.png)
Dezoito Minutos, 2,2 Milhões de Alvos
Foi uma semana difícil para o GitHub. Ontem, o GitHub confirmou que havia sido violado. Os invasores teriam extraído dados de aproximadamente 3.700 repositórios internos, e o ponto de entrada foi uma extensão maliciosa do VS Code executada na máquina de um funcionário do GitHub.
No dia anterior, o Nx Console (uma popular extensão do VS Code para o sistema de build monorepo Nx) demonstrou o mecanismo que tornou a violação possível. Quando se trata de segurança, as extensões do VS Code são o Velho Oeste.
O que aconteceu com o Nx Console
Em 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 12:30 UTC. A Microsoft não sinalizou o upload. O mantenedor do Nx não recebeu o e-mail de notificação de upload do marketplace até as 12:36 UTC, seis minutos depois. A build comprometida foi despublicada às 12:47 UTC e a Microsoft registrou a remoção completa às 12:48 UTC. Exposição total no Visual Studio Marketplace: cerca de dezoito minutos.
A mesma build também foi distribuída no OpenVSX. Relatórios anteriores afirmavam que o OpenVSX não havia sido afetado, mas o aviso atualizado dos mantenedores indica que esteve ativo lá das 12:33 UTC às 13:09 UTC. Isso representa aproximadamente trinta e seis minutos, o dobro da janela do Visual Studio Marketplace.
De acordo com o aviso, qualquer pessoa que tivesse o Nx Console instalado com a atualização automática habilitada durante esses períodos deve assumir que foi comprometida, e qualquer coisa no disco (tokens, Secrets, chaves SSH, qualquer credencial adjacente) precisava ser rotacionada.
A causa raiz foi um token do GitHub de um colaborador que havia sido extraído em um ataque anterior à cadeia de suprimentos e, em seguida, usado para publicar a versão maliciosa. O pipeline de publicação aceitou o token roubado sem questionar, o que era tudo o que os atacantes precisavam.
A atualização automática é o problema real
Todo marketplace de extensões popular vem com a atualização automática ativada por padrão. VS Code, Cursor, toda a linha. O raciocínio faz sentido isoladamente, porque a maioria dos desenvolvedores nunca atualiza nada manualmente, então desativá-la significa uma longa cauda de editores executando código obsoleto e vulnerável.
A compensação deixa de fazer sentido quando se considera editores hostis/comprometidos. A atualização automática oferece a um atacante que controla uma versão um canal de push direto para todas as máquinas que executam essa extensão. Os marketplaces não impõem nenhum portão de revisão ou período de espera entre a publicação de uma atualização e o momento em que os clientes instalados a recebem.
A verificação em si não possui um único intervalo fixo. Há um temporizador de fallback de 12 horas em extensionsWorkbenchService.ts (1 hora no Insiders com uma atualização de produto pendente), uma verificação imediata na inicialização assim que o workbench estiver ocioso, e vários gatilhos baseados em eventos (verificação de atualização de produto, alteração de política de allowlist, conexão passando de medida para não medida, o botão de auto-verificação sendo ativado). Além de tudo isso, há um caminho separado que detecta atualizações como um 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, prompts de recomendação, subsistemas em segundo plano que buscam metadados da galeria), ele sincroniza o resultado com as extensões instaladas e, se alguma estiver desatualizada, dispara eventuallyAutoUpdateExtensions, que instala através de um atrasador limitado a 1 segundo. Com extensions.autoUpdate ativado (o padrão), a instalação ocorre em segundo plano sem aviso.
A janela de dezoito minutos no Visual Studio Marketplace capturou qualquer editor em execução que realizou uma interação com a galeria, tocando na listagem do Nx Console durante esses minutos: barra lateral visível, pesquisa no marketplace, consulta de recomendação ou qualquer um dos subsistemas em segundo plano que buscam metadados da galeria. Através de fusos horários e horários de trabalho, em uma extensão com 2,2 milhões de instalações e uma barra lateral de Extensões que muitos desenvolvedores deixam aberta, essa população é muito maior do que um temporizador periódico sozinho sugeriria. Durante nossos próprios testes desses recursos, vimos a atualização automática ser disparada minutos após a publicação de uma nova versão, o que corresponde ao caminho de sincronização da galeria, e não ao temporizador de 12 horas. A janela OpenVSX fez o mesmo por aproximadamente trinta e seis minutos.
A linha do tempo dos mantenedores também mostra a lacuna de detecção que a atualização automática abre. Seis desses dezoito minutos se passaram antes mesmo que o mantenedor visse a notificação de upload do marketplace. A atualização automática estava puxando a versão maliciosa para as máquinas dos usuários durante esses seis minutos, antes que qualquer humano do lado do editor pudesse ter agido.
Por que isso continua funcionando
O caso Nx não é a primeira vez que isso acontece com uma extensão do VS Code. Em novembro de 2025, o comprometimento da AsyncAPI foi o primeiro evento da onda do worm Shai-Hulud 2.0. Os atacantes haviam roubado os tokens de publicação npm e OpenVSX da AsyncAPI, que estavam armazenados em Secrets de repositórios GitHub por anos, e os usaram para enviar pacotes npm maliciosos da AsyncAPI e uma versão maliciosa da extensão AsyncAPI VS Code no OpenVSX. Pelo menos um desenvolvedor relatou ter sido infectado através da extensão no próprio rastreador de problemas do projeto antes que os mantenedores pudessem descontinuar as versões afetadas. O mesmo mecanismo estava em ação: uma credencial roubada, usada para enviar código malicioso para uma base de usuários com atualização automática durante um curto período.
Algumas coisas estão contra os defensores aqui:
- Altos números de instalações e selos de editor verificado sinalizam confiança, e confiança é o que os atacantes querem sequestrar. Extensões populares já estão em milhões de máquinas, então uma versão comprometida empurra código malicioso para todas essas instalações existentes automaticamente, sem a necessidade de qualquer engenharia social contra novos usuários.
- Extensões são distribuídas como JavaScript interpretado, e não como binários compilados. O payload malicioso do Nx Console tinha 2.777 bytes injetados em um arquivo minificado, que então buscou um dropper ofuscado de 498 KB de um commit órfão no repositório oficial
nrwl/nxrepositório. O EDR não possui uma assinatura para um diff de JavaScript minificado contra uma extensão em que os usuários já confiam. - As credenciais de mantenedor são mais fáceis de serem alvo de phishing ou de serem extraídas do que deveriam. O caso Nx começou com um token de um comprometimento separado, usado a jusante contra um alvo confiável. O caso AsyncAPI começou com um token OpenVSX que estava armazenado em um Secret de repositório GitHub por anos.
- A comunidade está ficando rápida em detectar isso, mas dezoito minutos de distribuição automática são suficientes para causar danos, e isso é apenas em um dos dois marketplaces que hospedam a extensão.
Uma vez que chega a uma máquina, o marketplace não pode ajudar
Os marketplaces também não têm como revogar uma extensão depois de instalada. Remover a listagem impede novas instalações, mas qualquer pessoa que já tenha baixado a versão maliciosa continua a executá-la até que atualize para uma versão limpa ou desinstale manualmente. A atualização automática eventualmente levará os usuários afetados para a versão corrigida assim que o mantenedor lançar uma, mas o marketplace não tem um 'kill-switch' e nenhuma maneira de reverter uma instalação mais rapidamente.
A análise da Wiz Research sobre a cauda longa do Shai-Hulud 2.0 mostra essa dinâmica na prática. A extensão maliciosa AsyncAPI VS Code (v1.0.1) foi removida do OpenVSX em 26 de novembro de 2025, mas o registro reverteu para a versão limpa anterior (v1.0.0). Cópias instaladas na v1.0.1 não viram nenhuma versão mais recente disponível, então a atualização automática nunca foi acionada. A extensão continuou rodando em máquinas de desenvolvedores e exfiltrando credenciais por quase um mês, responsável por mais de 90% das infecções de cauda longa da campanha e por aproximadamente 100-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 em 24 de dezembro (depois que a Wiz Research relatou o problema a eles no dia anterior), momento em que as IDEs foram atualizadas automaticamente para ela e os novos comprometimentos diários caíram para um punhado em poucos dias.
A Microsoft também remove listagens silenciosamente. Não há notificação para os usuários que instalaram durante a janela de exposição. O editor deles não exibe uma mensagem como "você pode ter instalado uma versão comprometida, por favor, verifique sua máquina". A menos que estivesse acompanhando as notícias de segurança no dia do incidente, seu único sinal pode ser que a extensão parou de aparecer nos resultados de busca do marketplace. O repositório do Nx Console já tem uma issue de um desenvolvedor perguntando, de boa fé, por que a extensão havia desaparecido do marketplace. A maioria dos usuários não pensaria em perguntar.
O efeito combinado é que a única resposta eficaz do marketplace é impedir novas instalações de uma versão comprovadamente maliciosa. Para os desenvolvedores que já baixaram a build maliciosa durante a janela, a limpeza recai inteiramente sobre eles e depende de eles aprenderem sobre o incidente por meio de algum canal diferente do próprio marketplace.
O que realmente fazer
Se o Nx Console estivesse instalado com atualização automática durante essas janelas em 18 de maio, a orientação do aviso é o ponto de partida correto: gire tokens, Secrets, chaves SSH e qualquer outra coisa acessível a partir da máquina afetada. Qualquer pessoa que executou a build do OpenVSX está no escopo da janela mais longa de trinta e seis minutos, em vez da do Visual Studio Marketplace.
Para o padrão mais amplo, a intervenção de baixo custo é colocar um atraso entre o momento em que um lançamento é publicado e quando ele é permitido para instalação. Aikido's Proteção de Dispositivos vem com uma retenção padrão de 48 horas para novas versões de pacotes e extensões, o que teria detectado o Nx Console (e a recente durabletask comprometimento do PyPI) sem que ninguém tivesse que identificá-lo como malicioso primeiro. Como indivíduo sem uma solução de fornecedor, o mais próximo que você pode fazer é desativar as atualizações automáticas de extensão no VS Code e atualizar em um cronograma deliberado. É mais lento, e você ficará atrasado nas versões legítimas por um ou dois dias. Esse é o preço de não executar o código recém-publicado de outras pessoas em seu laptop no momento em que o publicam.
O VS Code já oferece suporte à superfície de política subjacente para tornar isso uma configuração em nível de organização. O extensions.allowed uma política empresarial permite que os administradores restrinjam quais editores, extensões e até mesmo versões específicas podem ser instalados em dispositivos gerenciados. Uma opção de resfriamento (cooldown) além disso (algo como "apenas auto-instalar versões com mais de N horas") se encaixaria na mesma configuração. Não há uma boa razão técnica para que isso já não exista, e dada a frequência com que esses incidentes ocorrem no marketplace com o qual ele é fornecido, deveria existir. O mesmo vale para o Cursor e qualquer outro editor baseado em VS Code: se você já permite que as organizações apliquem uma lista de permissões (allowlist), também deve permitir que apliquem um período de resfriamento (cooldown).
A história do GitHub se estenderá por semanas porque a vítima é famosa, e o mesmo mecanismo subjacente continuará a produzir violações. Enquanto os marketplaces enviarem automaticamente atualizações de contas que podem ser comprometidas de uma dúzia de maneiras comuns, cada extensão popular estará a um token roubado de se transformar em um worm.
Aikido Device Protection
Se você deseja um período de resfriamento (cooldown) hoje, sem esperar que o VS Code ou o Cursor o implementem nativamente, Aikido Device Protection é o que recomendamos. Ele impõe uma política configurável de idade mínima (padrão de 48 horas) para instalações de pacotes e extensões no nível do dispositivo, de modo que a mesma política cubra qualquer editor baseado em VS Code que seus desenvolvedores utilizem.
