.png)
Dezoito minutos, 2,2 milhões de alvos
Tem sido uma semana difícil para o GitHub. Ontem, o GitHub confirmou que tinha sido alvo de uma violação. Segundo consta, os atacantes extraíram dados de cerca de 3 700 repositórios internos, e o ponto de entrada foi uma extensão do VS Code maliciosa em execução no computador de um funcionário do GitHub.
No dia anterior, a Nx Console (uma extensão popular do VS Code para o sistema de compilação monorepo Nx) revelou o mecanismo que tornou a violação possível. No que diz respeito à segurança, as extensões do VS Code são um verdadeiro «O Oeste Selvagem».
O que aconteceu com a Nx Console
No dia 18 de maio, a versão 18.95.0 da extensão Nx Console (2,2 milhões de instalações, selo de editor verificado) foi carregada no Visual Studio Marketplace às 12h30 UTC. A Microsoft não sinalizou o carregamento. O responsável pela manutenção do Nx só recebeu o e-mail de notificação de publicação do marketplace às 12:36 UTC, seis minutos depois. A compilação comprometida foi retirada do ar às 12:47 UTC e a Microsoft registou a remoção na íntegra às 12:48 UTC. Exposição total no Visual Studio Marketplace: cerca de dezoito minutos.
A mesma compilação também foi disponibilizada no OpenVSX. Notícias anteriores indicavam que o OpenVSX não tinha sido afetado, mas o comunicado atualizado dos responsáveis pela manutenção indica que esteve disponível nesse serviço entre as 12:33 UTC e as 13:09 UTC. Trata-se de cerca de trinta e seis minutos, o dobro do período de disponibilidade no Visual Studio Marketplace.
De acordo com o aviso, qualquer pessoa que tivesse o Nx Console instalado com a atualização automática ativada durante esses períodos deve partir do princípio de que foi comprometida, e que todos os dados no disco (tokens, secrets, chaves SSH e quaisquer outros dados relacionados com credenciais) devem ser substituídos.
A causa principal foi o token do GitHub de um colaborador que tinha sido obtido ilegalmente num ataque anterior à cadeia de abastecimento e, posteriormente, utilizado para publicar a versão maliciosa. O pipeline de publicação aceitou o token roubado sem questionar, o que foi tudo o que os atacantes precisavam.
A atualização automática é o verdadeiro problema
Todas as plataformas populares de extensões vêm com a atualização automática ativada por predefinição. O VS Code, o Cursor, toda a gama. O raciocínio faz sentido quando considerado isoladamente, porque a maioria dos programadores nunca atualiza nada manualmente; por isso, desativar essa funcionalidade significaria que uma grande quantidade de editores continuaria a utilizar código desatualizado e vulnerável.
Esta vantagem deixa de fazer sentido quando se tem em conta os editores maliciosos ou comprometidos. A atualização automática proporciona a um atacante que controle uma versão um canal de distribuição direto para todos os computadores que executam essa extensão. As lojas de aplicações não impõem qualquer processo de revisão nem período de espera entre o momento em que uma atualização é publicada e o momento em que os clientes a descarregam.
A verificação em si não tem um intervalo fixo. Há um Temporizador de reserva de 12 horas em extensionsWorkbenchService.ts (1 hora no Insiders com uma atualização de produto pendente), uma verificação imediata ao iniciar assim que a bancada ficar inativa, e vários gatilhos baseados em eventos (verificação de atualizações do produto, alteração da política da lista de permissões, mudança da ligação de tarifa limitada para ilimitada, ativação da opção de verificação automática). Além de tudo isso, existe um caminho separado que deteta atualizações como efeito colateral de qualquer outra interação com o marketplace. Quando o VS Code consulta a galeria por qualquer motivo (barra lateral de extensões visível, pesquisa no marketplace, sugestões de recomendações, subsistemas em segundo plano que recuperam metadados da galeria), ele compara o resultado com as extensões instaladas e, caso alguma esteja desatualizada, incêndios Atualizar extensões automaticamente, que se instala através de um atrasador limitado a 1 segundo. Com extensions.autoUpdate Se estiver ativada (configuração padrão), a instalação ocorre em segundo plano, sem qualquer aviso.
A janela de dezoito minutos no Visual Studio Marketplace captou qualquer editor em execução que tivesse interagido com a galeria, acedendo à lista do Nx Console durante esses minutos: barra lateral visível, pesquisa no Marketplace, consulta de recomendações ou qualquer um dos subsistemas em segundo plano que recuperam metadados da galeria. Tendo em conta os diferentes fusos horários e horários de trabalho, numa extensão com 2,2 milhões de instalações e uma barra lateral de extensões que muitos programadores mantêm aberta, essa população é muito maior do que um temporizador periódico por si só sugeriria. Durante os nossos próprios testes destas funcionalidades, observámos que a atualização automática era acionada poucos minutos após a publicação de uma nova versão, o que corresponde ao percurso de sincronização da galeria, em vez do temporizador de 12 horas. A janela do OpenVSX fez o mesmo durante cerca de trinta e seis minutos.
O cronograma dos responsáveis pela manutenção também revela a lacuna de deteção que a atualização automática cria. Seis desses dezoito minutos decorreram antes de o responsável pela manutenção sequer ter visto a notificação de upload da loja de aplicações. Durante esses seis minutos, a atualização automática estava a instalar a versão maliciosa nos computadores dos utilizadores, antes de qualquer pessoa do lado do editor ter tido conhecimento do problema para agir.
Por que é que isto continua a funcionar
O caso do Nx não é a primeira vez que isto acontece a uma extensão do VS Code. Em novembro de 2025, o ataque à AsyncAPI foi o primeiro incidente da onda do worm Shai-Hulud 2.0. Os atacantes tinham roubado os tokens de publicação npm e OpenVSX da AsyncAPI, que se encontravam nos secrets do repositório GitHub secrets anos, e utilizaram-nos para distribuir pacotes npm maliciosos da AsyncAPI e uma versão maliciosa da extensão AsyncAPI para o VS Code no OpenVSX. Pelo menos um programador relatou ter sido infetado através da extensão no próprio sistema de acompanhamento de problemas do projeto, antes de os responsáveis pela manutenção terem conseguido desativar as versões afetadas. O mesmo mecanismo estava em ação: uma credencial roubada, usada para enviar código malicioso a uma base de utilizadores com atualização automática durante um curto período de tempo.
Há alguns fatores que jogam contra os defensores nesta situação:
- Um elevado número de instalações e os selos de editor verificado transmitem confiança, e é precisamente essa confiança que os atacantes pretendem manipular. As extensões populares já se encontram instaladas em milhões de computadores, pelo que uma versão comprometida introduz automaticamente código malicioso em todas essas instalações existentes, sem necessidade de recorrer a técnicas de engenharia social contra novos utilizadores.
- As extensões são distribuídas como código JavaScript interpretado, em vez de ficheiros binários compilados. A carga maliciosa do Nx Console consistia em 2 777 bytes injetados num ficheiro minimizado, que, por sua vez, descarregava um dropper ofuscado de 498 KB a partir de um commit abandonado no repositório oficial
nrwl/nxrepositório. O EDR não dispõe de uma assinatura para uma comparação de código JavaScript minimizado com uma extensão na qual os utilizadores já confiam. - É mais fácil do que deveria ser obter credenciais de administradores através de phishing ou de scraping. O caso da Nx teve início com um token proveniente de um ataque anterior, que foi utilizado posteriormente contra um alvo de confiança. O caso da AsyncAPI teve início com um token do OpenVSX que se encontrava num segredo de um repositório do GitHub há anos.
- A comunidade está a reagir rapidamente a esta situação, mas dezoito minutos de distribuição automática são suficientes para causar danos, e isso apenas numa das duas plataformas que hospedam a extensão.
Assim que for instalado num computador, a loja não poderá ajudá-lo
As lojas de aplicações também não têm como retirar uma extensão depois de esta ter sido instalada. Retirar a publicação impede novas instalações, mas quem já tiver descarregado a versão maliciosa continuará a utilizá-la até atualizar para uma versão segura ou desinstalar manualmente. A atualização automática acabará por levar os utilizadores afetados para a versão corrigida assim que o responsável pela manutenção a disponibilizar, mas a loja não dispõe de um «kill switch» nem de qualquer forma de reverter a instalação mais rapidamente.
A análiseWiz sobre a cauda longa do Shai-Hulud 2.0 ilustra esta dinâmica na prática. A extensão maliciosa AsyncAPI para o VS Code (v1.0.1) foi retirada do OpenVSX a 26 de novembro de 2025, mas o registo voltou à versão anterior, que estava limpa (v1.0.0). As cópias instaladas na v1.0.1 não viram nenhuma versão mais recente disponível, pelo que a atualização automática nunca foi acionada. A extensão continuou a funcionar nas máquinas dos programadores e a extrair credenciais durante quase um mês, representando mais de 90% das infeções de cauda longa da campanha e cerca de 100 a 200 novos repositórios comprometidos por dia, de 25 de novembro a 24 de dezembro. O fluxo só parou quando a AsyncAPI publicou uma versão limpa v1.1.0 a 24 de dezembro (depois de Wiz lhes ter comunicado o problema no dia anterior), altura em que as IDEs foram atualizadas automaticamente para essa versão e os novos compromissos diários caíram para apenas alguns em poucos dias.
A Microsoft também retira as listagens sem aviso prévio. Não há qualquer notificação para os utilizadores que tenham instalado a extensão durante o período em que esta esteve exposta. O seu editor não exibe uma mensagem do tipo «pode ter instalado uma versão comprometida; verifique o seu computador». A menos que estivesse a acompanhar as notícias de segurança no dia do incidente, o único indício que poderia ter é o facto de a extensão ter deixado de aparecer nos resultados de pesquisa da loja. O repositório do Nx Console já tem uma questão de um programador a perguntar, de boa-fé, por que razão a extensão desapareceu do marketplace. A maioria dos utilizadores nem pensaria em perguntar.
O resultado é que a única resposta eficaz do marketplace consiste em impedir novas instalações de uma versão reconhecidamente defeituosa. Para os programadores que já tenham descarregado a versão maliciosa durante esse período, a responsabilidade pela correção recai inteiramente sobre eles, dependendo de terem tomado conhecimento do incidente através de algum canal que não seja o próprio marketplace.
O que fazer, na verdade
Se tinha o Nx Console instalado com atualização automática durante esses períodos em 18 de maio, as orientações do aviso são o ponto de partida certo: altere os tokens, secrets, chaves SSH e qualquer outro elemento acessível a partir da máquina afetada. Qualquer pessoa que tenha executado a compilação do OpenVSX está abrangida pelo período mais longo de trinta e seis minutos, em vez do período do Visual Studio Marketplace.
No que diz respeito ao padrão geral, a solução mais simples consiste em introduzir um intervalo entre o momento em que uma versão é publicada e o momento em que a sua instalação é permitida. Aikido Proteção de Dispositivos vem com um período de espera padrão de 48 horas para novas versões de pacotes e extensões, o que teria detetado o Nx Console (e o recente tarefa duradoura Violação de segurança no PyPI) sem que seja necessário que alguém o identifique primeiro como malicioso. Como particular sem uma solução de um fornecedor, o mais próximo que se pode chegar é desativar as atualizações automáticas de extensões no VS Code e, em vez disso, atualizar-se de acordo com um calendário pré-definido. É mais lento e ficará um ou dois dias atrasado em relação aos lançamentos oficiais. Esse é o preço de não executar no seu portátil o código recém-publicado por outras pessoas no momento em que o publicam.
O VS Code já suporta a estrutura de políticas subjacente para tornar isto uma configuração ao nível da organização. O extensões.permitidas A política empresarial permite aos administradores restringir quais os editores, extensões e até versões específicas que podem ser instaladas nos dispositivos geridos. Uma opção de tempo de espera adicional (algo do tipo «instalar automaticamente apenas versões com mais de N horas») encaixar-se-ia nessa mesma configuração. Não há nenhuma boa razão técnica para que isso ainda não exista e, dada a frequência com que estes incidentes ocorrem no marketplace que o acompanha, deveria existir. O mesmo se aplica ao Cursor e a qualquer outro editor baseado no VS Code: se já permite que as organizações imponham uma lista de permissões, permita-lhes também impor um período de espera.
A história do GitHub vai dar que falar durante semanas porque a vítima é famosa, e o mesmo mecanismo subjacente continuará a gerar violações. Enquanto as lojas de aplicações continuarem a enviar automaticamente atualizações a partir de contas que podem ser comprometidas de uma dezena de formas comuns, qualquer extensão popular está a um token roubado de se transformar num worm.
Proteção Aikido
Se pretende implementar um período de espera hoje mesmo, sem ter de esperar que o VS Code ou o Cursor o incluam nativamente, recomendamos Aikido Protection. Este impõe uma política de idade mínima configurável (padrão de 48 horas) para a instalação de pacotes e extensões ao nível do dispositivo, pelo que a mesma política abrange qualquer editor baseado no VS Code que os seus programadores utilizem.
