GitHub Invadido: Extensão VS Code Vazou 3.800 Repositórios

GitHub invadido. A frase que ninguém na cadeia de fornecedores de software queria ler chegou em 20 de maio de 2026, quando a própria GitHub confirmou que atacantes exfiltraram cerca de 3.800 repositórios internos depois que um funcionário instalou uma extensão maliciosa do Visual Studio Code. Não foi falha de senha, não foi 0-day no Git: foi a sua IDE, com permissões de usuário, fazendo o que IDEs sempre fizeram — só que para o lado errado. Este post desmonta o ataque, mostra o que foi vazado de fato e dá o passo a passo para você não ser o próximo elo quebrado.

TL;DR — o que importa em 60 segundos

• GitHub invadido em 20/05/2026: o grupo TeamPCP exfiltrou cerca de 3.800 repositórios internos via extensão VS Code envenenada na máquina de um funcionário.
• Dados de clientes não foram tocados — segundo o GitHub. Mas topologia interna, lógica de rotação de segredos e pipelines de CI vazaram.
• O vetor é IDE, não Git. Extensões rodam com privilégio do seu usuário: leem ~/.aws, ~/.kube, tokens do gh, sessões do gerenciador de senha.
• TeamPCP é reincidente: já comprometeu Trivy, Checkmarx KICS, LiteLLM e a Comissão Europeia. Pede US$ 50 mil pelo dump do GitHub em fórum.
• Sua ação hoje: auditar extensões instaladas, remover não-assinadas, rotacionar tokens críticos e ativar telemetria de clone em massa.

O que aconteceu, em ordem cronológica

A história começou silenciosa, como sempre começa. Um colaborador do GitHub baixou uma extensão do Visual Studio Code Marketplace que se passava por uma ferramenta legítima de produtividade. A partir daí, a extensão fez o que extensões podem fazer: leu arquivos do projeto aberto, buscou credenciais em diretórios padrão, exfiltrou tokens. Em algum momento entre a primeira chamada de comando-e-controle e o alerta da equipe de segurança, o atacante clonou repositórios inteiros para fora.

Na madrugada de 20 de maio, em uma thread de cinco posts no X, o GitHub confirmou: GitHub invadido, perímetro interno comprometido. O número informado bate com a alegação do TeamPCP em fóruns clandestinos: 3.800 repositórios. A empresa afirma ter "detectado e contido" o incidente, sem detalhar a janela exata entre intrusão e contenção — um silêncio que diz muito.

A linha do tempo pública

• Antes de maio/2026: TeamPCP coleta vítimas em uma campanha contínua de envenenamento de extensões e pacotes (npm, PyPI, Composer).
• Início de maio/2026: funcionário do GitHub instala a extensão maliciosa do Marketplace.
• Janela X: atacantes movimentam-se lateralmente, clonam cerca de 3.800 repos internos.
• 20/05/2026 (madrugada): GitHub publica o aviso em thread oficial no X.
• 20-23/05/2026: TeamPCP coloca o pacote à venda por US$ 50 mil mínimo em fórum clandestino.

Anatomia do ataque: por que uma extensão vence um SSO

Você fortalece autenticação, exige FIDO2 em tudo, faz code review obrigatório. E aí instala uma extensão de syntax highlight. O detalhe que tornou o GitHub invadido viável é simples: extensões VS Code rodam no mesmo contexto de usuário do editor. Elas têm acesso a:

1. Todo arquivo aberto na workspace — e qualquer outro que o processo do VS Code consiga ler com a sua permissão.
2. Variáveis de ambiente do shell que iniciou o editor — inclusive GITHUB_TOKEN, AWS_ACCESS_KEY_ID, segredos injetados via direnv.
3. Diretórios sensíveis: ~/.aws/credentials, ~/.kube/config, ~/.ssh/, sessões persistentes do gh auth, vaults do pass.
4. Conexões de rede de saída irrestritas — o Marketplace não exige declaração granular de permissões como Android ou iOS.
5. Capacidade de spawnar processos: git clone, curl, node, qualquer binário disponível no PATH.

Não há sandbox. Não há prompt de permissão como em apps móveis. Você instala, ela roda. Esse é o "Yes, I trust the author" do .vscode — herdado do modelo de plugin pesado que VS Code mantém por compatibilidade com extensões legítimas que precisam desse poder (linters, debuggers, Language Servers).

Por que o Marketplace é um vetor confortável

A Microsoft assina o canal mas não audita o código de cada extensão. São mais de 60 mil pacotes ativos, atualizações automáticas e pseudo-anonimato de publisher. O terreno é convidativo para typosquatting (clones com nomes parecidos), squatting de versão (extensão legítima abandonada e republicada por outro) e dependency confusion no package.json interno do plugin.

