Investigadores da empresa de testes de intrusão Novee Security revelaram uma nova classe de fraquezas em pipelines de integração e entrega contínua (CI/CD) que baptizaram de “Cordyceps”, em alusão ao fungo parasita que assume o controlo do organismo hospedeiro. De acordo com a divulgação, o padrão explorável reside em fluxos de trabalho do GitHub Actions e pode permitir a um atacante sem autenticação assumir o controlo total de repositórios de dezenas das maiores organizações do mundo. Entre os exemplos confirmados estão projetos ligados à Microsoft, Google, Apache e Cloudflare. Ainda que a comunicação inicial tenha partido da imprensa, os factos foram verificados junto da investigação original da Novee e dos avisos oficiais do próprio GitHub.
Resposta rápida: A Cordyceps não é um único CVE, mas uma classe sistémica de falhas em fluxos de trabalho de CI/CD do GitHub Actions. A Novee diz que, após analisar cerca de 30 mil repositórios de alto impacto, sinalizou 654 e confirmou mais de 300 como totalmente exploráveis. As organizações afetadas já corrigiram os casos divulgados e o GitHub lançou, em junho de 2026, defesas ao nível da plataforma. Reveja urgentemente os seus ficheiros .yml, atualize o actions/checkout e restrinja quem pode acionar fluxos de trabalho.
O que é a Cordyceps e porque é diferente
Ao contrário de uma vulnerabilidade isolada, a Cordyceps é descrita como uma classe de falhas sistémicas. A Novee identificou um conjunto de padrões exploráveis na cadeia de fornecimento de software open source — injeção de comandos, lógica de autenticação quebrada, cadeias de envenenamento de artefactos e escalonamento de privilégios em fluxos de trabalho do GitHub Actions. O problema central não está nos pull requests em si, mas na forma como as pipelines automatizadas tratam dados não confiáveis.
O ataque assenta em cadeias de exploração de vários passos que atravessam fronteiras de confiança. Num cenário típico, um utilizador não autorizado deixa um comentário anónimo ou submete uma alteração de código através de um pull request. Um fluxo de trabalho de baixo privilégio trata essa entrada como um comando confiável e executa código oculto que compromete o pacote de software ou o artefacto final. A partir daí, o escalonamento de privilégios ocorre quando esses dados contaminados fluem para um fluxo de trabalho de privilégio elevado e expõem chaves de autenticação de alto nível — abrindo caminho a permissões administrativas totais sobre a rede cloud de uma organização.
A gravidade agrava-se pela baixíssima barreira de entrada. Segundo Elad Meged, engenheiro fundador e investigador de segurança da Novee, a falha é explorável por qualquer utilizador não autenticado. Na prática, a exploração pode exigir apenas um pull request ou até um comentário num pull request a partir de uma conta gratuita do GitHub, permitindo que atacantes de baixo privilégio ou anónimos executem código malicioso, roubem credenciais e potencialmente ganhem controlo de repositórios e ambientes cloud ligados.
A dimensão do problema
Os números da investigação dão a medida do alcance. Depois de analisar cerca de 30 mil repositórios de alto impacto, a Novee sinalizou 654 projetos e verificou mais de 300 como totalmente exploráveis. Entre os casos confirmados incluem-se repositórios associados à Microsoft, Google, Apache, Cloudflare e à Python Software Foundation, com exemplos como o Azure Sentinel, o adk-samples da Google, o Apache Doris, o formatador Black e ferramentas dos Cloudflare Workers.
Um dos casos mais expressivos envolve a Microsoft. A Novee descreveu um ataque dirigido ao SIEM Azure Sentinel da Microsoft, em que um comentário num pull request acionou código anónimo do atacante na integração contínua do fabricante e roubou uma chave de aplicação GitHub que não expira. No caso da Google, um pull request executou código do atacante no processo de integração contínua, arriscando o controlo não autenticado sobre o projeto Google Cloud associado.
É importante contextualizar o risco. A Novee afirmou não haver, de momento, evidência de que atacantes tenham explorado amplamente estes padrões de fluxo de trabalho no mundo real, e as organizações afetadas corrigiram os problemas divulgados. Ainda assim, o padrão em si permanece disseminado por milhões de repositórios.
O fator IA: um problema que se replica sozinho
Um dos aspetos mais preocupantes da investigação é o papel dos agentes de codificação por IA na propagação da falha. À medida que os programadores dependem cada vez mais de ferramentas de IA para gerar rapidamente ficheiros de configuração de CI/CD, essas ferramentas reproduzem os mesmos padrões inseguros repetidamente — o que resulta na mesma classe de vulnerabilidade a ser plantada silenciosamente por potencialmente milhões de repositórios.
A raiz do problema é cultural, não apenas técnica. Como sublinhou a Novee, muitas equipas de desenvolvimento ainda não tratam o YAML dos fluxos de trabalho de CI/CD como código crítico de segurança. Estes ficheiros são vistos como “meras configurações”, mas na prática executam comandos, manuseiam credenciais, publicam pacotes e tomam decisões de lançamento.
Cronologia e resposta do GitHub
| Data | Acontecimento |
|---|---|
| 18 jun. 2026 | GitHub lança o actions/checkout v7, que recusa por omissão o checkout de código de forks em gatilhos pull_request_target e workflow_run |
| 24 jun. 2026 | Novee publica a investigação sobre a Cordyceps |
| 26 jun. 2026 | GitHub passa a emitir tokens de cache só de leitura para gatilhos não confiáveis |
| 20 jul. 2026 | Data revista para a aplicação do backport do actions/checkout às versões suportadas |
Em paralelo com a divulgação, o GitHub tem vindo a reforçar as defesas ao nível da plataforma. O gatilho pull_request_target é um dos mais frequentemente mal utilizados do GitHub Actions: os fluxos por ele acionados correm com o GITHUB_TOKEN, os segredos e o acesso ao cache do ramo principal do repositório base. Fazer checkout do topo de um pull request não revisto de um fork dentro destes fluxos permite tipicamente que código controlado pelo atacante seja executado com todos os privilégios — o chamado ataque “pwn request”.
Quanto ao envenenamento de cache, o GitHub passou a emitir tokens de cache só de leitura para o ramo principal em eventos de fluxo de trabalho que podem ser acionados sem permissões de escrita no repositório. Anteriormente, o serviço emitia tokens de leitura e escrita para cada evento — incluindo gatilhos como pull_request_target e issue_comment — o que permitia que código influenciado por um ator externo escrevesse no cache do ramo principal, para depois ser restaurado por um fluxo confiável como push ou schedule.
Como mitigar: passos concretos
- Trate o YAML como código crítico: aplique a mesma revisão de segurança aos ficheiros de fluxo de trabalho que aplicaria ao código da aplicação.
- Atualize o
actions/checkout: use a versão mais recente e evite fazer checkout de código de forks em gatilhospull_request_targeteworkflow_run. - Prefira
pull_requestapull_request_target: só use o segundo quando o fluxo exigir mesmo permissões elevadas ou acesso a segredos. - Aplique o princípio do menor privilégio: restrinja as permissões concedidas ao
GITHUB_TOKENe ative políticas de quem pode acionar fluxos de trabalho. - Audite entradas não confiáveis: evite injetar diretamente conteúdo de comentários, títulos ou corpos de pull requests em comandos de shell.
Porque é que isto importa em Portugal
Embora os alvos demonstrados sejam gigantes tecnológicos, a lição é universal e diretamente aplicável às PME e organizações portuguesas que dependem de pipelines de CI/CD. Qualquer equipa que use o GitHub Actions para construir e publicar software herda potencialmente estes padrões inseguros — sobretudo quando recorre a agentes de IA para gerar configurações. Um único ponto de apoio numa pipeline pode alcançar código-fonte, segredos e a capacidade de distribuir software adulterado a jusante.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a segurança da cadeia de fornecimento de software é uma componente explícita das obrigações de gestão de risco. Um comprometimento de pipeline que resulte na exposição de dados pessoais pode ainda desencadear obrigações de notificação ao abrigo do RGPD. O CNCS e o CERT.PT recomendam, de forma consistente, a adoção de práticas de menor privilégio e a monitorização de dependências e ferramentas de desenvolvimento como parte da higiene de cibersegurança das organizações.
Perguntas frequentes
A Cordyceps tem um número CVE?
Não. A Cordyceps não é uma vulnerabilidade única com um identificador CVE, mas uma classe sistémica de padrões exploráveis em fluxos de trabalho de CI/CD do GitHub Actions. Reúne falhas como injeção de comandos, envenenamento de artefactos e escalonamento de privilégios.
A minha organização foi afetada?
Se usa o GitHub Actions com gatilhos como pull_request_target e faz checkout de código de forks não revistos, poderá estar exposta a este padrão. A Novee confirmou centenas de repositórios exploráveis, mas o padrão pode existir em muitos mais que não foram analisados.
Já houve ataques reais a explorar a Cordyceps?
Segundo a Novee, não há atualmente evidência de exploração ampla destes padrões no mundo real, e as organizações afetadas corrigiram os casos divulgados. Ainda assim, incidentes semelhantes de envenenamento de pipeline ocorreram noutros contextos.
O que devo fazer primeiro?
Comece por atualizar o actions/checkout, rever os ficheiros YAML dos seus fluxos de trabalho, substituir pull_request_target por pull_request sempre que possível e restringir quem pode acionar workflows. Aplicar o princípio do menor privilégio ao GITHUB_TOKEN é essencial.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Novee Security, pelo GitHub e por publicações especializadas de cibersegurança.