Os pipelines modernos parecem seguros quando todos os testes terminam com um grande sinal verde, mas uma nova classe de ameaça mostra que esse cenário pode ser enganoso. A vulnerabilidade no GitHub Actions chamada Cordyceps revelou como fluxos de automação aparentemente corretos podem esconder brechas capazes de expor segredos, tokens e credenciais de ambientes corporativos.
Descoberta pela Novee Security, a falha explora problemas de composição em arquivos de configuração do GitHub Actions, afetando centenas de repositórios de alto impacto. O caso chamou atenção porque os scanners tradicionais de segurança não identificavam o problema: os arquivos YAML estavam sintaticamente corretos, mas a lógica de confiança entre eventos e permissões estava comprometida.
Com a adoção crescente de CI/CD, especialmente em projetos open source e ambientes empresariais, o GitHub Actions se tornou uma peça central no desenvolvimento de software. Essa popularidade também transformou pipelines automatizados em alvos estratégicos para ataques de cadeia de suprimentos.
O que é a vulnerabilidade no GitHub Actions Cordyceps e o ataque pwn request
A Cordyceps é uma classe de falhas relacionada ao uso inseguro do mecanismo conhecido como pwn request, uma técnica que explora diferenças de comportamento entre eventos de colaboração no GitHub.
O problema aparece principalmente quando um fluxo de trabalho usa o gatilho pull_request_target de maneira incorreta. Esse recurso foi criado para permitir que mantenedores executem determinadas ações com permissões elevadas durante uma solicitação de alteração, mas essa confiança adicional pode ser abusada.
Em um cenário vulnerável, um atacante pode enviar uma alteração aparentemente legítima por meio de um pull request. Se o pipeline executar código controlado pelo invasor dentro de um contexto privilegiado, informações sensíveis podem ser acessadas.
Entre os riscos estão o vazamento de tokens do GitHub, chaves de APIs, credenciais de nuvem e segredos armazenados como variáveis protegidas. Em ambientes corporativos, isso pode abrir caminho para movimentação lateral e comprometimento de outros sistemas.
A característica mais preocupante da vulnerabilidade no GitHub Actions é que ela não depende de um erro óbvio. O arquivo de configuração pode passar por revisões tradicionais e ainda assim conter uma combinação perigosa de permissões, eventos e código externo.
A diferença perigosa entre pull_request e pull_request_target
Para entender o impacto da falha, é necessário diferenciar dois gatilhos importantes do GitHub Actions.
O evento pull_request executa workflows relacionados ao código enviado pelo colaborador, normalmente em um ambiente com permissões reduzidas. Isso limita o impacto caso o código contenha comportamento malicioso.
Já o pull_request_target roda o workflow usando o contexto da branch principal do repositório. Essa característica permite acesso a determinados segredos e permissões que normalmente não seriam entregues a um código externo.
O problema surge quando desenvolvedores combinam pull_request_target com ações como checkout do código modificado pelo colaborador. Nesse momento, o pipeline pode acabar executando código não confiável com privilégios elevados.
Esse tipo de configuração cria uma falsa sensação de segurança. O repositório continua protegido por revisões de código, mas o processo automático que valida as alterações pode se transformar no próprio vetor de ataque.
Técnicas de execução: injeção de comandos e escalada
A exploração da Cordyceps pode envolver diferentes técnicas, incluindo injeção de comandos e execução indireta de código malicioso.
Um exemplo comum acontece quando dados fornecidos por usuários ou colaboradores são utilizados dentro de comandos do pipeline sem validação adequada. Pequenos detalhes em scripts podem permitir que um invasor altere o comportamento esperado do workflow.
Outra estratégia envolve dependências e ações reutilizadas dentro do GitHub Actions. Caso uma etapa execute código externo sem controle adequado de versão, o atacante pode explorar alterações futuras ou comprometimentos de componentes de terceiros.
A combinação entre permissões elevadas e execução de código não confiável transforma uma simples automação de testes em uma porta de entrada para ataques mais avançados.
Como gigantes como Google e Microsoft foram expostos pela vulnerabilidade no GitHub Actions
O impacto da Cordyceps ganhou relevância porque atingiu projetos associados a grandes organizações de tecnologia.
Entre os casos analisados pela Novee Security, estavam repositórios relacionados ao Azure Sentinel, plataforma de segurança da Microsoft, e ao Kit de Desenvolvimento de IA do Google. As investigações demonstraram como configurações vulneráveis poderiam permitir exposição de credenciais e segredos armazenados nos ambientes de CI/CD.
O risco não estava necessariamente em uma falha do serviço GitHub, mas na forma como os fluxos de trabalho foram configurados pelos projetos. Essa diferença é fundamental: a infraestrutura funciona conforme projetada, porém combinações inseguras podem criar caminhos inesperados para invasores.
Casos como esse reforçam que grandes empresas também enfrentam desafios de governança em ambientes automatizados. Quanto maior a quantidade de repositórios, colaboradores e integrações, maior a necessidade de revisar continuamente os controles de segurança.
Por que os scanners tradicionais falharam na vulnerabilidade no GitHub Actions
Um dos pontos mais importantes da vulnerabilidade no GitHub Actions Cordyceps é explicar por que ferramentas tradicionais não conseguiram identificar o problema.
A maioria dos scanners analisa padrões conhecidos, erros de sintaxe, permissões explícitas ou comportamentos considerados inseguros. Porém, a Cordyceps explora uma falha de composição: cada parte do arquivo pode parecer correta isoladamente, mas a combinação cria um risco.
É como analisar peças individuais de uma máquina e concluir que todas funcionam, sem perceber que a montagem final gera um mecanismo perigoso.
Os arquivos YAML continuam válidos. Os testes continuam passando. O pipeline continua aparecendo como confiável. O problema está na relação entre eventos, permissões e código executado.
Outro fator que aumenta esse desafio é o avanço das ferramentas de inteligência artificial para geração de código. Modelos de IA conseguem reproduzir rapidamente padrões comuns encontrados em projetos públicos, incluindo configurações inseguras de CI/CD.
Isso significa que erros de arquitetura podem se espalhar em escala muito maior quando desenvolvedores copiam exemplos sem uma análise profunda de segurança.
Como proteger seus fluxos de trabalho no GitHub Actions contra ataques em CI/CD
A prevenção da falha no GitHub Actions exige uma combinação de boas práticas, revisão humana e ferramentas especializadas. Algumas medidas reduzem significativamente o risco:
- Evite usar pull_request_target para executar código não confiável. Quando possível, prefira o uso de pull_request para validações que não precisam de privilégios elevados.
- Não execute código de colaboradores externos com permissões privilegiadas. Separar etapas de análise e implantação ajuda a reduzir superfícies de ataque.
- Fixe versões de ações usando SHA. Em vez de depender de versões móveis, utilize referências imutáveis para evitar alterações inesperadas em componentes externos.
- Reduza permissões dos tokens. Configure o princípio do menor privilégio utilizando permissões mínimas para o GITHUB_TOKEN.
- Revise workflows antigos. Muitos riscos permanecem em arquivos criados anos atrás, quando práticas atuais de segurança ainda não eram comuns.
- Use ferramentas específicas de segurança para CI/CD. Scanners modernos precisam analisar contexto e fluxo lógico, não apenas procurar padrões estáticos.
Além disso, equipes de desenvolvimento devem incluir revisão de segurança nos processos de alteração de pipelines. Um arquivo de automação deve receber o mesmo cuidado aplicado ao código da aplicação.
Conclusão e os novos desafios da cadeia de suprimentos
A descoberta da Cordyceps mostra que a segurança moderna depende cada vez mais da compreensão do contexto. Não basta verificar se um arquivo está correto do ponto de vista técnico: é necessário entender como componentes, permissões e fluxos de execução interagem.
A vulnerabilidade no GitHub Actions também reforça um desafio crescente da cadeia de suprimentos de software. Códigos escritos por humanos ou gerados por inteligência artificial precisam passar por controles que considerem riscos de arquitetura, não apenas erros visíveis.
Os pipelines de CI/CD são fundamentais para a velocidade do desenvolvimento moderno, mas precisam ser tratados como ativos críticos de segurança.
Agora é o momento para equipes revisarem seus arquivos de workflow, analisarem permissões e verificarem se seus processos de automação realmente merecem o sinal verde que exibem.
