Um pesquisador de segurança descobriu uma falha no Claude Code GitHub Action, da Anthropic, que permitia a um invasor assumir o controle de repositórios públicos vulneráveis que o executavam, bastando para isso abrir uma única issue no GitHub. Como o próprio repositório da ação mantido pela Anthropic utilizava o mesmo fluxo de trabalho, um ataque bem-sucedido poderia ter injetado código malicioso na própria ação e em todos os projetos a jusante que a consomem.
RyotaK, da GMO Flatt Security, reportou a falha central de bypass à Anthropic em janeiro, e a empresa corrigiu o problema em quatro dias, com reforços adicionais ao longo da primavera; as correções estão na versão 1.0.94 do claude-code-action. A Anthropic classificou a gravidade com nota 7,8 no CVSS v4.0 (Sistema de Pontuação de Vulnerabilidades Comuns, versão 4.0) e pagou uma recompensa pelo bug.
Como o Claude Code GitHub Actions opera
O Claude Code GitHub Actions insere o Claude em pipelines de CI/CD (integração contínua e entrega contínua) para triar issues, aplicar etiquetas, revisar pull requests (solicitações de merge de código) ou executar comandos de barra. Por padrão, o fluxo de trabalho recebe acesso de leitura e escrita ao código, às issues, aos pull requests, às discussões e aos arquivos de workflow do repositório. Como essas permissões são amplas, a ação deveria ser criteriosa sobre quem pode acioná-la: apenas usuários com permissão de escrita.
A brecha na verificação de gatilho
A verificação de gatilho tinha um buraco. Ela liberava a passagem para qualquer ator cujo nome terminasse em [bot], partindo do pressuposto de que os GitHub Apps (aplicativos integráveis do GitHub) são componentes confiáveis instalados por administradores. O problema é que qualquer pessoa pode registrar um GitHub App, instalá-lo em um repositório próprio e usar o token (chave de acesso) correspondente para abrir uma issue ou pull request em qualquer repositório público. A ação via "um bot" e deixava passar o conteúdo do invasor. O modo tag tinha uma verificação extra para confirmar que o ator era um humano real; o modo agent não tinha, o que o deixou exposto.
Injeção indireta de prompt
A partir daí, o invasor se apoia na injeção indireta de prompt, isto é, plantar instruções dentro de conteúdo que uma IA lê para que o modelo as siga em vez da sua tarefa real. RyotaK escreveu uma issue cujo corpo parecia uma mensagem de erro e, em seguida, refinou o prompt até que o Claude "se recuperasse" executando os comandos embutidos nela. O alvo é o arquivo /proc/self/environ, o arquivo do Linux que guarda as variáveis de ambiente de um processo, incluindo segredos. O Claude Code bloqueia leituras ingênuas, mas RyotaK contornou a proteção mesmo assim e fez o Claude gravar os valores de volta na issue, onde o invasor pode coletá-los.
O verdadeiro prêmio: o token OIDC
O verdadeiro prêmio nessas variáveis é o par de credenciais que o GitHub Actions usa para solicitar um token OIDC (token de identificação OpenID Connect, um token assinado que comprova "sou este workflow rodando neste repositório"). O Claude Code troca esse token pelo backend da Anthropic para obter um token de instalação do Claude GitHub App com acesso de escrita. Roube essas credenciais, replique a troca e você terá acesso de escrita ao código, às issues e aos workflows do alvo. Mire no próprio repositório claude-code-action e você poderá envenenar a ação que os projetos a jusante consomem.
Uma rota alternativa mais simples
RyotaK também apontou um caminho mais suave, que dispensava totalmente o truque do bot. O exemplo de workflow de triagem de issues fornecido pela própria Anthropic vinha com a configuração allowed_non_write_users: "*", que permite que qualquer pessoa o acione, um ajuste que a documentação da Anthropic já sinaliza como arriscado. Pior: o Claude publicava resumos das tarefas no painel de resumo do workflow, publicamente visível, uma forma pronta de vazar dados. Muitos repositórios copiaram esse exemplo e herdaram a falha.
Há também um caminho para um invasor que pode editar issues, mas não consegue acionar o Claude por conta própria: editar a issue de um usuário confiável depois que ela disparou o workflow, mas antes de o Claude lê-la, e o payload entra como entrada "confiável".
O que fazer
Atualize para a versão 1.0.94 ou posterior do claude-code-action. Em seguida, audite qualquer workflow que permita que usuários sem permissão de escrita, ou bots, acionem o Claude: se ele estiver recebendo entrada não confiável, não o alimente com nenhum segredo além da chave de API da Anthropic e do GITHUB_TOKEN, e remova ferramentas e permissões que possam ser usadas para exfiltração de dados.
Casos reais anteriores
Nada disso é teórico. A mesma configuração, um triador de issues com IA somado a permissões amplas e injeção de prompt, já causou um impacto real na cadeia de suprimentos:
- Em fevereiro, um título de issue com prompt injetado contra o workflow de triagem claude-code-action do Cline permitiu que invasores roubassem um token de publicação do npm e enviassem uma versão não autorizada, a cline@2.3.0. A versão rogue apenas forçava a instalação de um agente de IA separado, não malicioso, e foi removida cerca de oito horas depois, mas a mesma cadeia poderia ter distribuído malware de verdade para todos que atualizassem.
- O bot autônomo "HackerBot-Claw" passou o final de fevereiro sondando configurações incorretas do GitHub Actions na Microsoft, Datadog, em projetos da CNCF (Cloud Native Computing Foundation) e em outros. Quando ele tentou injetar prompt em um revisor baseado em Claude por meio de um arquivo de configuração envenenado, o Claude identificou a tentativa e se recusou a prosseguir.
Não há indícios públicos de que esse caminho exato, o que envenena a própria ação da Anthropic, tenha sido usado contra um alvo real; RyotaK o comprovou apenas em seus próprios repositórios de teste e faz questão de separá-lo das variantes acima, que de fato foram exploradas.
RyotaK afirma ter reportado cerca de 50 formas distintas de burlar o sistema de permissões do Claude Code e executar comandos, parte de uma sequência constante de falhas de injeção de prompt em agentes de codificação com IA. A injeção de prompt continua sem solução, e um agente com ferramentas reais e tokens reais pode ser empurrado até onde suas permissões permitirem.
Nenhum comentário publicado até agora.