CVE-2026-70336: um link envenena o próximo processo Node no VS Code Web

Nem toda execução remota começa quando a vítima clica. Na CVE-2026-70336, o link malicioso altera silenciosamente uma sessão web do VS Code e deixa o gatilho preparado no ambiente do terminal remoto. A carga só roda depois, quando o desenvolvedor executa um comando Node.js rotineiro. Essa separação entre entrega e execução torna a cadeia discreta e pode fazer o evento parecer uma ação normal de desenvolvimento.

O advisory do próprio projeto classifica a falha como alta, com CVSS 3.1 de 8,8. Versões anteriores à 1.132.1 são afetadas. A exploração exige interação do usuário, mas não exige privilégio prévio do atacante, tem baixa complexidade e pode comprometer confidencialidade, integridade e disponibilidade no contexto da conta que executa o servidor remoto.

O que foi confirmado oficialmente

A Microsoft publicou o GHSA-fp6w-v29h-43rj em 11 de agosto de 2026 e associou o caso à CVE-2026-70336. O cenário descrito é específico: um usuário de code-server é induzido a abrir uma URL preparada, essa URL altera a sessão e o próximo comando Node.js iniciado no terminal executa código controlado pelo atacante. O vetor oficial é CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

• Afetadas: versões do VS Code anteriores à 1.132.1
• Corrigida: versão 1.132.1
• Vetor inicial: link criado pelo atacante e aberto pelo usuário
• Gatilho de execução: um comando Node.js iniciado posteriormente no terminal remoto
• Pontuação oficial: CVSS 3.1 de 8,8, severidade alta
• Interação necessária: sim, o usuário precisa abrir o link

A cadeia técnica: da URL ao processo

Segundo o advisory, três fronteiras falharam em sequência. Opções privilegiadas de desenvolvimento de extensão podiam chegar por payloads de URL em builds de produção. Valores não confiáveis do cliente alcançavam o ambiente do terminal remoto. Por fim, esses valores conseguiam sobrescrever variáveis usadas na inicialização do extension host. O título do advisory identifica a variável decisiva: NODE_OPTIONS.

# Benign local demonstration of documented Node.js behavior.
# This does not exercise the VS Code vulnerability or use a crafted URL.

printf 'console.log("preloaded before the application")\n' > /tmp/vorvex-node-preload.js
NODE_OPTIONS='--require /tmp/vorvex-node-preload.js' \
  node -e 'console.log("application started")'
rm /tmp/vorvex-node-preload.js

# Expected order:
# preloaded before the application
# application started

O Node.js documenta que as opções em NODE_OPTIONS são interpretadas antes das opções da linha de comando. Entre as opções permitidas está --require, capaz de pré-carregar um módulo. Portanto, se uma origem não confiável controla essa variável no ambiente do terminal, o próximo node, npm ou ferramenta baseada em Node pode iniciar com código adicional antes da tarefa esperada. O trecho acima demonstra apenas esse comportamento oficial em uma máquina local; ele não reproduz a falha do VS Code.

Por que o navegador não limita o impacto

O VS Code for the Web isolado roda dentro do sandbox do navegador e oferece um ambiente de execução limitado. Isso muda quando a interface web está conectada por Remote Tunnels ou VS Code Server. Nesse modo, comandos e extensões são executados na máquina remota. A documentação da Microsoft deixa claro que o servidor roda com o mesmo usuário usado para entrar na máquina.

Por isso, o impacto não fica preso à aba. O processo Node.js nasce no host de desenvolvimento e herda o alcance daquela conta: código-fonte, credenciais presentes no ambiente, tokens de registries, chaves acessíveis pelo usuário e conectividade interna disponível para a máquina. A CVSS mantém escopo inalterado porque a execução ocorre dentro da autoridade do componente e do usuário afetados, não porque o dano seja pequeno.

