O ataque Open VSX expôs uma vulnerabilidade crítica em um dos principais registros de extensões para o ecossistema de desenvolvimento baseado no VSCode. A Eclipse Foundation, responsável pelo Open VSX, confirmou que tokens de acesso foram vazados em repositórios públicos, permitindo que agentes maliciosos publicassem extensões contaminadas com o malware GlassWorm. A resposta imediata incluiu a remoção das extensões comprometidas e a rotação de todos os tokens comprometidos.
Esse incidente evidencia, mais uma vez, como pequenas falhas no gerenciamento de segredos podem comprometer toda a cadeia de suprimentos de software. Os invasores conseguiram infiltrar código malicioso em extensões legítimas, explorando a confiança que milhares de desenvolvedores depositam na plataforma.
A seguir, você entenderá como o ataque ocorreu, como o malware GlassWorm operava e quais foram as ações de mitigação adotadas.
O que é o Open VSX e por que ele é importante?
O Open VSX é um registro aberto e independente de extensões, criado como alternativa ao marketplace oficial da Microsoft usado no Visual Studio Code. Ele é essencial para usuários de forks como VSCodium, Cursor e Windsurf, que não podem acessar o marketplace proprietário da Microsoft devido a restrições de licença.
Mantido pela Eclipse Foundation, o Open VSX permite que desenvolvedores publiquem, distribuam e atualizem extensões de forma transparente e colaborativa. Essa abertura o torna crucial para o ecossistema open-source, mas também o expõe a riscos específicos — como ataques de cadeia de suprimentos, que visam comprometer extensões utilizadas por milhares de desenvolvedores.
A anatomia do ataque Open VSX: vazamento de tokens e o malware ‘GlassWorm’
O ponto de falha inicial: tokens expostos
O ataque Open VSX teve início com uma descoberta da Wiz, que identificou mais de 550 tokens e segredos expostos em repositórios públicos no GitHub. Esses tokens permitiam acesso direto a extensões publicadas no Open VSX, possibilitando que qualquer pessoa — incluindo agentes maliciosos — enviasse novas versões adulteradas de extensões populares.
Um token de acesso funciona como uma chave privada que autoriza a publicação de novas versões de uma extensão. Quando exposto, ele concede controle total sobre o pacote, incluindo a capacidade de inserir código malicioso sem que os usuários percebam.
‘GlassWorm’: o malware em ação
A investigação da Koi Security revelou que os invasores utilizaram esse acesso para distribuir o malware GlassWorm através de pelo menos 49 extensões. O objetivo era claro: roubar credenciais de desenvolvedores, cookies, tokens de autenticação e até dados de carteiras de criptomoedas.
O diferencial da campanha GlassWorm estava no uso de esteganografia Unicode — uma técnica que insere caracteres invisíveis (como espaços de largura zero ou caracteres bidi) dentro do código-fonte. Isso permitia ocultar comandos maliciosos e dificultava a detecção por ferramentas de segurança, já que o código parecia legítimo aos olhos humanos.
Esclarecimentos da Eclipse Foundation
Após a repercussão inicial e a publicação de relatórios externos, a Eclipse Foundation esclareceu alguns pontos importantes:
- O malware GlassWorm não era autorreplicante. Ele não infectava automaticamente outras extensões após ser instalado.
- O foco principal era roubar tokens de desenvolvedores para ampliar o alcance do ataque.
- Muitos números de download reportados nas análises externas estavam inflados por bots automatizados, não representando usuários reais.
Resposta ao incidente e medidas de contenção
Ação rápida: limpeza e rotação
No dia 21 de outubro, a equipe responsável pelo Open VSX removeu todas as extensões comprometidas com o malware GlassWorm. Paralelamente, todos os tokens de acesso foram rotacionados ou revogados, interrompendo imediatamente o uso indevido desses acessos.
A Eclipse Foundation afirmou que o incidente está “totalmente contido”, e que investigações adicionais estão em andamento para identificar impactos reais e usuários potencialmente afetados.
O que muda agora? Melhorias de segurança futuras
Entre as ações anunciadas para fortalecer a segurança do Open VSX, destacam-se:
- Redução do tempo de validade dos tokens de acesso.
- Criação de processos automáticos de revogação e detecção de uso suspeito.
- Análises de segurança automatizadas para novas publicações de extensões.
- Parcerias com marketplaces como o da Microsoft para compartilhar indicadores de comprometimento (IoCs).
A ameaça não acabou: GlassWorm migra para o GitHub
Mesmo com o ataque Open VSX neutralizado, a campanha GlassWorm não foi encerrada. A empresa de segurança Aikido identificou o mesmo grupo de agentes maliciosos atuando no GitHub, usando novamente a técnica de esteganografia Unicode em bibliotecas JavaScript.
Os invasores agora estão distribuindo pacotes maliciosos via repositórios de código, explorando a confiança em dependências de projetos open-source. Isso demonstra que, embora a porta do Open VSX tenha sido fechada, os atacantes continuam ativos e adaptando suas estratégias.
Conclusão: a lição sobre gerenciamento de segredos
O ataque Open VSX representa uma das mais recentes e significativas violações de segurança na cadeia de suprimentos de software. Ele não foi causado por uma falha técnica complexa, mas por algo simples e evitável: vazamento de tokens e chaves privadas em repositórios públicos.
A lição é clara: segredos expostos em código são portas abertas para invasores. Ferramentas de detecção automática, políticas de rotação de credenciais e auditorias contínuas devem ser parte da rotina de qualquer desenvolvedor ou empresa.
Este é um bom momento para revisar repositórios, excluir chaves expostas e verificar a procedência de extensões instaladas em editores como VSCode, VSCodium ou Cursor. A segurança da cadeia de suprimentos começa com a responsabilidade individual.
