Um Funcionário Instalou a Extensão Errada

Na segunda-feira, 19 de maio de 2026, o GitHub confirmou publicamente algo que parecia roteiro de filme: um de seus próprios engenheiros instalou uma extensão envenenada do VS Code, e isso abriu a porta para que hackers roubassem cerca de 3.800 repositórios internos da plataforma. O código-fonte do GitHub Copilot, ferramentas de red team, e até release notes do GitHub Enterprise Server — tudo exfiltrado.

O grupo responsável atende pelo nome de TeamPCP (também rastreado como UNC6780), e não é novato no jogo. Já comprometeram o Trivy da Aqua Security, o KICS da CheckMarx, o LiteLLM, o SDK da Telnyx, e pacotes do TanStack e da MistralAI. O padrão é sempre o mesmo: atacar a cadeia de suprimentos de software por onde ninguém está olhando.

Como o Ataque Funcionou

A mecânica é brutal na sua simplicidade.

Extensões do VS Code não são plugins inofensivos. Elas rodam com acesso total à máquina do desenvolvedor — arquivos locais, terminais, tokens de autenticação, chaves SSH, variáveis de ambiente. Quando você instala uma extensão, está dando permissão para que código arbitrário execute no seu ambiente de trabalho.

O TeamPCP conseguiu comprometer uma extensão legítima no Marketplace do VS Code. Não criaram uma extensão nova com nome parecido (typosquatting clássico). Eles sequestraram a infraestrutura de publicação de uma extensão já existente e publicaram uma versão maliciosa por cima.

O fluxo do ataque:

1. A extensão comprometida foi publicada no Marketplace oficial
2. Um engenheiro do GitHub instalou (ou atualizou) a extensão normalmente
3. O payload embutido começou a coletar credenciais silenciosamente — arquivos .env, tokens OAuth, chaves de API, tudo que existia na máquina
4. Com as credenciais administrativas em mãos, os atacantes acessaram os repositórios internos do GitHub
5. Aproximadamente 3.800 repos foram exfiltrados

O GitHub não divulgou o nome da extensão. Mas pesquisadores de segurança como Charlie Eriksen destacaram que “extensões do VS Code têm acesso total a tudo na máquina do desenvolvedor, incluindo credenciais, chaves de cloud e chaves SSH.”

O Que Foi Roubado

Segundo o TeamPCP, o pacote roubado inclui:

O grupo colocou o material à venda em fóruns de cibercrime por US$ 50.000 — e ameaçou vazar tudo publicamente caso não encontrasse comprador.

Pense na ironia: o código-fonte das ferramentas de red team do GitHub — as mesmas ferramentas usadas para testar a segurança da plataforma — agora está nas mãos de criminosos. É como roubar o manual do cofre.

A Resposta do GitHub

O GitHub agiu relativamente rápido. Segundo o comunicado oficial:

“Removemos a versão maliciosa da extensão, isolamos o endpoint comprometido e iniciamos a resposta a incidentes imediatamente. Segredos críticos foram rotacionados ontem e durante a noite, com as credenciais de maior impacto priorizadas primeiro.”

A empresa também afirmou que, até o momento, não há evidências de que dados de clientes armazenados fora dos repositórios internos tenham sido comprometidos. A palavra-chave aqui é “até o momento” — a investigação ainda está em andamento.

Mas vamos ser realistas: 3.800 repositórios internos não são pouca coisa. Mesmo que dados de clientes não tenham vazado diretamente, código-fonte interno pode conter:

• Lógica de autenticação e autorização
• Endpoints de API não documentados
• Configurações de infraestrutura
• Vulnerabilidades zero-day ainda não corrigidas

Esse tipo de informação é ouro para qualquer atacante que queira explorar a plataforma no futuro.

TeamPCP: Quem São Esses Caras?

O TeamPCP (UNC6780) é um grupo de cibercrime especializado em ataques à cadeia de suprimentos de software. A estratégia é consistente: em vez de atacar o alvo diretamente, eles envenenam as ferramentas que os desenvolvedores usam no dia a dia. Não é força bruta. É engenharia social em escala industrial.

Ataques anteriores confirmados:

