O GitHub desativou 73 repositórios oficiais da Microsoft no dia 5 de junho de 2026. O incidente envolveu as organizações Azure e Durable Task e expôs uma vulnerabilidade crítica no fluxo de trabalho de desenvolvimento moderno: abrir código em ferramentas como Claude Code, Gemini CLI, Cursor ou VS Code pode comprometer uma máquina inteira, sem nenhum clique suspeito, sem nenhum download manual.

Portanto, entender o que aconteceu aqui não é só curiosidade técnica. É uma questão de segurança operacional para qualquer dev que trabalha com repositórios externos.

GitHub Primeiro, o vetor de ataque: não foi o código, foram os arquivos de configuração

Um colaborador com credenciais já comprometidas enviou um commit ao repositório Azure/durabletask. Até aí, nada fora do comum na rotina de contribuição open source. Mas o commit não alterava lógica de negócio nem corrigia bugs. Em vez disso, ele adicionava cinco arquivos de configuração que ferramentas de desenvolvimento executam automaticamente ao abrir o projeto.

O resultado era direto: um executável malicioso de 4,6 MB rodava silenciosamente em segundo plano. Sem pop-up, sem aviso, sem interação do usuário.

GitHub: O que o malware coletava, e por que isso é especialmente grave para devs

Assim que ativado, o programa vasculhava a máquina em busca de credenciais de AWS, Azure e Google Cloud, tokens do GitHub, chaves SSH e variáveis de ambiente. Além disso, ele também lia o histórico do terminal.

Para a maioria dos usuários comuns, isso seria grave. Para um desenvolvedor, todavia, é catastrófico. Um dev geralmente tem acesso a servidores de produção, pipelines de CI/CD, bancos de dados e sistemas internos de clientes. Com essas credenciais em mãos, o atacante se torna, efetivamente, o desenvolvedor.

Por que o ataque de junho foi possível: a lição das credenciais não rotacionadas

Esse incidente de junho não surgiu do nada. Em maio, a mesma conta comprometida havia sido usada para publicar três versões maliciosas do pacote durabletask no PyPI. O pacote é baixado mais de 400 mil vezes por mês, o que amplia consideravelmente o raio de impacto potencial.

Aparentemente, a Microsoft não rotacionou completamente as credenciais da conta após o incidente de maio. Isso permitiu que o atacante simplesmente reutilizasse o mesmo acesso semanas depois.

Ou seja: a falha não foi só técnica. Foi também de processo.

O worm Miasma e o grupo por trás do código

O grupo TeamPCP assumiu a responsabilidade pelo Mini Shai-Hulud, worm antecessor direto do Miasma. O grupo tem um histórico documentado de ataques a pacotes de código aberto em 2025 e 2026, com vítimas que incluem Mistral AI, LiteLLM e centenas de pacotes npm.

O ponto mais preocupante, no entanto, é que o código do Mini Shai-Hulud foi publicado abertamente. Isso significa que qualquer pessoa com conhecimento técnico suficiente pode derivar novas variantes. Determinar se o Miasma foi obra do próprio grupo ou de alguém que aproveitou o código disponível é, portanto, extremamente difícil.

O efeito cascata: pipelines quebrados em menos de uma hora

Um dos repositórios afetados foi o Azure/functions-action, usado por desenvolvedores para automatizar deploys na nuvem Azure. Com a desativação, todos os processos que dependiam desse repositório pararam simultaneamente.

Em poucas horas, o fórum de suporte da Microsoft já acumulava mais de 20 relatos de pipelines completamente quebrados. Fica evidente, assim, o quanto a cadeia de dependências de um time de desenvolvimento é vulnerável a um único ponto de falha comprometido.

O que você precisa fazer agora, e o que mudar no seu fluxo de trabalho com GitHub

Se você clonou algum repositório afetado e o abriu em uma ferramenta de IA ou editor com extensões ativas depois de 2 de junho, trate a máquina como comprometida e rotacione todas as credenciais armazenadas nela.

Para reduzir exposição em situações futuras, algumas práticas diretas fazem diferença:

Trave as versões dos pacotes que você utiliza. Versões flutuantes são uma porta aberta para substituições maliciosas.

Audite regularmente os commits recentes nos repositórios que você consome, especialmente aqueles que adicionam arquivos de configuração como .claude/, .gemini/ ou .vscode/tasks.json. Esses arquivos são executados automaticamente por ferramentas populares e, por isso, são vetores de ataque de alta eficiência.

Revise também a política de rotação de credenciais do seu time. O caso da Microsoft demonstra que um incidente sem resposta adequada de rotação vira, inevitavelmente, a porta de entrada do próximo ataque.

O modelo de confiança implícita no open source está sob pressão

Por muito tempo, o ecossistema open source operou sob uma premissa de confiança: repositórios de organizações conhecidas, pacotes amplamente usados e contas de colaboradores estabelecidos eram tratados como seguros por padrão.

O worm Miasma, assim como ataques anteriores a cadeias de suprimento de software, demonstra que essa premissa precisa ser revista. Consequentemente, a segurança de um projeto não depende apenas do código que você escreve, mas também de cada dependência, cada configuração e cada conta com acesso ao repositório.

No modelo atual de desenvolvimento, em que ferramentas de IA leem e executam contexto de repositórios automaticamente, o perímetro de segurança se expandiu de forma significativa. Abrir um repositório virou um ato com consequências de segurança que vão além da máquina local.

A pergunta que fica é: o seu fluxo de trabalho já leva isso em conta?

Acompanhe nosso perfil no Instagram!