Falha ‘Cordyceps’ em pipelines CI/CD do GitHub expõe mais de 300 repositórios a ataques de supply chain

Pesquisadores da Novee Security divulgaram uma nova classe de falha em workflows de CI/CD do GitHub, batizada de Cordyceps, que permite a qualquer usuário não autenticado assumir o controle de pipelines em organizações do porte de Microsoft, Google, Apache e Cloudflare. Uma varredura inicial em cerca de 30 mil repositórios de alto impacto identificou mais de 300 totalmente exploráveis — o suficiente para forjar aprovações, enviar código malicioso e roubar credenciais sem precisar pertencer à organização-alvo.

O que aconteceu

A empresa de pesquisa Novee Security batizou de Cordyceps — em referência ao fungo parasita que sequestra o comportamento de insetos — um padrão recorrente de configuração frágil em pipelines de integração e entrega contínua baseados no GitHub Actions. O ponto em comum é o gatilho pull_request_target, combinado a permissões amplas e checkout do código vindo do fork. Quando essa combinação aparece em um workflow, o atacante consegue executar código no contexto privilegiado do repositório de origem antes mesmo de qualquer revisão humana.

A pesquisa, publicada em 24 de junho de 2026, baseia-se em um levantamento automatizado sobre cerca de 30 mil repositórios considerados de alto impacto. Dessa amostra, mais de 300 estavam imediatamente exploráveis — uma taxa próxima de 1% que, projetada para o universo do GitHub, sugere milhares de pipelines vulneráveis ainda em produção em todo o ecossistema open source. Entre os afetados confirmados estão projetos mantidos por Microsoft, Google, Apache, Cloudflare e outras grandes corporações que sustentam parte da infraestrutura de software do planeta.

O Cordyceps não é uma vulnerabilidade pontual com CVE associado, mas um antipadrão de design que se propaga horizontalmente em ecossistemas que dependem de contribuições externas. A Novee Security descreve a falha como explorável por qualquer usuário não autenticado, o que coloca a barreira de entrada do ataque essencialmente em zero: basta uma conta gratuita do GitHub e a paciência para abrir um pull request.

Como o ataque funciona

O vetor combina três elementos clássicos do GitHub Actions. Primeiro, o gatilho pull_request_target, que se diferencia do pull_request tradicional por rodar com o contexto e o token do repositório de destino — e não do fork. Segundo, o checkout explícito do código submetido pelo contribuidor externo via actions/checkout apontando para o SHA do PR. Terceiro, a execução de comandos arbitrários a partir desse código — instalação de dependências, testes, ferramentas auxiliares — sem qualquer sandbox real.

A consequência é que abrir um pull request com payload malicioso passa a ser equivalente a injetar código no pipeline interno. Dali em diante, o atacante pode exfiltrar o GITHUB_TOKEN, ler segredos do repositório, publicar artefatos assinados pela organização e até mesmo aprovar seu próprio merge, caso existam workflows de auto-aprovação. O comportamento lembra a infestação do fungo do nome: o pipeline da vítima passa a executar tarefas controladas pelo invasor sem disparar alertas óbvios.

“A falha é explorável por qualquer usuário não autenticado. Sem associação à organização, sem privilégios especiais; uma conta gratuita é suficiente para forjar aprovações, enviar código ou roubar credenciais”, afirmou Elad Meged, engenheiro fundador e pesquisador de segurança da Novee Security.

Quem é afetado

Em tese, qualquer projeto público que aceite contribuições externas e use o gatilho pull_request_target de forma incorreta. Na prática, a Novee Security identificou alguns perfis mais expostos:

• Bibliotecas open source mantidas por grandes empresas que automatizam validações de PR;
• Repositórios de ferramentas de desenvolvedor com integração contínua agressiva e testes que carregam arquivos do fork;
• Mono-repos corporativos com pipelines compartilhados, em que o vazamento de um único token pode comprometer múltiplos produtos;
• Projetos de infraestrutura com Terraform, Kubernetes ou bots que publicam imagens em registries privados;
• Pipelines que misturam workflow de validação e workflow de release, ampliando o blast radius em caso de comprometimento.

Análise

O Cordyceps é menos uma novidade técnica e mais uma confirmação numérica de algo que pesquisadores de supply chain alertam desde o ataque ao SolarWinds, em 2020: o pipeline é o novo perímetro, e quase ninguém o trata como tal. As recomendações do próprio GitHub sobre o uso seguro de pull_request_target existem desde 2020, mas continuam sistematicamente ignoradas. A pesquisa da Novee Security oferece uma fotografia atualizada do problema e mostra que, mesmo em 2026, organizações com programas maduros de segurança ainda incluem repositórios com a configuração problemática.

O caso ecoa incidentes recentes envolvendo workflows de CI/CD, como o comprometimento do action tj-actions/changed-files em março de 2025, e reforça uma tendência consolidada: ataques contra a cadeia de suprimentos de software têm migrado da camada de pacote (npm, PyPI) para a camada de orquestração (GitHub Actions, GitLab CI, Argo, Tekton). O retorno do investimento para o atacante é maior, pois um único pipeline comprometido pode contaminar dezenas de produtos a jusante de uma só vez. Para defensores no Brasil, o ponto crítico é entender que o GitHub Actions não é apenas uma ferramenta de build: é um runtime de produção com acesso a segredos sensíveis e à capacidade de publicar código em nome da empresa.

Recomendações práticas

• Audite todos os workflows que utilizam pull_request_target em repositórios públicos e remova o uso do gatilho onde não houver justificativa explícita;
• Quando o gatilho for necessário, jamais faça checkout do SHA do PR no mesmo job que tem acesso a segredos — isole essa parte em jobs com permissions: read-all e sem segredos disponíveis;
• Reduza o escopo do GITHUB_TOKEN com permissions: mínimo (idealmente contents: read) em cada workflow;
• Habilite a opção “Require approval for all outside contributors” nas configurações do Actions em cada repositório público;
• Considere ferramentas de varredura específicas, como zizmor, octoscan ou a própria oferta da Novee, para mapear padrões inseguros no parque atual;
• Inclua revisão dos arquivos em .github/workflows/ no code review padrão — esses YAMLs devem receber a mesma atenção crítica do código de produção;
• Monitore o uso de GITHUB_TOKEN e segredos via logs do Actions e habilite alertas para execuções anômalas em branches que não sejam main.

Fonte: The Hacker News