• Trivy (scanner de segurança da Aqua Security) — comprometido via dependência maliciosa
• KICS (CheckMarx) — mesma tática, outro alvo de segurança
• LiteLLM — 97 milhões de downloads comprometidos (já cobrimos isso aqui no CodeInsider)
• SDK da Telnyx — usado por milhares de empresas de telecom
• Pacotes TanStack e MistralAI — bibliotecas populares no ecossistema JavaScript/Python

Percebe a escolha dos alvos? Não são projetos aleatórios. O TeamPCP mira especificamente em ferramentas de segurança e infraestrutura de IA — exatamente as ferramentas que empresas de tecnologia confiam cegamente porque “são de segurança, logo devem ser seguras.” A ironia é quase poética.

O padrão operacional também é revelador: eles não mantêm acesso persistente por meses como grupos APT tradicionais. A estratégia é smash-and-grab — comprometer, exfiltrar o máximo possível em horas, e monetizar rápido. Isso dificulta a detecção porque o tempo de exposição é curto, mas o estrago já foi feito.

Por Que Extensões do VS Code São Um Pesadelo de Segurança

Eu já perdi a conta de quantas vezes escrevi sobre supply chain attacks aqui, mas essa merece destaque porque expõe um problema que a maioria dos devs ignora.

O VS Code é o editor mais usado do mundo. Segundo o Stack Overflow Survey, mais de 73% dos desenvolvedores usam VS Code como editor principal. O Marketplace tem mais de 50.000 extensões — e o processo de verificação é, digamos, generoso.

Diferente de lojas de apps mobile, onde existe um processo de review (mesmo que imperfeito), o Marketplace do VS Code é essencialmente self-service. Qualquer pessoa pode publicar uma extensão. E uma vez instalada, ela roda com os mesmos privilégios do usuário.

# O que uma extensão maliciosa pode acessar:
~/.ssh/                    # Chaves SSH
~/.aws/credentials         # Credenciais AWS
~/.kube/config             # Configs Kubernetes
~/.gitconfig               # Configuração Git + tokens
.env                       # Variáveis de ambiente
~/.docker/config.json      # Registry Docker
$HISTFILE                  # Histórico do shell

Não existe sandbox. Não existe isolamento. Quando você clica “Install” numa extensão do VS Code, está confiando cegamente que aquele código não vai roubar suas credenciais.

E antes que alguém argumente “mas eu só instalo extensões populares” — foi exatamente isso que o engenheiro do GitHub fez. A extensão era legítima até ser comprometida.

O Caso Nx Console Como Referência

Para quem quer entender a mecânica, vale olhar o caso da extensão Nx Console que aconteceu na mesma época. Foram apenas 2.777 bytes de JavaScript malicioso — menos de 3KB — que silenciosamente coletavam credenciais no momento em que o desenvolvedor abria qualquer workspace.

Não precisou de exploit sofisticado. Não precisou de zero-day. Bastou 3KB de código numa extensão que os devs já confiavam.

E esse é o ponto que mais me incomoda nessa história toda: a barreira de entrada para esse tipo de ataque é absurdamente baixa. Qualquer desenvolvedor JavaScript com conhecimento intermediário consegue escrever um credential harvester em menos de 50 linhas. A parte difícil nunca foi o código — foi conseguir distribuir o malware. E o Marketplace do VS Code resolve esse problema de graça.

O Que Isso Significa para Você

Se você usa VS Code (e provavelmente usa), aqui vai o que precisa fazer agora:

1. Audite suas extensões instaladas

# Liste todas as extensões instaladas
code --list-extensions

# Verifique quando cada uma foi atualizada pela última vez
# Extensões que atualizaram recentemente sem changelog claro = red flag

2. Implemente políticas de extensão na sua empresa

O VS Code suporta políticas de extensão via settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false,
  "extensions.ignoreRecommendations": true
}

Desabilitar auto-update dá a você uma janela para verificar o que mudou antes de atualizar.

3. Use o VS Code em sandbox

Ferramentas como Dev Containers ou GitHub Codespaces isolam seu ambiente de desenvolvimento. Se uma extensão for comprometida, ela só tem acesso ao container — não à sua máquina inteira.

