Falha em ação do Claude no GitHub permitia sequestro de repositórios a partir de uma única issue
Uma vulnerabilidade grave na Claude Code GitHub Action, mantida pela Anthropic, abriu espaço para que atacantes tomassem o controle de repositórios públicos apenas ao criar uma única issue maliciosa. A brecha, identificada pelo pesquisador RyotaK, da GMO Flatt Security, expôs riscos importantes para pipelines de CI/CD que integram agentes de IA com permissões amplas sobre código, issues, pull requests e workflows.
O caso ganhou contornos ainda mais delicados porque o próprio repositório oficial da action da Anthropic utilizava o fluxo vulnerável. Em um cenário de exploração bem-sucedida, um invasor poderia injetar código malicioso na própria action e, a partir daí, comprometer todos os projetos que dependem dela, configurando um típico ataque à cadeia de suprimentos de software.
RyotaK reportou o bypass principal à Anthropic em janeiro. A empresa levou quatro dias para corrigir o problema inicial e, nos meses seguintes, continuou fortalecendo os mecanismos de segurança da ferramenta. As correções passaram a valer a partir da versão claude-code-action v1.0.94. Internamente, a Anthropic classificou a vulnerabilidade com pontuação 7,8 no CVSS v4.0 e recompensou o pesquisador por meio de seu programa de bug bounty.
Como funciona o Claude Code GitHub Action
O Claude Code GitHub Action foi criado para conectar o modelo Claude a pipelines de CI/CD, automatizando tarefas como:
– triagem e categorização de issues
– aplicação de labels
– revisão de pull requests
– execução de comandos via slash commands em comentários
Por padrão, o workflow que integra essa action pode receber permissões de leitura e escrita sobre o código-fonte, issues, pull requests, discussões e até arquivos de workflow do repositório. Na prática, isso significa que o agente de IA passa a ter poder para alterar partes críticas do projeto, inclusive a própria automação.
Essa combinação de privilégios torna o controle de acionamento da action um ponto extremamente sensível. Idealmente, somente usuários de confiança – normalmente quem já possui permissão de escrita no repositório – deveriam conseguir disparar comandos interpretados pelo agente. A vulnerabilidade descoberta estava justamente na etapa em que a action decidia se um determinado ator era confiável ou não.
O erro de confiar cegamente em “bots”
A lógica de autorização da action aceitava qualquer ator cujo nome terminasse com o sufixo “[bot]”, assumindo que se tratava de um GitHub App legítimo, instalado por administradores do repositório. Essa premissa, porém, ignora um detalhe crucial: qualquer pessoa pode registrar um GitHub App, instalá-lo em um repositório próprio e utilizar seus tokens para interagir com outros repositórios públicos.
Explorando essa brecha, um atacante poderia criar um GitHub App malicioso, obter um token associado a esse app e, com ele, abrir issues ou pull requests em projetos públicos que utilizassem o Claude Code com a configuração vulnerável. A action interpretaria essas interações como atividade de um “bot confiável” e processaria o conteúdo fornecido sem a devida validação, abrindo caminho para a execução de instruções maliciosas.
O impacto era mais crítico no modo “agent” da action. No modo “tag”, existia uma checagem extra para garantir que o ator fosse um usuário humano com certas características específicas. Já no modo “agent”, esse filtro adicional não estava presente, deixando todo o fluxo aberto ao abuso.
Da issue maliciosa ao controle do repositório: o papel do prompt injection
Uma vez que o atacante conseguia fazer com que a action aceitasse seu comando, o passo seguinte envolvia o uso de prompt injection indireto. Essa técnica consiste em esconder instruções maliciosas dentro de textos aparentemente inofensivos – por exemplo, em uma descrição de issue ou em um comentário – de modo que o sistema de IA, ao processar aquele conteúdo, obedeça a comandos ocultos em vez de seguir apenas a tarefa legítima.
No cenário construído por RyotaK, a issue maliciosa simulava uma mensagem de erro ou um bug complexo. O corpo do texto era elaborado para convencer o Claude a “diagnosticar” o problema executando comandos sugeridos no próprio conteúdo da issue. Após sucessivos ajustes no prompt, o pesquisador conseguiu que o agente “recuperasse” a execução, rodando comandos embutidos no texto sem que houvesse uma intenção explícita no workflow para isso.
O alvo principal do ataque passou a ser o arquivo `/proc/self/environ`, presente em sistemas Linux, que contém as variáveis de ambiente do processo em execução – entre elas, segredos e tokens usados pela própria automação. Embora o Claude Code tivesse uma proteção para bloquear leituras diretas desse arquivo, RyotaK encontrou uma forma de contornar essa barreira, induzindo o agente a capturar os valores e registrá-los de volta na própria issue.
Dessa forma, o invasor passava a ter acesso a dados sensíveis diretamente pela interface pública do repositório.
O que estava em risco: tokens, credenciais e supply chain
Entre todas as variáveis de ambiente expostas, o elemento mais crítico era o par de credenciais utilizado pelo GitHub Actions para obter um token OIDC (OpenID Connect). Esse token assinado comprova que determinado workflow realmente está sendo executado em determinado repositório e contexto, funcionando como uma espécie de identidade confiável do pipeline.
O fluxo normal do Claude Code consiste em trocar esse token OIDC com o backend da Anthropic para receber um token de instalação do Claude GitHub App, com permissões de escrita no repositório. Assim, o agente consegue criar ou atualizar código, issues e arquivos de workflow de forma legítima.
Se um atacante obtivesse essas credenciais por meio do ataque descrito, poderia replicar essa troca de tokens e, no fim do processo, conquistar acesso de escrita ao repositório alvo. Isso inclui:
– alterar arquivos de código
– editar ou criar novos workflows do GitHub Actions
– manipular issues e pull requests
– introduzir backdoors ou comportamentos maliciosos gradativamente
Em um cenário ainda mais grave, se o ataque fosse direcionado ao próprio repositório da claude-code-action, seria possível adulterar a action que inúmeros outros projetos utilizam. Dessa forma, o comprometimento se espalharia “rio abaixo”, caracterizando um ataque clássico à cadeia de suprimentos de software, em que uma dependência aparentemente confiável passa a distribuir código comprometido.
Configurações inseguras ampliavam a superfície de ataque
Além do bypass via “[bot]”, RyotaK encontrou outra rota de exploração, ainda mais simples, que dispensava o uso de GitHub Apps maliciosos. Um dos exemplos de workflow de triagem de issues, fornecido pela própria Anthropic, usava a opção `allowed_non_write_users: “*”`. Essa configuração permitia que qualquer usuário, mesmo sem permissão de escrita, acionasse a action.
Apesar de a documentação já alertar para o risco dessa configuração ampla, muitos mantenedores copiaram o exemplo literalmente em seus próprios repositórios, herdando a vulnerabilidade sem perceber. Bastava que um atacante abrisse uma issue bem construída para desencadear o fluxo de IA com privilégios elevados, repetindo a mesma cadeia de exploração.
Outro fator que aumentava o risco era o comportamento padrão de publicação de resumos de tarefas no painel público de execução do workflow. Em alguns casos, o Claude sintetizava o que havia feito e registrava essas informações em áreas de log acessíveis publicamente. Se durante a exploração algum dado sensível fosse processado ou retornado pelo agente, havia a chance de ele acabar exposto nesse painel, criando um canal direto de vazamento de informações.
Também existiam caminhos teóricos de exploração mesmo para invasores sem permissão formal de acionar o Claude diretamente, explorando interações indiretas, automações intermediárias ou integrações com outros bots e ferramentas. Qualquer ponto em que o conteúdo fornecido por usuários externos fosse repassado de forma pouco filtrada ao agente de IA se tornava um vetor potencial de ataque.
O que a correção mudou na prática
Com as atualizações lançadas a partir da versão v1.0.94, a Anthropic passou a endurecer significativamente as verificações de autorização. Entre as medidas adotadas, destacam-se:
– remoção da confiança genérica em atores com sufixo “[bot]”
– validações mais estritas para determinar quem pode acionar a action
– reforço nas recomendações de configuração segura, desencorajando o uso de curingas como `allowed_non_write_users: “*”`
– mitigação de caminhos de exfiltração de dados por meio de logs públicos ou mensagens de resumo
Além disso, a empresa ajustou o comportamento do agente para dificultar a leitura de arquivos sensíveis e reduzir a probabilidade de que instruções embutidas em conteúdo arbitrário prevaleçam sobre o objetivo original do workflow.
Lições para times de desenvolvimento e segurança
O incidente com o Claude Code expõe um conjunto de lições importantes para equipes que estão integrando IA generativa em seus pipelines de desenvolvimento:
1. Agentes de IA com permissão de escrita são equivalentes a colaboradores com acesso total. Eles devem ser tratados com o mesmo rigor de qualquer conta privilegiada, com políticas claras de quem pode acioná-los e em quais condições.
2. Configurações de exemplo não devem ser copiadas cegamente. Trechos de YAML fornecidos em documentações muitas vezes priorizam simplicidade e demonstratividade, não a segurança. É fundamental revisar criticamente cada permissão antes de adotá-la em produção.
3. Prompt injection é um risco real em automações de IA. Sempre que um agente consome conteúdo fornecido por usuários – issues, comentários, descrições de PR – existe potencial para que esse conteúdo tente subverter o comportamento da ferramenta.
4. Segredos em variáveis de ambiente continuam sendo um alvo central. Qualquer mecanismo que permita ao agente ler e refletir essas variáveis (mesmo indiretamente) precisa ser cuidadosamente controlado.
5. Logs públicos e mensagens de status podem vazar mais do que se imagina. Resumos automáticos gerados por IA, se não forem filtrados, podem acabar reproduzindo trechos de dados sensíveis manipulados no contexto do workflow.
Boas práticas para quem usa IA em CI/CD
Para organizações que já utilizam ou pretendem utilizar ações de IA em seus pipelines, alguns cuidados minimizam o risco de incidentes semelhantes:
– restringir o acionamento de actions de IA a usuários com permissão de escrita ou a grupos específicos
– evitar configurações amplas do tipo “qualquer usuário pode acionar esse fluxo”
– limitar o escopo de permissões do GitHub Actions ao mínimo necessário para cada tarefa
– isolar segredos sensíveis e, quando possível, usar tokens com escopo reduzido e curto tempo de vida
– revisar periodicamente workflows que envolvem IA, buscando pontos em que conteúdo externo é passado diretamente ao agente
– monitorar comportamentos anômalos, como commits inesperados feitos por bots ou alterações de workflows sem justificativa
IA, automação e o novo perímetro de segurança
O episódio da Claude Code GitHub Action ilustra uma tendência mais ampla: à medida que agentes de IA ganham poder de agir autonomamente em ambientes de desenvolvimento, eles se tornam parte crítica da superfície de ataque. Não se trata apenas de “modelos que respondem perguntas”, mas de sistemas capazes de executar comandos, alterar código e orquestrar pipelines inteiros.
Nesse contexto, segurança passa a significar também projetar prompts robustos, limitar cuidadosamente o acesso da IA ao ambiente e estabelecer políticas claras sobre como e quando esses agentes podem ser acionados. Ferramentas poderosas, se configuradas de forma ingênua, podem transformar uma simples issue em porta de entrada para o sequestro de repositórios inteiros.
A atuação rápida da Anthropic reduziu o tempo de exposição, mas o caso serve de alerta: integrar IA a processos de desenvolvimento exige o mesmo nível de atenção aplicado a qualquer componente crítico de infraestrutura. Quem ignora esse aspecto corre o risco de descobrir, tardiamente, que um comentário aparentemente inocente foi o primeiro passo de um ataque à sua cadeia de suprimentos de software.