Quem é o TeamPCP e por que isso importa

TeamPCP não é amador. O grupo já comprometeu, em 2026:

• Trivy, o scanner de vulnerabilidade da Aqua Security.
• Checkmarx KICS, ferramenta de IaC scanning.
• LiteLLM, proxy popular para LLMs.
• Comissão Europeia em fevereiro.
• Pacotes npm e PyPI em ondas mensais ao longo do trimestre.

A assinatura técnica do grupo é supply chain de ferramentas de desenvolvedor — exatamente o tipo de software que você instala uma vez e nunca mais audita. Quando o atacante mira a IDE, ele mira o ponto onde código, credenciais e confiança convergem. O GitHub invadido é só o caso mais visível dessa estratégia.

O preço pedido (US$ 50 mil pelo dump completo) sugere mercado já validado: alguém compra. Esse alguém vai usar o conteúdo para escrever malware que entende a arquitetura interna do GitHub, gerar provas de conceito de ataque a clientes da plataforma e identificar endpoints internos sem rate-limit. Não é hype: é um amplificador real de risco a jusante.

Os 3.800 repositórios — o que de fato vazou no GitHub invadido

O GitHub afirma que dados de clientes não foram tocados. Acredite, mas qualifique: o que estava nos repositórios internos é, conforme padrões públicos de empresas como o GitHub, exatamente o que você não quer fora:

• Topologia de deployment (regions, fallbacks, blast radius por serviço).
• Lógica de rotação de segredos (frequência, mecanismos, quem dispara).
• Workflows de CI/CD (steps escondidos, integrações com cofres, runners custom).
• Referências a integrações de terceiros e SLAs internos.
• Snippets de código com TODOs do tipo // FIXME: rate limit aqui está fraco.

Mesmo sem nenhum segredo de cliente exposto, isso vira mapa de calor para ataques futuros. Para quem opera o próprio SaaS ou plataforma, a lição é direta: o repositório interno é um ativo de segurança, não só de engenharia.

Por que sua empresa é alvo, mesmo sem ser o GitHub

Você não precisa hospedar 100 milhões de devs para entrar no radar. O mesmo vetor que deixou o GitHub invadido funciona em qualquer estação de desenvolvedor mundo afora. Três cenários típicos onde ele pega PMEs e times pequenos:

1. Freelancer com extensão envenenada termina projeto cliente; tokens AWS e GitHub do cliente saem junto.
2. Time pequeno usa Cursor ou Windsurf (forks do VS Code) sem auditoria de extensões; superfície idêntica.
3. Onboarding de novo dev clona repo, instala "VS Code pack recomendado pela equipe" — pack inclui dependência transitiva maliciosa.

A defesa não é parar de usar IDE moderna. É tratar a IDE como endpoint produtivo sob o mesmo regime de qualquer servidor de produção: inventariada, monitorada, com baseline declarada e revisão de mudança.

Como auditar e endurecer suas extensões VS Code agora

O playbook abaixo é o que evitaria o cenário de GitHub invadido na sua casa. Não vou pregar "remova tudo e use Notepad". O que funciona, em ordem de impacto:

Inventário em 10 minutos

Rode code --list-extensions --show-versions > extensions-baseline.txt em cada estação. Versione esse arquivo no repositório de infra do time. Qualquer diff em pull request vira sinal — instalações silenciosas, downgrade suspeito, extensão nova sem ticket.

Remoção do excesso

A regra prática: se você não usou a extensão nos últimos 90 dias, desinstale. Cada plugin é capacidade adicional para o atacante; manter os 30 favoritos do hype passado é dívida de superfície, não conveniência.

Política de publisher

Permita apenas publishers verificados, organizações conhecidas, ou extensões com mais de 1 milhão de downloads E histórico de 12 meses. Você fecha quase todo o espaço de typosquatting com esses três filtros simples.

Segregação de credenciais

Pare de manter tokens long-lived em ~/.aws/credentials ou variável de ambiente perene. Use SSO federado (AWS IAM Identity Center), gh auth login com refresh curto, 1Password CLI ou doppler para injetar segredos efêmeros via shell. O atacante que ler seu disco encontra arquivos vazios.

Workspaces isoladas

Para clientes sensíveis ou repositórios privados, abra em Dev Containers. A extensão maliciosa, mesmo se instalada no host, fica fora do contexto do container — onde estão suas chaves do cliente.

Telemetria de clone em massa

Na sua organização do GitHub, ative auditoria de eventos repo.clone e alerte para volumes anormais por usuário. Se um colaborador clonou 80 repos em 12 minutos, isso é o atacante, não a pessoa.

Comparativo: práticas seguras vs. perigosas no IDE

