Olá a todos!
Há duas semanas escrevi aqui que o marketplace de extensões do VS Code era um campo minado e que mais cedo ou mais tarde íamos pagar a fatura. Ontem, dia 2 de Junho, o investigador Ammar Askar resolveu provar que eu fui simpático de mais na avaliação. Publicou um zero day, com prova de conceito completa e funcional, que rouba o token de OAuth do GitHub a partir de um único clique num link. Sem CVE atribuído. Sem patch. Sem aviso prévio à Microsoft, e já lá vamos perceber porquê.
O resumo para quem está com pressa e quer fechar o portátil em pânico: existe agora código público que, se vocês clicarem no link errado, instala silenciosamente uma extensão maliciosa no vosso editor e exfiltra um token que dá acesso de leitura e escrita a todos os repositórios a que a vossa conta tem acesso. Privados incluídos. Os da empresa incluídos. Aquele onde guardaram, sem querer, um ficheiro .env com segredos lá dentro também incluído.
O ataque inteiro demora menos de um minuto e não exige nenhuma interação vossa para além do clique inicial. Deixem isto assentar antes de continuarmos.
O pecado original chama se github.dev
Antes de explicar a mecânica, é preciso entender a peça central, porque sem ela nada disto faz sentido.
Vocês sabem que podem trocar github.com por github.dev no URL de qualquer repositório e, de repente, abre se uma versão do VS Code a correr dentro do browser. É giro. É prático. Edito um ficheiro, faço commit, nem instalo nada. A maravilha da web moderna.
O problema está no que acontece nos bastidores nesse instante. Quando abrimos um repositório no github.dev, o GitHub faz POST de um token de OAuth para essa sessão no browser, para que o editor consiga interagir com o GitHub em nosso nome. Faz sentido, certo? O editor precisa de poder fazer push, ler ficheiros, listar branches.
Só que aqui vem a parte que devia fazer parar qualquer pessoa que pensa em segurança por mais de cinco segundos: esse token não está limitado ao repositório que abrimos. Ele dá acesso completo, leitura e escrita, a todos os repositórios a que a nossa conta tem acesso. Estamos a abrir um repositório público qualquer para corrigir uma vírgula num README e o browser recebe, de bandeja, a chave mestra de tudo o resto.
Como alguém comentou no Hacker News de forma cirúrgica: era como ter um token com permissões de deus guardado em texto limpo, world readable, à espera que o pacote malicioso da semana o encontrasse. O github.dev nem devia estar autenticado na sessão completa do GitHub. Devia abrir com um token temporário, limitado àquele repositório, e ponto final. Mas não é assim que está feito, e é essa decisão de design que torna tudo o que se segue possível.
Como funciona o ataque, passo a passo
O Askar encadeou cinco comportamentos do VS Code que, isolados, parecem inofensivos. Juntos, dão isto. Vou explicar de forma que qualquer pessoa consiga acompanhar, porque a elegância (perversa) do ataque está precisamente em ser feito só com peças legítimas.
Primeiro, o atacante prepara um repositório armadilhado. Lá dentro mete um notebook de Jupyter, um ficheiro .ipynb, e uma pasta .vscode com uma definição de extensão local e um package.json que adiciona atalhos de teclado perigosos.
Segundo, a vítima clica num link de github.dev preparado de propósito, que abre esse notebook. Como o github.dev não implementa tokens de CSRF, qualquer link na internet pode atirar a vítima diretamente para dentro do ataque. Um link num email, num comentário, numa issue, numa mensagem de Discord. Qualquer um serve.
Terceiro, dentro do notebook há uma célula que injeta JavaScript. O truque é um clássico: uma tag de imagem em HTML com um handler onerror que executa código arbitrário dentro do iframe do webview. O webview, recordo, é a moldura onde o github.dev desenha aquela interface bonita do editor.
Quarto, e é aqui que a coisa fica diabólica, esse JavaScript espera que o github.dev carregue e depois dispara eventos sintéticos de teclado. Teclas falsas, geradas por código, que o editor interpreta como se vocês as tivessem premido. Primeiro um Ctrl+Shift+A, que corresponde ao comando “Notifications: Accept Notification Primary Action”, para aceitar automaticamente a extensão recomendada que o repositório sugere. Depois um atalho personalizado, do tipo Ctrl+F1, que invoca diretamente o comando que instala a extensão, saltando por cima da caixa de diálogo que normalmente nos avisa e nos pede confiança no publicador.
E porque é que salta esse aviso? Porque a extensão não vem do marketplace. O atacante coloca a a extensão diretamente na pasta .vscode/extensions/ do workspace. Como é local, o editor não mostra o diálogo de confiança no publicador que apareceria se a instalássemos a partir do marketplace oficial.
Quinto e último, a extensão maliciosa, agora instalada e ativa, acede ao token de OAuth que o github.dev guardou, consulta a API do GitHub para enumerar todos os repositórios da vítima, e exfiltra o que quiser. Em menos de um minuto. Com vocês a olhar para um notebook que parecia inofensivo.
E no desktop ainda é pior
Pensaram que o problema vivia só no browser? A vulnerabilidade afeta também o VS Code de desktop, aquele que está instalado na máquina de toda a gente que escreve código.
No desktop a vítima tem de clonar e abrir o repositório do atacante, o que adiciona um passo, mas em troca o prémio é maior: uma exploração bem sucedida escala para execução remota de código completa. RCE. Porque as extensões de VS Code têm acesso irrestrito às APIs de Node.js, incluindo o child_process, ou seja, podem correr comandos no sistema operativo sem limite nenhum.
Isto não é novidade absoluta para quem lê este blog. Eu já vos disse, e o Charlie Eriksen da Aikido disse antes de mim, que uma extensão de VS Code tem acesso a tudo na vossa máquina: credenciais, chaves de cloud, chaves SSH, tokens, variáveis de ambiente, tudo. Não há sandbox. O que o Askar fez foi pegar nesse facto desconfortável e mostrar um caminho prático para o explorar a partir de um único clique.
A parte política, porque há sempre uma
O Askar não reportou isto à Microsoft em privado. Divulgou tudo publicamente, prova de conceito incluída, e justificou a decisão com experiências anteriores más com o Microsoft Security Response Center.
Eu sei que isto vai dividir opiniões. Há quem ache que divulgar um zero day funcional sem dar tempo ao fornecedor é irresponsável. E há quem, como eu, depois de ver durante anos investigadores sérios a serem ignorados, minimizados, ou a receberem um “obrigado, não vale bounty” por bugs que valiam ouro, entenda perfeitamente a frustração.
A divulgação coordenada só funciona quando o lado de lá leva o processo a sério. Quando o fornecedor trata os reports como uma chatice de relações públicas em vez de um problema de engenharia, o investigador acaba por concluir que a pressão pública é a única alavanca que sobra. Não estou a aplaudir, estou a constatar. E a constatação é incómoda: o incentivo para a divulgação responsável depende inteiramente de quem recebe os reports comportar se à altura. Quando não se comporta, é isto que acontece.
O que isto tem em comum com tudo o resto que aqui escrevo
Se vos parece que já leram este filme, é porque leram. Há duas semanas foi uma extensão de VS Code envenenada que comprometeu o próprio GitHub. Antes disso o BitwardenGate. Antes a campanha contra a Checkmarx. O Megalodon e os milhares de repositórios envenenados num domingo à tarde.
O padrão é sempre o mesmo, e é por isso que continuo a martelar na mesma tecla até ficar com tendinite: a indústria inteira construiu o seu fluxo de trabalho em cima de ferramentas e plataformas em que confia de forma implícita, total, e quase religiosa. O marketplace é seguro porque é oficial. O github.dev é seguro porque é o GitHub. A extensão é segura porque tem boas reviews. O token está bem porque está no browser e o browser é seguro.
Cada uma destas suposições já foi desmentida. Repetidamente. E o que este zero day acrescenta é a demonstração de que nem sequer precisamos de instalar nada conscientemente para sermos comprometidos. Basta clicar. Num link. Como clicamos em cinquenta por dia.
O que devem fazer, hoje, sem desculpas
Chega de teoria. Parte prática, porque enquanto não há patch a responsabilidade é vossa.
Limpem já os dados do site github.dev no browser. Esta é a mitigação que o próprio investigador indica. No Chrome vão ao ícone na barra de endereço, depois a Cookies e dados do site, depois Gerir dados do site no dispositivo, e apaguem tudo o que pertença a domínios github.dev. Ao fazerem isto, da próxima vez que um link tentar explorar a falha vão receber o aviso “A extensão ‘GitHub Repositories’ quer iniciar sessão usando o GitHub”, em vez de a sessão acontecer em silêncio. Esse aviso é a vossa rede de segurança até existir correção oficial.
Não cliquem em links de github.dev que não conhecem. Sei que soa a conselho de avozinha, mas neste caso é literalmente o vetor. Um link de github.dev que apareça num sítio inesperado é, até prova em contrário, uma armadilha. Tratem como tal.
Auditem as extensões de VS Code instaladas, outra vez. Sim, eu sei que já vos disse isto há duas semanas. Volto a dizer porque continua a ser verdade e porque a maioria de vós não fez nada. Quantas extensões têm? Quem as publicou? Quando foram atualizadas? Removam tudo o que não usam.
Considerem que os vossos tokens podem já ter sido vistos. Se andaram a usar o github.dev em máquinas onde clicaram em links de proveniência duvidosa, rodem os tokens de acesso e revejam as sessões ativas e as aplicações autorizadas na vossa conta do GitHub. Mais vale a paranóia barata do que o arrependimento caro.
E sim, montem um espelho do vosso código fora do GitHub. Já estavam à espera, eu sei. Um git clone --mirror num cron diário para um NAS ou para uma instância de Gitea ou Forgejo que vocês controlam custa meia hora de setup e zero euros se já têm hardware. O dia em que precisarem disto não vão ter tempo de o montar.
Nota final
A ironia que não consigo deixar passar é que o github.dev é uma feature de conveniência. Foi feita para nos poupar dois cliques, para podermos editar um ficheiro sem abrir o editor local. E é precisamente essa conveniência, essa decisão de meter um editor completo dentro do browser, autenticado com um token que abre tudo, que abriu a porta.
A segurança e a conveniência estão quase sempre em lados opostos da balança. De cada vez que uma plataforma nos oferece algo “sem fricção”, vale a pena perguntar onde é que a fricção foi parar. Porque ela não desaparece. Apenas muda de sítio, e muitas vezes vai parar exatamente ao sítio onde um atacante a sabe encontrar.
Limpem os cookies do github.dev. Façam o espelho do código. E da próxima vez que clicarem num link bonito que abre um editor no browser, lembrem se de que, naquele instante, podem estar a entregar a chave de casa a um estranho que nem sequer precisou de bater à porta.
Fiquem atentos.
Um abraço,
Nuno Higgs
Fontes:
- BleepingComputer, VS Code zero day lets hackers steal GitHub tokens in one click (2 Junho 2026)
- Ammar Askar, prova de conceito e divulgação técnica (2 Junho 2026)
- Hacker News, discussão da comunidade sobre o token e o github.dev
- Este blog, O GitHub foi hackeado por uma extensão de VS Code envenenada (20 Maio 2026)