Olá a todos!
Se acordaram hoje e ainda não viram a notícia, segurem-se: o GitHub – sim, o GitHub, a plataforma onde mais de 100 milhões de developers guardam o seu código – confirmou que foi comprometido. Um funcionário instalou uma extensão maliciosa de VS Code, e isso bastou para que o grupo TeamPCP exfiltrasse cerca de 3.800 repositórios internos da empresa. Código fonte proprietário do GitHub. Repositórios privados. A cozinha inteira.
O grupo já colocou os dados à venda num fórum de cibercrime por um mínimo de $50.000, com o clássico ultimato: ou alguém compra, ou eles fazem leak de tudo. Mas a notícia não é o leak em si – é o que isto nos diz sobre o modelo em que toda a indústria se apoiou cegamente durante a última década.
Antes de ir mais fundo, o habitual disclaimer: uso o GitHub. Tenho repositórios no GitHub. Não estou aqui a dizer que devem apagar as vossas contas e mudar para pombos-correio. Estou a dizer que quem coloca código crítico – código de produção, segredos, propriedade intelectual – exclusivamente numa plataforma que não controla, está a jogar roleta russa com o gatilho cada vez mais sensível. E hoje o GitHub mostrou-nos o porquê.
O que aconteceu, exactamente
A 20 de Maio de 2026, o GitHub publicou uma série de mensagens no X a confirmar o incidente. A sequência é esta: um funcionário do GitHub instalou uma extensão de VS Code do marketplace oficial. Essa extensão estava envenenada continha malware. A partir do momento em que foi executada, o atacante ganhou acesso à máquina do funcionário e, com ela, a tudo o que essa máquina tinha acesso. Neste caso, repositórios internos do GitHub.
O GitHub diz que detectou o compromisso, isolou o endpoint, removeu a extensão do marketplace, e iniciou procedimentos de incident response. Credenciais críticas foram rotadas durante a noite. Dizem também que, neste momento, não há evidência de que dados de clientes armazenados fora dos repositórios internos tenham sido afectados.
A frase operativa aqui é “neste momento”. A investigação está em curso. Quem já passou por incident response na vida real sabe que “não temos evidência de X” não significa “X não aconteceu”. Significa “ainda não encontrámos evidência de X”. É uma diferença abismal.
O TeamPCP – o grupo que reivindicou o ataque – fala em cerca de 4.000 repositórios privados, e o GitHub confirmou que o número de ~3.800 é “directionally consistent” com a sua investigação. Traduzindo do corporate-speak: sim, os números batem. Ou seja, não estamos a falar de um script kiddie que apanhou meia dúzia de ficheiros. Estamos a falar de uma exfiltração massiva do código interno de uma das plataformas mais críticas da infraestrutura de software mundial.
O TeamPCP já não é novidade e isso torna tudo muito pior
Se leram o meu post sobre o BitwardenGate em Abril, já conhecem este nome. O TeamPCP, também referenciado como UNC6780, é o grupo por trás de uma série de ataques de supply chain que têm vindo a escalar em frequência e em ambição desde o início de 2026.
Recapitulemos a lista de vítimas: o scanner de segurança Trivy da Aqua Security, o KICS da Checkmarx (tanto a imagem Docker como as extensões de VS Code), o LiteLLM, o Telnyx SDK, o TanStack, packages da MistralAI, o Bitwarden CLI. E agora o GitHub. Em todos os casos, o vector é o mesmo: comprometer a cadeia de ferramentas que os developers usam e confiam implicitamente, para ganhar acesso ao que realmente importa – credenciais, segredos, código proprietário.
O que o TeamPCP fez com o GitHub é conceptualmente idêntico ao que fez com o Bitwarden: não atacaram o produto directamente. Atacaram as ferramentas que os funcionários e os pipelines usam. No caso do Bitwarden, foram GitHub Actions comprometidas no pipeline de CI/CD. No caso do GitHub, foi uma extensão de VS Code no marketplace oficial da Microsoft.
E aqui está o detalhe que me tira o sono: a extensão estava no marketplace oficial. Não foi side-loaded. Não foi instalada de um repo obscuro. Foi instalada do mesmo sítio onde todos nós vamos buscar extensões para o VS Code. Do marketplace que a Microsoft opera, que supostamente tem processos de review, e que milhões de developers usam diariamente sem pensar duas vezes.
O VS Code Marketplace é um campo minado. E ninguém quer admiti-lo.
Isto não é a primeira vez que extensões maliciosas aparecem no marketplace do VS Code. No último ano — só no último ano — extensões com 9 milhões de instalações foram removidas por preocupações de segurança. Outra batch instalava cryptominers nas máquinas dos developers. Duas extensões de assistentes de código com IA, com 1.5 milhões de instalações combinadas, foram apanhadas a enviar dados para servidores na China.
E sabem o que acontece sempre? A extensão é removida, sai um post-mortem, os developers são lembrados para “terem cuidado com o que instalam”, e duas semanas depois toda a gente se esquece e volta ao mesmo. Até ao próximo incidente.
O problema é estrutural, não é comportamental. Dizer a um developer para “ter cuidado com as extensões que instala” é como dizer a alguém para “ter cuidado com as moléculas de ar que respira”. O VS Code é construído à volta do conceito de extensibilidade. O editor sem extensões é um bloco de notas glorificado. O workflow de qualquer developer moderno passa por dezenas de extensões – linters, formatters, language servers, integrações com Git, com Docker, com Kubernetes, com AWS, com Azure, com Terraform.
E como bem notou o Charlie Eriksen da Aikido Security a propósito deste breach: as extensões de VS Code têm acesso completo a tudo na máquina do developer. Credenciais, cloud keys, SSH keys, tokens, ficheiros de configuração, variáveis de ambiente. Tudo. Não há sandbox. Não há isolamento. Quando instalas uma extensão de VS Code, estás a dar a um terceiro desconhecido acesso root à tua estação de trabalho de desenvolvimento.
E aqui mora o problema maior: o GitHub não corre em máquinas de developers aleatórios. Estamos a falar de um funcionário de uma das empresas de software mais sofisticadas do mundo, que presumivelmente opera sob políticas de segurança rigorosas, com EDR, com segmentação de rede, com processos de incident response maduros — e mesmo assim, uma extensão envenenada de VS Code foi suficiente para comprometer o acesso a milhares de repositórios internos.
Se isto aconteceu ao GitHub, pergunto-vos com toda a sinceridade: acham que a vossa empresa está mais protegida?
O verdadeiro problema: confiança implícita em infraestrutura que não controlamos
E agora chegamos ao ponto que realmente me interessa, e que é a razão pela qual estou a escrever este post em vez de simplesmente partilhar a notícia com um “vejam isto” no LinkedIn.
O GitHub é o sítio onde a esmagadora maioria das empresas do mundo guarda o seu código. Não uma cópia do código — muitas vezes a única cópia centralizada, o source of truth, o ponto de convergência de todo o desenvolvimento. CI/CD pipelines apontam para lá. Code reviews acontecem lá. Secrets são geridos lá (ou por ferramentas integradas com lá). Deployments são triggered a partir de lá.
Quando digo “o GitHub foi comprometido”, o que a maioria das pessoas ouve é “houve um breach no GitHub”. O que deviam ouvir é: “a plataforma onde guardo o meu código, os meus segredos, e a minha pipeline de deployment foi comprometida por atacantes que agora têm acesso ao código fonte interno da própria plataforma.”
Agora, o GitHub diz que os dados dos clientes não foram afectados. E eu quero acreditar nisso. Mas façamos um exercício mental: se os atacantes exfiltraram ~3.800 repositórios internos com código fonte proprietário do GitHub, o que é que esse código pode conter? Lógica de autenticação. Mecanismos de autorização. APIs internas. Esquemas de bases de dados. Configurações de infraestrutura. Potenciais vulnerabilidades zero-day no próprio GitHub que agora estão nas mãos de um grupo de cibercrime que já demonstrou sofisticação suficiente para comprometer o Bitwarden, a Checkmarx, e meia dúzia de outras ferramentas de segurança.
Mesmo que — no melhor cenário — os dados dos clientes estejam intactos hoje, o código fonte exfiltrado pode ser usado para encontrar vulnerabilidades que permitam comprometer dados de clientes amanhã. Isto não é paranóia. É análise de risco básica.
E lembrem-se: há menos de um mês, a 28 de Abril, foi divulgado o CVE-2026-3854, uma vulnerabilidade crítica no GitHub que permitia a utilizadores autenticados executar comandos arbitrários nos servidores do GitHub e expunha milhões de repositórios públicos e privados. Não há confirmação de que esse CVE esteja relacionado com este breach. Mas a coincidência temporal é, no mínimo, desconfortável.
A solução que ninguém quer implementar (mas que é a única que realmente protege se dois dedos de testa estiverem envolvidos)
Eu sei que vou soar como um disco riscado. Quem lê este blog há tempo já me ouviu dizer isto de dez formas diferentes. Mas se há dia para o repetir, é hoje.
O vosso código crítico precisa de viver em infraestrutura que vocês controlam.
Não estou a dizer para abandonarem o GitHub — seria impraticável para a maioria das equipas e projectos. Estou a dizer que o GitHub não pode ser o vosso único ponto de armazenamento de código, e que para projectos verdadeiramente críticos, deviam ter uma instância de Gitea, GitLab, ou Forgejo self-hosted, na vossa infraestrutura, no vosso datacenter ou no vosso servidor dedicado, com backups que vocês controlam, com políticas de acesso que vocês definem, e com uma superfície de ataque que vocês podem auditar.
O Gitea corre num Raspberry Pi. Literalmente. Já o demonstrei aqui no blog. O GitLab CE corre num VPS de €20/mês. O Forgejo — o fork comunitário do Gitea — é ainda mais leve. Nenhuma destas soluções é perfeita, nenhuma tem o ecossistema do GitHub, nenhuma tem os GitHub Actions, as GitHub Pages, o Copilot integrado, e todos os outros bells and whistles. Mas sabem o que têm? Vocês. A controlá-los. A decidir quem acede ao quê. A decidir onde os dados vivem. A decidir que extensões, plugins, e integrações são permitidas no ambiente.
Quando o GitHub é comprometido, vocês não controlam a resposta. Não controlam o timeline da investigação. Não controlam a comunicação. Não controlam se os vossos dados foram ou não exfiltrados — ficam à espera que alguém vos diga, e quando vos disserem, já podem ter passado dias ou semanas.
Quando a vossa instância de Gitea self-hosted é comprometida (se for comprometida), vocês são os primeiros a saber, vocês controlam a investigação, vocês decidem o que fazer e quando, e vocês têm acesso directo a todos os logs, todas as métricas, todos os artefactos forenses.
A diferença entre estas duas situações não é técnica. É de soberania.
Mas Nuno, eu sou uma PME, não tenho equipa para manter infraestrutura de Git…
Ouço isto frequentemente, e é um argumento legítimo. Nem toda a gente tem um sysadmin dedicado ou uma equipa de DevOps. E o GitHub é fantástico precisamente porque tira essa complexidade de cima de quem quer apenas escrever código e fazer push.
Mas pergunto-vos: se o vosso negócio depende de software que vocês desenvolvem, e esse software é a vossa vantagem competitiva, o vosso produto, a razão pela qual os vossos clientes vos pagam — não acham que ter uma cópia desse software em infraestrutura que controlam é pelo menos tão importante como ter um backup da vossa base de dados de clientes?
A maioria das PMEs hoje tem backups dos seus dados. Têm NAS, têm backup offsite, têm replicação. Ninguém acha estranho ter uma cópia dos dados fora do servidor principal. Mas quando se fala em ter uma cópia do código fora do GitHub, de repente é “overengineering” ou “paranóia”.
Não é overengineering. Não é paranóia. É gestão de risco básica que hoje ficou validada da forma mais dramática possível.
Montar um mirror é trivial. Um git clone --mirror num cron job que corre uma vez por dia para o vosso NAS, para o vosso servidor dedicado, para a vossa instância de Gitea. Meia hora de setup. Zero custo adicional se já têm hardware. E no dia em que o GitHub tiver um breach que afecte dados de clientes — e não é uma questão de se, é uma questão de quando — vocês têm o vosso código, os vossos branches, os vossos tags, tudo intacto, na vossa posse.
O padrão que se repete (e que a maioria escolhe ignorar)
Já escrevi aqui sobre o BitwardenGate. Sobre a campanha Checkmarx. Sobre o axios e o DPRK. Sobre o Chrome a instalar 4GB de IA silenciosamente. Sobre a Anthropic a mudar as regras do jogo com um mês de aviso. Sobre o postmortem que provou que se não controlas o modelo, não controlas nada.
Todos estes posts têm um tema comum: a dependência cega de infraestrutura, serviços, e ferramentas de terceiros que não controlamos é uma vulnerabilidade existencial para qualquer organização que dependa de tecnologia. E em 2026, isso são todas as organizações.
O GitHub de hoje é o AWS de amanhã. O VS Code Marketplace de hoje é o Docker Hub de ontem. O npm de hoje é o PyPI de amanhã. Cada um destes ecosistemas é um ponto único de falha que, quando falha, cascateia para milhares ou milhões de organizações em simultâneo.
Ninguém espera que cada empresa monte a sua própria cloud. Mas espero — e cada vez mais exijo nas conversas que tenho — que cada empresa tenha pelo menos um plano B. Um mirror do código. Uma cópia dos artefactos críticos. Uma instância self-hosted de pelo menos uma alternativa às ferramentas mais críticas. Um playbook para o dia em que o fornecedor X é comprometido.
Porque esse dia já não é hipotético. Para os clientes do GitHub, esse dia é hoje.
O que devem fazer agora
Vou ser prático, porque de teoria já chega:
Verifiquem as extensões de VS Code instaladas nas máquinas dos vossos developers. Façam uma auditoria. Quantas extensões têm? Quem as publicou? Quando foram actualizadas pela última vez? Existe alguma que não reconhecem ou que já não usam? Removam tudo o que não é estritamente necessário. Já.
Implementem políticas de extensões aprovadas. O VS Code suporta extensions.json e políticas de grupo que limitam quais extensões podem ser instaladas. Usem-nas. Não é restritivo — é higiénico.
Montem um mirror do vosso código. Hoje. Não amanhã, não na próxima sprint, não “quando tivermos tempo”. Um git clone --mirror para cada repositório crítico, num storage que controlam. Automatizem com um cron job ou com uma ferramenta como o Gitea Mirror.
Rotem secrets que estejam em repositórios do GitHub. Se têm API keys, tokens, ou credenciais em repositórios privados do GitHub — mesmo que em variáveis de ambiente ou em GitHub Secrets — considerem rotá-los preventivamente. A exposição do código interno do GitHub pode ter revelado detalhes sobre como estes mecanismos funcionam.
Revejam a vossa postura de CI/CD. Se as vossas pipelines de CI/CD correm no GitHub Actions com actions de terceiros referenciadas por tag mutável, estão expostos ao mesmo vector que foi usado para comprometer o Bitwarden e a Checkmarx. Passem a referenciar actions por hash de commit.
Considerem seriamente uma instância self-hosted de Git para código crítico. Gitea, GitLab CE, Forgejo — escolham o que preferirem. Não precisa de substituir o GitHub. Precisa de existir como alternativa, como backup, como plano B. Se investem em redundância para bases de dados, para servidores web, para load balancers — o vosso código merece o mesmo tratamento.
Nota final
Há uma ironia que não consigo ignorar nisto tudo. O GitHub é literalmente a plataforma que aloja o código de ferramentas de segurança como o Trivy, o KICS, o Bitwarden. É o sítio onde se faz code review, onde se abrem security advisories, onde se publicam CVEs. É o centro nervoso da segurança open source.
E foi comprometido por uma extensão de VS Code.
Não por um zero-day sofisticado. Não por um APT estatal com recursos ilimitados. Por uma extensão no marketplace. Uma extensão que um funcionário instalou, provavelmente porque parecia útil, porque tinha boas reviews, porque estava no marketplace oficial e portanto devia ser segura.
Essa suposição — “está no marketplace oficial, portanto é seguro” — é exactamente a mesma suposição que nos fez confiar cegamente no npm, no PyPI, no Docker Hub, e no próprio GitHub. E é a suposição que, repetidamente, se prova errada.
A segurança não é um produto que se compra. Não é um serviço que se subscreve. É uma postura que se adopta, e parte dessa postura é aceitar que qualquer sistema externo pode ser comprometido, e construir resiliência à volta dessa realidade.
Hoje o GitHub aprendeu essa lição da pior forma. Espero que não precisem de aprender da mesma maneira.
Mantende-se vigilantes.
Um abraço,
Nuno Higgs
Fontes:
- GitHub (X/Twitter) — Thread oficial sobre o incidente (20 Maio 2026)
- Help Net Security — TeamPCP breached GitHub’s internal codebase via poisoned VS Code extension (20 Maio 2026)
- Security Affairs — A Malicious VS Code Extension Just Breached GitHub’s Internal Repositories (20 Maio 2026)
- CyberNews — Compromised employee device leads to GitHub breach: source code for sale (20 Maio 2026)
- Este blog — BitwardenGate: O teu gestor de passwords foi comprometido (23 Abril 2026)