// devcontainer.json
{
  "name": "Secure Dev",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "customizations": {
    "vscode": {
      "extensions": [
        // Apenas extensões aprovadas
        "ms-python.python",
        "dbaeumer.vscode-eslint"
      ]
    }
  }
}

4. Monitore o que suas extensões fazem

A extensão Extension Total da Aikido Security analisa extensões instaladas e detecta comportamentos suspeitos. Não é perfeito, mas é melhor que nada.

5. Considere alternativas com melhor modelo de segurança

Editores como Zed (que lançou a versão 1.0 recentemente) estão repensando o modelo de extensões. O Neovim, por sua vez, tem um ecossistema onde plugins são repositórios Git auditáveis — não blobs binários num marketplace centralizado.

A Supply Chain Está Quebrada

Esse incidente é mais um capítulo na mesma história que estamos acompanhando há anos: a cadeia de suprimentos de software é o elo mais fraco da segurança moderna.

O padrão se repete: atacantes não tentam invadir seu firewall. Eles envenenam as ferramentas que você voluntariamente instala, confiando que o ecossistema é seguro.

E o mais preocupante: se o próprio GitHub — uma empresa da Microsoft com bilhões em recursos de segurança — foi vítima, o que dizer da sua startup de 15 pessoas?

O Marketplace Precisa Mudar

A Microsoft precisa repensar fundamentalmente o modelo de segurança do VS Code Marketplace. Algumas medidas que fariam diferença imediata:

• Hold obrigatório de 48 horas para novas versões de extensões populares (>100K instalações)
• Sandbox real para extensões, limitando acesso ao filesystem e rede
• Assinatura de código verificável — se uma extensão muda de maintainer, o usuário precisa saber
• Análise estática automatizada de cada versão publicada, não apenas scan de malware básico
• Logs de acesso visíveis para o desenvolvedor — o que cada extensão acessou na última sessão

Enquanto isso não acontece, a responsabilidade cai sobre cada desenvolvedor. E honestamente? A maioria de nós não está prestando atenção.

O Elefante na Sala: $50.000 pelo Código do Copilot

Talvez o aspecto mais interessante dessa história não seja técnico, mas estratégico. O TeamPCP está vendendo o código-fonte do GitHub Copilot por US$ 50.000.

Pense no que isso significa:

• Competidores podem estudar exatamente como o Copilot funciona internamente
• Pesquisadores de segurança podem encontrar vulnerabilidades no serviço
• O código das ferramentas de red team revela como o GitHub testa sua própria segurança — e por consequência, onde estão os pontos cegos

US$ 50.000 é uma pechincha quando você considera que o Copilot gera bilhões em receita para a Microsoft. Se um estado-nação ou concorrente adquirir esse código, o impacto vai muito além do valor nominal.

Aliás, o fato do grupo ter colocado um preço tão baixo sugere duas coisas: ou eles querem vender rápido antes que as credenciais rotacionadas invalidem o acesso, ou já venderam para alguém e estão tentando monetizar cópias extras.

Nenhuma das duas opções é reconfortante.

E tem outro detalhe que está passando despercebido: entre os repositórios roubados estão suítes de testes de segurança internas. Isso não é só código — é o mapa de como o GitHub valida sua própria segurança. Quais cenários eles testam, quais não testam, quais edge cases são cobertos. Para um atacante sofisticado, esse material vale muito mais que o código do Copilot.

Se essa história prova alguma coisa, é que o modelo de “confie e instale” que governa o ecossistema de desenvolvimento moderno está falido. Não é uma questão de se a próxima supply chain attack vai acontecer — é uma questão de qual ferramenta vai ser a próxima. E com 50.000 extensões no Marketplace do VS Code, cada uma rodando com acesso total à máquina do dev, a superfície de ataque é gigantesca.

A melhor defesa que você tem hoje? Tratar cada extensão, cada pacote npm, cada dependência como código não confiável até prova em contrário. Paranoia não é um bug — é uma feature de segurança.

E se você estiver pensando “isso não vai acontecer comigo” — o engenheiro do GitHub provavelmente pensou a mesma coisa antes de clicar em “Update”.

Fonte de inspiração: GitHub confirms breach of 3,800 repos via malicious VSCode extension (BleepingComputer)