GlassWorm ameaça Open VSX ao aproveitar dependências de extensões

Pesquisadores de segurança descobriram uma variação preocupante do operacional conhecido como GlassWorm que ataca o ecossistema de extensões para editores de código, e desta vez o faz aproveitando uma peculiaridade do registro Open VSX. Em vez de incorporar diretamente um carregador malicioso em cada pacote, os atacantes estão recorrendo às relações entre extensões para transformar plugins aparentemente inocuos em vetores de entrega em atualizações posteriores. Isso significa que uma extensão que parece legítima no início pode, com uma simples atualização, começar a baixar código ligado a GlassWorm sem que o usuário o espere. Você pode ler o relatório técnico da empresa que o documentou aqui: Socket — Open VSX transitive GlassWorm campaign.

O mecanismo que exploram baseia-se em como os editores instalam extensões indicadas nos meta- dados: tanto as propriedades extensionPack como extensionDependencies no arquivo package.json provocam que o editor instale também as extensões listadas. Essa lógica, pensada para facilitar a experiência do desenvolvedor, torna-se perigosa quando um ator malicioso publica primeiro uma extensão inofensiva e mais tarde a atualiza para declarar dependências para pacotes comprometidos. A documentação oficial de como estes manifestos funcionam ajuda a entender o detalhe técnico: Documentação de manifesto de extensões de VS Code, e o registro onde muitas dessas extensões são alojadas Open VSX.

De acordo com o Socket, desde o final de janeiro de 2026 foram identificadas dezenas de extensões maliciosas no Open VSX que imitavam utilitários de uso comum para desenvolvedores: linters, formateadores, runners de código e plugins projetados para assistentes de programação com IA. Os sinais de abuso incluem ofuscação mais agressiva do código, rotação de endereços de pagamento na cadeia de blocos Solana e uso dessas transações como um “dead drop” para resolver os servidores de comando e controle; técnicas que visam melhorar a resiliência do ataque contra a mitigação tradicionais.

Paralelamente, pesquisadores de Aikido documentaram uma tática complementar que se viu em repositórios do GitHub e pacotes npm: a inserção de caracteres Unicode invisíveis no código fonte para ocultar um carregador. Embora esses caracteres não sejam apreciados ao ler o arquivo em um editor, a interpretação posterior permite descodificar e executar um primeiro estádio que, por sua vez, recupera uma segunda etapa com capacidades de exfiltração de tokens, credenciais e segredos. A análise de Aikido com exemplos e amostras técnicas está disponível aqui: Aikido — GlassWorm returns: unicode attack, e uma amostra concreta do uso desses caracteres em um commit pode ser consultada neste pull request: Commit com caracteres invisíveis.

O alcance dessa infecção em código aberto foi notável: Aikido estimou que mais de uma centena de repositórios no GitHub foram tocados na primeira semana de março de 2026, e pelo menos dois pacotes npm com a mesma técnica foram detectados, o que aponta para uma operação coordenada que abrange diferentes plataformas de distribuição de software.

Por sua vez, a pesquisa de Endor Labs colocou sobre a mesa outra variação da ameaça no ecossistema npm, onde dezenas de pacotes maliciosos publicados por contas descartáveis foram encontrados entre novembro de 2025 e fevereiro de 2026. Estes pacotes usavam o que é chamado de Remote Dynamic Dependencies: dependências cuja origem é um URL HTTP externo em vez do próprio registo. Essa capacidade permite aos operadores alterar o código que é entregue sem publicar uma nova versão no registo, o que complica a detecção e o bloqueio. O relatório do Endor Labs, com as suas conclusões e observações sobre riscos de dependências remotas, está aqui: Endor Labs — Return of PhantomRaven.

A autoria dessas ondas foi objeto de debate: embora alguns analisaram a campanha como parte do coletivo PhantomRaven, Endor Labs levantou dúvidas e sugestões de que uma parte do fenômeno talvez respondesse a experimentos de segurança ou pesquisas, apontando sinais de alarme como a coleta maciça de dados, a rotação deliberada de contas e a falta de transparência nos pacotes. Você pode consultar o contexto sobre PhantomRaven e análises adicionais na nota de Sonatype: Sonatype — PhantomRaven npm malware.

Para além da autoria, há uma lição técnica clara: quando um pacote ou extensão depende de recursos que não estão versionados no registro - sejam pacotes remotos, endereços em blockchain que mudam ou dependências transitórias adicionadas por atualizações - o controle do comportamento fica nas mãos do publicador. Isso torna o fornecimento de código aberto numa superfície de ataque dinâmica onde uma atualização aparentemente banal pode introduzir funcionalidades com permissões amplas e consequências graves.

O que significa isto para desenvolvedores e equipamentos que constroem software? Primeiro, requer mudar a mentalidade em relação à confiança implícita depositada em extensões e pacotes populares: a reputação pode ser comprada ou recriada e um pacote legítimo hoje pode tornar-se perigoso amanhã. Segundo, convém inspecionar os manifestos e a cadeia de dependências antes de incorporar livrarias ou extensões em ambientes de produção, prestando atenção a entradas não padrão como dependências apontando para URLs externas, e a metadados que agregam pacotes adicionais como extensionPack ou extensionDependencies.

Também é importante proteger credenciais e tokens com políticas de privilégios mínimos e rotação periódica, evitar armazenar segredos em variáveis de ambiente não protegidas, usar repositórios privados ou mirrors controlados quando possível, e aplicar análises automatizadas da cadeia de fornecimento que detecte comportamentos suspeitos. Ferramentas de análise de software e digitalização de dependências podem ajudar a identificar pacotes que incorporam código de fontes fora do registro ou que realizam chamadas incomuns ao ambiente de execução.

Finalmente, a comunidade e os mantenedores de registros têm um papel chave: revisar e endurecer os processos de publicação, implantar mecanismos para detectar padrões de ofuscação e dependências dinâmicas, e oferecer sinais claros ao usuário sobre a origem e o alcance do que se instala. Open VSX e outros repositórios já tomaram medidas para retirar extensões maliciosas, mas a resposta técnica e operacional deve ser contínua e colaborativa entre fornecedores de ferramentas, equipamentos de segurança e desenvolvedores.

Este episódio é um lembrete de que o conforto dos ecossistemas modernos de desenvolvedores –extensões que se instalam automaticamente, dependências que se resolvem com um clique – traz um custo em segurança se não forem implementadas salvaguardas. A defesa contra campanhas como o GlassWorm exige tanto melhores práticas individuais como melhorias sistêmicas em como se distribui e revisa o software livre e suas dependências.