Ataque à cadeia de suprimentos do VS Code expõe falhas críticas nos bloqueios de extensões

O ataque à cadeia de suprimentos do VS Code não é um evento isolado, é o ponto mais recente de uma campanha coordenada do TeamPCP que já comprometeu Nx Console, Checkmarx KICS, Trivy e GitHub Actions em menos de dois meses. A extensão maliciosa da Nx Console (18.95.0), distribuída por apenas 18 minutos no Marketplace, foi capaz de exfiltrar 3.800 repositórios internos do GitHub porque o VS Code executa extensões sem sandboxing e com privilégios completos do usuário. Isso significa que qualquer código carregado, seja via marketplace, CDN ou cópia direta para .vscode/extensions, tem acesso irrestrito a chaves SSH, tokens OAuth, variáveis de ambiente e pipelines de CI/CD.

A falha crítica aqui não está no VS Code como produto, mas na falsa segurança gerada por políticas superficiais: bloquear o domínio marketplace.visualstudio.com ignora que as extensões são servidas via CDN com URLs previsíveis (ex: vscode.blob.core.windows.net), e que o diretório .vscode/extensions é gravável por qualquer processo local. O CVE-2026-48027, atribuído pela CISA, confirma que a atualização automática do VS Code pode instalar binários sem interação humana, o que torna inútil qualquer política baseada em 'não instalar extensões'. A defesa real começa com validação de assinatura obrigatória (não só do marketplace, mas de cada arquivo .vsix antes da extração) e monitoramento contínuo de escrita nesse diretório, algo que ferramentas como Sysmon ou EDRs empresariais conseguem detectar, mas raramente estão configuradas para isso.

Em 3 de junho, o CEVIU já havia reportado o roubo de tokens GitHub via bug no webview do VS Code, mas era uma vulnerabilidade pontual de renderização. Agora, a ameaça evoluiu para um ataque estrutural à cadeia de suprimentos: não depende de bug no código-fonte, mas explora o modelo de implantação do VS Code por design. Antes, o foco estava em *como* as extensões eram injetadas (ex: GitHub Actions inseguras). Hoje, o ataque acontece *após* a instalação, porque o próprio mecanismo de atualização automática é usado como vetor. A diferença prática é que, em abril, bastava auditar workflows; agora, é preciso bloquear gravação em .vscode/extensions, validar assinaturas criptográficas de todos os arquivos .vsix e isolar o ambiente de desenvolvimento como se fosse produção.

Desenvolvedores não são usuários finais, são porteiros da infraestrutura. Uma extensão maliciosa no VS Code pode ler ~/.aws/credentials, acessar repositórios privados via SSH, injetar credenciais em pipelines do GitHub Actions e até modificar artefatos Docker antes do push. Isso transforma máquinas de desenvolvimento em pivôs para ataques de movimento lateral. Empresas que tratam IDEs como ferramentas neutras estão expostas: o ataque ao GitHub não veio por um servidor desatualizado, mas por um laptop com VS Code e uma única extensão trojanizada. A consequência imediata é que políticas de segurança devem migrar de 'bloquear acesso à internet' para 'controlar execução local', com WDAC no Windows, seccomp-bpf no Linux e listas de permissão rigorosas para extensões, não apenas no marketplace, mas em todo ciclo de vida do arquivo.