Clinejection: Três Fraquezas Que Ninguém Corrigiu a Tempo

Em nossa análise anterior do Clinejection, percorremos os cinco passos do ataque: de um título de issue no GitHub a 4.000 máquinas comprometidas via npm. Aquele artigo descreveu a mecânica. Este examina algo diferente: por que a infraestrutura permitiu cada passo, e o que a resposta da equipe revela sobre o estado real da segurança em projetos com agentes de IA.

O Clinejection não foi um ataque sofisticado. Foi um ataque composto. Três fraquezas independentes, cada uma tolerável isoladamente, se combinaram para criar um vetor que nenhum controle pontual conseguiria bloquear. E a janela entre o primeiro aviso e a exploração foi de 47 dias.

Primeira Fraqueza: O Bot Que Obedecia a Qualquer Um

O repositório do Cline usava um agente Claude para triagem automática de issues. A configuração concedia acesso total ao Bash. O parâmetro allowedNonWriteUsers estava definido como '*', o que significa: qualquer usuário do GitHub podia acionar o bot. Qualquer um.

Um bot de triagem não precisa executar código. Precisa ler títulos, aplicar rótulos, postar comentários. Dar acesso shell a um agente de IA que processa input de qualquer usuário da internet é, nas palavras do próprio post-mortem da Cline, “funcionalmente equivalente a dar a todos os usuários do GitHub acesso shell.”

A equipe reconheceu isso depois. O problema é que essa configuração existia antes. Alguém escreveu allowedNonWriteUsers: '*' e colocou em produção. Alguém revisou (ou não revisou) essa decisão. O princípio do menor privilégio existe há décadas. Não foi aplicado.

Injeção de prompt em agentes de IA não é um vetor teórico. Como exploramos na análise dos Agentic Workflows do GitHub, o modelo de segurança que o GitHub construiu para seus agentes é deliberadamente restritivo: agentes operam em modo somente leitura por padrão, e qualquer escrita passa por buffer humano. O Cline fez o oposto. Deu acesso total. E pagou o preço.

Segunda Fraqueza: O Cache Que Ninguém Verificava

Com acesso ao ambiente de CI/CD via bot comprometido, o atacante usou uma ferramenta open-source chamada Cacheract para inundar o cache do GitHub Actions além do limite de 10 GB. Quando o cache atingiu a capacidade máxima, o mecanismo de evicção LRU (Least Recently Used) descartou entradas legítimas. O atacante plantou entradas envenenadas de node_modules no lugar.

Na execução seguinte do workflow de release noturno, o pipeline restaurou dependências do cache. Recebeu código do atacante como se fosse código legítimo. Sem verificação de hash. Sem validação de integridade. O cache era tratado como infraestrutura interna confiável.

Cache poisoning em GitHub Actions não é uma técnica nova. A ferramenta usada é pública. A documentação de como explorar evicção LRU está disponível. O ataque exigiu, nas palavras do pesquisador Adnan Khan, “não mais que uma conta GitHub e conhecimento de técnicas publicamente documentadas.”

A prevenção também não exigia nada novo. Checksums no conteúdo do cache. Assinatura das entradas. Validação antes da restauração. Técnicas que existem desde antes do GitHub Actions existir.

Terceira Fraqueza: Credenciais Que Sobreviveram à Rotação

Aqui o ataque se torna estudo de caso em teatro de segurança.

O repositório do Cline migrou para autenticação OIDC. Mas os tokens anteriores, incluindo o NPM_RELEASE_TOKEN, permaneceram ativos. Tokens noturnos e de produção compartilhavam o mesmo escopo. Comprometer o pipeline noturno dava acesso à publicação de produção.

Quando a divulgação pública aconteceu em 9 de fevereiro, a equipe “rotacionou” credenciais. Oito dias depois, em 17 de fevereiro, o token npm ainda funcionava. O atacante publicou cline@2.3.0 com um script postinstall que instalava o OpenClaw globalmente. Quatro mil downloads em oito horas.

Rotação de credenciais sem verificação de revogação é ritual, não segurança. Se você troca a fechadura mas não confirma que a chave antiga parou de funcionar, não fez nada.