• Repositórios e alterações locais ainda não enviados ao controle de versão
• Tokens de npm, Git e serviços de CI acessíveis à conta de desenvolvimento
• Credenciais de nuvem ou kubeconfig presentes no host remoto
• Acesso de rede a bancos, painéis e serviços internos alcançáveis pelo ambiente
• Capacidade de modificar dependências, scripts de build e artefatos produzidos depois do comprometimento

Como testar sem transformar o pentest em phishing

A confirmação mais segura começa por versão e arquitetura, não pelo envio de um link real. Em um pentest autorizado, inventariamos quais equipes usam VS Code no navegador, quais sessões alcançam hosts persistentes e qual identidade executa o servidor. Depois verificamos se cada componente em execução já está na 1.132.1 ou posterior. A demonstração de NODE_OPTIONS pode ser feita em laboratório isolado com o módulo benigno mostrado acima.

# Run in each authorized VS Code client or server environment.
code --version

# The first line must report 1.132.1 or a later release.
# Also verify the version shown by the active remote session instead of
# assuming that an updated desktop client updated every remote server.

# Read-only triage in exported proxy or browser-navigation logs.
# Results are leads for investigation, not proof of exploitation.
rg -i 'NODE_OPTIONS|NODE_OPTIONS%3D|NODE_OPTIONS%253D' \
  exported-vscode-access.log exported-browser-history.txt

Não recomendamos mandar a URL de exploração para desenvolvedores, nem mesmo como simulação surpresa. Além do risco operacional, o gatilho atrasado dificulta garantir quando e onde o código será executado. Se o cliente exigir prova dinâmica da CVE, ela deve ocorrer com conta, servidor, repositório e credenciais descartáveis, horário combinado e módulo sem efeito além de registrar um marcador controlado.

Correção e contenção

A correção está na versão 1.132.1. De acordo com o advisory, o patch rejeita opções privilegiadas de desenvolvimento de extensão vindas de payloads de URL em builds de produção, sanitiza valores não confiáveis do ambiente do terminal remoto e impede que valores fornecidos pelo cliente sobrescrevam variáveis de bootstrap do extension host. São três controles independentes na mesma cadeia, uma abordagem adequada para evitar que uma única validação esquecida reabra o caminho.

• Atualize VS Code e os componentes de servidor remoto para 1.132.1 ou posterior
• Confirme a versão na sessão remota ativa, não apenas no notebook do desenvolvedor
• Até atualizar, não abra URLs de VS Code Web recebidas de origem não confiável
• Restrinja o acesso a implantações web confiáveis, conforme a mitigação oficial
• Encerre sessões suspeitas e abra um novo terminal para descartar ambiente herdado
• Se houver indício de execução, trate como comprometimento da conta do host e rotacione os segredos acessíveis a ela

O que muda na revisão de ambientes de desenvolvimento

Ambiente remoto de desenvolvimento não é só uma IDE publicada. Ele é uma ponte autenticada até uma máquina capaz de compilar, assinar, acessar dependências privadas e conversar com a rede interna. O teste precisa acompanhar dados que atravessam essa ponte: parâmetros de URL, mensagens do cliente, configuração de extensões, variáveis herdadas e processos filhos.

• Inclua VS Code Server, Remote Tunnels e IDEs web no inventário de ativos críticos
• Teste se dados do cliente conseguem alterar ambiente de terminal ou opções de inicialização
• Separe o host de desenvolvimento das credenciais de produção sempre que possível
• Aplique privilégio mínimo aos tokens de package registry, Git, nuvem e CI
• Colete telemetria de criação de processos e alterações de ambiente nos hosts mais sensíveis
• Trate links profundos de ferramentas de desenvolvimento como entrada não confiável

A lição da CVE-2026-70336 é direta: uma interface no navegador pode terminar em execução no servidor sem que o usuário veja a transição de confiança. Um pentest que olha apenas para a página perde o caminho mais importante. É preciso seguir a entrada até o ambiente herdado pelo processo que realmente executa o código.