Prática	Risco	Defesa equivalente
Tokens long-lived em ~/.aws/credentials	Exfiltração instantânea ao primeiro plugin malicioso	SSO federado + sessão de 8h
Aceitar "Trust this workspace" sem ler	Execução automática de tasks do .vscode/tasks.json	Workspace Trust + revisão manual
Instalar extensão por screenshot do Stack Overflow	Typosquatting de nome similar	Verificar publisher + downloads + idade
code --install-extension em script de onboarding sem pin	Versão envenenada em qualquer release	Pin de versão + checksum em CI
Editar repo de cliente no mesmo perfil pessoal	Vazamento cruzado de credenciais	Profiles do VS Code ou Dev Containers
Atualização automática de extensões	Patch malicioso entra sem revisão	extensions.autoUpdate: false

O ângulo IA: por que o problema piora com Copilot, Cursor e agentes

Se o GitHub invadido em 2026 foi possível com extensão tradicional, imagine a superfície quando a IDE passa a ser também runtime de IA. A maior mudança do ano foi a IDE virar plataforma de execução de agentes. Copilot, Cursor Chat, Windsurf, Continue.dev, JetBrains AI Assistant — todos rodam com permissões da IDE, fazem chamadas de rede contínuas, processam contexto de toda a workspace.

Isso muda a equação de risco em três pontos:

1. Superfície ampliada: cada agente é uma extensão a mais com permissões totais.
2. Output como ataque: uma extensão maliciosa pode injetar texto no prompt do agente, fazendo o LLM gerar código que parece bom mas tem backdoor sutil. Você revisa, o LLM "concorda", o código entra em main.
3. Telemetria opaca: agentes legítimos já mandam pedaços de código para clouds de provedor. Extensão maliciosa imita o tráfego e se esconde no ruído.

A resposta não é abandonar IA na IDE — perderíamos produtividade demais. A resposta é tratar agente como terceiro processo, com logging dedicado e cofre de credenciais isolado. Quem trabalha com modelos próprios (Llama 3, Mistral) tem vantagem aqui: dá para isolar o tráfego de agente em endpoint controlado, sem depender de fornecedor externo. Falamos sobre a lógica de "dono do stack ganha resiliência" em aplicativo Moodle personalizado vs app oficial, onde o mesmo princípio se aplica a outro tipo de produto digital.

E se eu já fui comprometido?

Assumindo a hipótese mais paranoica — você instalou a mesma classe de extensão que deixou o GitHub invadido — eis os sintomas a procurar nos próximos 30 dias:

• Logins MFA não solicitados em GitHub, AWS ou GCP.
• Repositórios seus aparecendo como fork em contas que você não conhece.
• Pacotes seus em npm ou PyPI com versões patch que você não publicou.
• Pull Requests automatizados com mudanças pequenas em workflow files (.github/workflows/*).
• Cobrança anômala em provedor de LLM — alguém usou sua API key.

A resposta padrão é dura mas necessária: rotacionar todas as credenciais que passaram pela máquina suspeita, em ordem de impacto (cloud → git → email → senhas pessoais), revogar sessões ativas em todos os SaaS, e provisionar uma estação limpa para reinstalar IDE com inventário fechado. Backup de configuração não vale — pode trazer o veneno junto.

Para quem opera comunicação com clientes na mesma rede (WhatsApp, email transacional), revise também credenciais de canal. Vimos times perdendo número WhatsApp por reuso de tokens entre ambientes quando trocam de provedor, situação que tratamos em markup nas mensagens WhatsApp.

Conclusão: a IDE é o novo perímetro

O GitHub invadido em maio de 2026 não foi um pico de azar — foi a consequência previsível de tratar IDE como espaço pessoal num mundo onde IDE é infraestrutura. Repare na cronologia: as próximas manchetes de "GitHub invadido" vão se parecer estruturalmente com essa. O atacante mais inteligente do trimestre não escreveu exploit. Escreveu extensão.

A boa notícia: as defesas são banais. Inventariar, restringir publisher, segregar credencial, isolar workspace, ativar telemetria de clone. Nenhuma exige comprar produto novo, todas cabem numa sprint. A má notícia: até a maioria dos times fazer o trabalho, o TeamPCP — ou o próximo grupo no lugar dele — continua tendo a melhor margem entre esforço e payout do mercado.

Comece pelos cinco minutos mais baratos: rode code --list-extensions agora, mande pro Slack do time, compare com colegas. Tudo que aparecer e ninguém reconhecer é o primeiro item da auditoria de amanhã.

Acompanhamos esse caso pela rotina diária de manter agathas.com.br segura e os clientes em pé. Se o seu time precisa de uma revisão objetiva de superfície de ataque em IDE e CI, fale com a gente — mostramos onde mexer primeiro.