Campanha usa relações transitivas entre extensões para transformar pacotes aparentemente legítimos em veículos de entrega de malware contra desenvolvedores.
| Componente | Registro Open VSX, extensões para ambientes compatíveis com VS Code, repositórios GitHub e pacotes npm citados na mesma onda de atividade. |
| Vetor | Uso de extensionPack e extensionDependencies em package.json para instalar extensões relacionadas após a publicação inicial de pacotes que aparentavam ser benignos. |
| Impacto | Entrega transitiva de carregadores associados ao GlassWorm, coleta de tokens, credenciais e segredos, drenagem de carteiras de criptomoedas e uso de sistemas infectados como proxies. |
| Prioridade | Auditar extensões instaladas a partir do Open VSX, revisar dependências transitivas, remover pacotes suspeitos, rotacionar segredos expostos e bloquear artefatos associados à campanha. |
| Artefatos | Pelo menos 72 extensões maliciosas adicionais no Open VSX desde 31 de janeiro de 2026, 151 repositórios GitHub afetados entre 3 e 9 de março de 2026 e dois pacotes npm usando a mesma técnica de Unicode invisível. |
| Técnicas | Ofuscação mais pesada, caracteres Unicode invisíveis, verificação de localidade russa, transações Solana como resolvedor de servidor C2 e rotação de carteiras Solana para dificultar detecção. |
A campanha GlassWorm evoluiu para uma etapa mais agressiva contra a cadeia de suprimentos de desenvolvimento ao abusar do modo como extensões do Open VSX podem declarar relações com outras extensões. Em vez de exigir que cada listagem maliciosa carregue diretamente o componente de instalação, os operadores passaram a usar campos como extensionPack e extensionDependencies para fazer com que uma extensão aparentemente autônoma instale outra extensão ligada ao GlassWorm. Esse modelo muda o ponto de controle defensivo: a avaliação isolada do pacote inicial deixa de ser suficiente quando uma atualização posterior pode introduzir uma relação transitiva que altera o comportamento real no ambiente do desenvolvedor.
O conjunto identificado inclui ao menos 72 extensões maliciosas adicionais no Open VSX desde 31 de janeiro de 2026. Elas imitavam utilitários comuns no fluxo de trabalho de programação, incluindo linters, formatadores, executores de código e ferramentas relacionadas a assistentes de codificação com inteligência artificial, como Clade Code e Google Antigravity. O objetivo operacional permanece alinhado ao histórico do GlassWorm: roubo de segredos, coleta de credenciais, drenagem de carteiras de criptomoedas e uso de máquinas comprometidas como infraestrutura de proxy para outras atividades criminosas.
A campanha já vinha sendo associada a infiltrações em marketplaces de extensões do Microsoft Visual Studio e do Open VSX. A nova etapa mantém características observadas anteriormente, como o uso de caracteres Unicode invisíveis para esconder trechos de código, verificações para evitar infecção em sistemas com localidade russa e uso de transações Solana como resolvedor de servidor de comando e controle. A diferença principal está no abuso de relações entre extensões, que aproxima o fluxo de ataque de padrões já conhecidos no ecossistema npm, onde dependências maliciosas podem entrar indiretamente em projetos que aparentam consumir pacotes legítimos.
No Open VSX, uma extensão pode declarar outras extensões como parte de um pacote ou como dependências funcionais. Quando esses campos aparecem no package.json, o editor procede com a instalação das extensões listadas. O GlassWorm explora exatamente essa confiança operacional: uma extensão publicada inicialmente sem comportamento obviamente malicioso pode passar por revisão ou ganhar adoção, e depois receber uma atualização que adiciona uma extensão associada à campanha como dependência. A instalação final acontece de forma transitiva, reduzindo a chance de o usuário perceber que um segundo artefato entrou no ambiente.
Esse desenho cria um cenário em que o propósito aparente da extensão não muda, mas sua superfície de execução passa a incluir código externo controlado pelo operador. Uma extensão que parecia ser apenas um linter, formatador ou auxiliar de codificação pode se tornar um instalador para outro pacote. Como a cadeia depende de metadados aceitos pelo próprio modelo de extensão, a análise precisa considerar tanto o código local quanto as relações declaradas e suas alterações ao longo do tempo. A revisão de versões anteriores também se torna importante, porque o ponto de comprometimento pode estar na mudança de dependências e não em uma função recém-adicionada no pacote principal.
A etapa de execução mantém elementos já associados ao GlassWorm. A campanha usa ofuscação para dificultar inspeção estática, caracteres Unicode invisíveis para ocultar conteúdo em código e um mecanismo baseado em transações Solana para localizar o servidor de comando e controle. O uso de carteiras Solana rotacionadas aumenta a resiliência contra bloqueios pontuais, porque a infraestrutura de resolução não depende apenas de um domínio fixo publicado diretamente no pacote. A verificação de localidade russa sugere uma tentativa de reduzir infecções em determinados ambientes e também fornece um sinal útil para análise comportamental em sandbox.
A superfície principal envolve estáções de trabalho de desenvolvedores que instalam extensões a partir do Open VSX, especialmente em ambientes que usam IDEs ou editores compatíveis com o ecossistema de extensões do VS Code. O risco aumenta quando organizações permitem instalação autônoma de extensões, não mantêm inventário de pacotes por usuário e não registram mudanças de versão ou de dependências. Equipes que trabalham com tokens de nuvem, segredos de CI/CD, chaves de API, carteiras de criptomoedas ou credenciais em variáveis de ambiente devem tratar máquinas de desenvolvimento afetadas como ativos sensíveis, pois o fluxo descrito mira exatamente esse tipo de material.
A mesma técnica de ocultação por Unicode invisível também apareceu em uma campanha de injeção em repositórios de código aberto. Entre 3 e 9 de março de 2026, ao menos 151 repositórios GitHub teriam sido afetados por alterações que pareciam realistas, como ajustes de documentação, incrementos de versão, pequenas refatorações e correções pontuais. O conteúdo invisível decodificava para um carregador responsável por buscar e executar um segundo estágio com foco em tokens, credenciais e segredos. Dois pacotes npm também foram citados com a mesma técnica, indicando um esforço coordenado contra múltiplos pontos do fluxo de desenvolvimento.
Outro conjunto correlato envolve 88 pacotes npm publicados em três ondas entre novembro de 2025 e fevereiro de 2026 por 50 contas descartáveis. Esses pacotes usavam dependências dinâmicas remotas, nas quais o package.json aponta para código hospedado em uma URL HTTP personalizada. Esse padrão permite alterar o comportamento entregue aos consumidores sem publicar uma nova versão no registro npm, o que reduz a visibilidade de mudanças e dificulta auditorias baseadas apenas em versões fixadas no registro.
- Extensões Open VSX que ganharam novas relações transitivas após a publicação inicial.
- Ambientes de desenvolvimento com instalação livre de extensões e baixa governança de versões.
- Repositórios GitHub com alterações aparentemente legítimas contendo caracteres Unicode invisíveis.
- Pacotes npm com dependências remotas fora do registro e comportamento alterável pelo servidor externo.
A busca defensiva deve começar pelo inventário de extensões instaladas e por seus metadados. O ponto crítico é identificar extensões que passaram a declarar extensionPack ou extensionDependencies em versões recentes, principalmente quando o pacote original se apresenta como ferramenta simples de produtividade ou utilitário de desenvolvimento. A análise deve comparar versões, observar quando a dependência transitiva foi introduzida e correlacionar esse momento com eventos de instalação, execução do editor, abertura de projetos e alterações em variáveis de ambiente ou arquivos de configuração sensíveis.
Em endpoints, a telemetria relevante inclui processos iniciados pelo editor, conexões de rede anômalas após instalação ou atualização de extensões, acesso a arquivos de credenciais, leitura de variáveis de ambiente e criação de canais de comunicação persistentes. Em repositórios, a caça deve procurar caracteres invisíveis ou sequências Unicode fora do padrão em commits recentes, especialmente quando acompanhadas de mudanças pequenas e estilisticamente coerentes com o projeto. A presença de alterações benignas ao redor do conteúdo malicioso é parte importante do fluxo, porque reduz a probabilidade de revisão manual cuidadosa.
No ecossistema npm, equipes devem localizar dependências referenciadas por URLs externas em package.json, caches de gerenciadores de pacote e lockfiles. Dependências dinâmicas remotas são um ponto de risco porque o conteúdo pode mudar sem alteração de versão. Em pipelines de CI/CD, a prioridade é revisar jobs executados após instalação de pacotes ou extensões, variáveis expostas no ambiente, tokens usados por runners e qualquer comunicação externa iniciada durante etapas de build ou teste.
- Novas entradas
extensionPackouextensionDependenciesem extensões previamente aprovadas. - Conexões externas iniciadas por processos do editor logo após instalação ou atualização de extensão.
- Caracteres Unicode invisíveis em commits de documentação, versão, refatoração pequena ou correção simples.
- Dependências npm apontando para URLs HTTP personalizadas em vez de pacotes versionados no registro.
- Leitura incomum de variáveis de ambiente, tokens de CI/CD, arquivos de credenciais e metadados do sistema.
A resposta deve priorizar remoção das extensões suspeitas, bloqueio de novas instalações não aprovadas e revisão das extensões já presentes em estáções de trabalho de desenvolvimento. Como o abuso ocorre por relações transitivas, não basta procurar apenas código malicioso dentro da extensão instalada diretamente pelo usuário. É necessário listar também extensões puxadas automaticamente, comparar versões publicadas, revisar alterações em package.json e validar se a dependência declarada tem finalidade compatível com o pacote original.
Quando houver indício de execução, a contenção deve assumir possível exposição de segredos acessíveis ao usuário ou ao pipeline. Tokens de repositório, credenciais de nuvem, chaves de API, segredos de CI/CD e credenciais armazenadas localmente devem ser rotacionados conforme escopo do ativo afetado. A investigação precisa preservar artefatos de endpoint, histórico de instalação de extensões, caches de pacotes, logs do editor, eventos de rede e registros de pipeline para reconstruir a janela de exposição sem depender apenas da presença atual do pacote malicioso.
Para reduzir recorrência, organizações devem adotar allowlist de extensões, revisão de metadados antes de atualização, bloqueio de dependências remotas não autorizadas em npm, inspeção de caracteres Unicode invisíveis em revisões de código e políticas de menor privilégio para estáções de desenvolvimento. Em ambientes com alto valor de segredos, a execução de extensões deve ser separada do acesso direto a credenciais sensíveis, e pipelines devem evitar expor tokens amplos a etapas que instalam dependências ou executam código de terceiros.
- Remover extensões associadas à campanha e revisar extensões instaladas por dependência transitiva.
- Comparar versões recentes de
package.jsonem extensões aprovadas e sinalizar novas relações externas. - Rotacionar tokens, credenciais e segredos acessíveis em máquinas ou pipelines potencialmente afetados.
- Bloquear dependências npm por URL HTTP personalizada quando não houver justificativa aprovada.
- Adicionar verificação de caracteres Unicode invisíveis em revisão de código, hooks internos e pipelines defensivos.
0 Comentários