O Payload e a Ironia

O pacote comprometido instalava o OpenClaw. Como analisamos em nosso artigo sobre a confusão entre OpenClaw e Claude Code, o OpenClaw é um projeto legítimo de IA: um assistente pessoal open-source que conecta WhatsApp, email e calendário. Não é malware. É uma ferramenta real criada por um desenvolvedor real.

A ironia é precisa. Um agente de IA (o bot de triagem do Cline) foi comprometido via injeção de prompt para instalar silenciosamente outro projeto de IA (OpenClaw) em máquinas de desenvolvedores que usam uma terceira ferramenta de IA (o Cline). Três camadas de IA, nenhuma governança entre elas.

O atacante escolheu um payload benigno. Poderia ter escolhido qualquer coisa. Ransomware. Exfiltração de chaves SSH. Minerador de criptomoedas. A infraestrutura não distinguiu entre o payload real e essas alternativas. O enquadramento de “baixo impacto” que apareceu em algumas análises iniciais confunde a escolha do atacante com a capacidade de defesa. São coisas diferentes.

O Silêncio de 39 Dias

A cronologia da divulgação responsável conta sua própria história.

1º de janeiro de 2026: Adnan Khan submete um relatório de segurança (GHSA) ao projeto Cline detalhando a vulnerabilidade de injeção de prompt no bot de triagem. 8 de janeiro: email de follow-up. Sem resposta. 18 de janeiro: mensagem direta ao CEO da Cline no X (antigo Twitter). Ignorada.

9 de fevereiro: Khan publica a divulgação após 39 dias sem resposta. A equipe do Cline corrige em 30 minutos.

Trinta minutos para corrigir. Trinta e nove dias para começar. O problema nunca foi capacidade técnica. Foi prioridade operacional. Divulgação de vulnerabilidade tratada como sugestão, não como incidente.

Entre 10 e 11 de fevereiro, a equipe reportou ter “rotacionado” credenciais. Seis dias depois, o token npm foi explorado com sucesso. A rotação não funcionou, não foi verificada, ou não incluiu o token correto.

O Que as Três Fraquezas Ensinam Juntas

Individualmente, cada falha é corrigível em minutos. Restringir permissões do bot. Assinar o cache. Revogar tokens legados. Nenhuma exige investimento significativo ou tecnologia nova.

Juntas, revelam um padrão mais profundo. Nenhuma dessas decisões foi tomada por malícia. Foram tomadas por conveniência, por inércia, por falta de revisão. Alguém configurou allowedNonWriteUsers: '*' porque era mais fácil. Alguém deixou tokens legados ativos porque desabilitá-los exigia coordenação. Alguém não implementou validação de cache porque “cache é interno.”

Chris Hughes, da Zenity, resumiu: “Quando um simples título de issue pode influenciar um pipeline de build automatizado, o risco não é mais teórico.” O risco nunca foi teórico. O que mudou é que agora temos o caso documentado.

Organizações que operam agentes de IA em sua infraestrutura de desenvolvimento precisam responder três perguntas hoje. Quais agentes têm acesso a ferramentas de execução? Quais credenciais estão acessíveis a processos de build? E qual é o tempo médio entre um relatório de vulnerabilidade e uma ação concreta?

Se a resposta a qualquer uma dessas perguntas é “não sei,” o playbook do Clinejection está público. O próximo atacante não precisa inventar nada. Precisa encontrar um alvo que ainda opera sob as mesmas três premissas.

Fontes

Cline. “Post-Mortem: Unauthorized Cline CLI NPM.” Fevereiro 2026.
Adnan Khan. “Clinejection.” Fevereiro 2026.
GitHub Advisory. “GHSA-9ppg-jx86-fqw7.” Fevereiro 2026.
Snyk. “Cline Supply Chain Attack: Prompt Injection & GitHub Actions.” Fevereiro 2026.
The Hacker News. “Cline CLI 2.3.0 Supply Chain Attack.” Fevereiro 2026.

Victorino Group ajuda organizações a governar agentes de IA antes que se tornem vetores de ataque na cadeia de suprimentos: contato@victorino.com.br | www.victorino.com.br