A cadeia de fornecimento de software em jaque: o ataque a Cline que instalou o OpenClaw sem permissão

Esta semana foi confirmado outro episódio preocupante na segurança da cadeia de fornecimento de software: a ferramenta de ajuda para programadores Cline CLI, um projeto de código aberto que integra capacidades de inteligência artificial, foi publicada na rede npm em uma versão comprometida que incluía uma instrução para instalar de forma silenciosa o agente autônomo OpenClaw. O pacote em causa foi cline@ 2.3.0, e a publicação não autorizada ocorreu em 17 de fevereiro de 2026 usando um token de publicação que, segundo os mantenedores, havia sido comprometido. O comunicado oficial pode ser consultado no aviso de segurança do projeto no GitHub: GHSA-9ppg-jx86-fqw7.

O pacote publicado incluía uma modificação em package.json que adicione um programa de pós-instalação cujo efeito foi executar npm install - g openclaw@ latest. Isso provocou que, durante um período de aproximadamente oito horas entre as 3:26 e as 11:30 PT de 17 de fevereiro, qualquer desenvolvedor que instalasse essa versão recebesse a instalação automática de OpenClaw em seu ambiente. Os responsáveis pela Cline afirmam que não se detectou outro código malicioso dentro do pacote, e que a instalação do OpenClaw não foi concebida nem autorizada; ainda assim, o fato de que um agente autônomo pudesse se distribuir assim gera inquietação.

Os mantenedores responderam retirando a versão afetada e publicando rapidamente cline@ 24. 0, além de desativar o token comprometido e marcando a 2.3.0 como deprecada. Também anunciaram mudanças no seu mecanismo de publicação que incorporam o OpenID Connect (OIDC) desde o GitHub Actions para reduzir a dependência de tokens estáticos e minimizar esse tipo de risco. O fluxo de notícias técnicas foi documentando a reação e o alcance: por exemplo, a Microsoft Threat Intelligence observou em sua conta de X um aumento nas instalações do OpenClaw coincidete com o incidente ( ver publicação), e assinaturas de segurança estimaram que a versão comprometida se descarregou milhares de vezes durante a janela de exposição, segundo dados compartilhados por StepSecurity.

Embora o OpenClaw em si não seja considerado malware e, segundo a análise da assinatura Endor Labs, a publicação não continha componentes que arrancaram serviços perigosos de forma imediata, este acontecimento é um lembrete de que a instalação indesejada de software com privilégios pode se tornar uma porta de entrada para ataques mais graves. Como explicou o pesquisador Henrik Plate de Endor Labs, o impacto técnico imediato pode ser limitado, mas a lição operacional é clara: Os mantenedores devem forçar mecanismos de publicação confiáveis e os usuários devem monitorar as atestações e assinaturas associadas às releases. A análise completa do Endor Labs está disponível aqui: Endor Labs – análise do incidente.

A pesquisa sobre como a capacidade de publicar a versão maliciosa aponta para uma cadeia de exploração mais complexa que envolve agentes de IA utilizados nos fluxos de trabalho de triage de issues. O pesquisador Adnan Khan detectou que o repositório de Cline tinha um workflow que, ao abrir uma incidência, levantava um agente Claude com acesso à base de código e ferramentas adicionais para gerar respostas automáticas. Essa automação, pensada para aliviar a carga dos mantenedores, outorgava excessivas permissões ao agente, e um título de issue cuidadosamente construído poderia induzir a IA a executar comandos arbitrários: uma técnica que Khan bautizou como "Clinejection". Sua explicação técnica e provas estão publicadas em seu blog: Clinejection — análise de Adnan Khan. O commit que introduziu a mudança susceptível de exploração também pode ser consultado no repositório: commit de dezembro de 2025.

A sequência de ataque descrita por Khan combina prompt injection contra agentes de IA com uma técnica de envenenamento de cache no GitHub Actions para conseguir execução em um workflow de publicação com permissões elevadas. O atacante primeiro provoca que o sistema de triage execute código malicioso, depois reche a cache com dados que provocam a expulsão de entradas legítimas e coloca entradas “envenenadas” que coincidem com as chaves usadas pelos jobs noturnos de publicação. Quando a rotina de publicação noturna é executada e encontra essas entradas manipuladas, recupera artefatos e credenciais que permitem a quem controla o fluxo publicar artefatos em npm com tokens de produção. Khan já havia escrito sobre este tipo de risco em análises anteriores sobre o GitHub Actions cache poisoning: The monsters in your build cache.

Pesquisadores externos confirmaram que a cadeia de exploração descrita foi, em essência, a que derivou na publicação de [email protected] com o script de pós-instalação. Um relatório técnico que resume achados e correlações está disponível no blog do MBG Security, que detalha como se chegou a aproveitar um token ativo de publicação em npm para assinar e aumentar o pacote comprometido: MBG Security – pesquisa do compromisso. Complementariamente, a análise e a cobertura do caso por meios de segurança especializados ajudam a entender o panorama: socket.dev – análise do ataque e uma nota mais geralista com reações da indústria The Hacker News.

Para além dos detalhes técnicos imediatos, a comunidade de segurança observa uma conclusão prática: os agentes de IA incorporados em pipelines e máquinas não são atores neutros; quando recebem permissões amplas, atuam como componentes privilegiados do sistema. Chris Hughes, responsável pela estratégia de segurança em Zenity, sintetizou esta ideia ao sublinhar que o que antes se debatia em abstracto sobre a segurança de agentes autónomos agora tem um custo operacional tangível e exige governação e controlos de acesso específicos. A nota com sua declaração está coletada na cobertura do incidente por The Hacker News.

Se você usa Cline ou gerencia repositórios que utilizam máquinas semelhantes, as medidas imediatas que recomendam as equipes de resposta e os pesquisadores são claras: atualizar à versão corrigida, revisar o ambiente por instalações inesperadas de OpenClaw e remover qualquer componente não requerido, rotar tokens e credenciais que poderiam ter sido expostas, e endurecer os workflows para que os agentes de IA não recebam permissões para executar código com privilégios de publicação. Também convém adotar OIDC para a publicação desde o GitHub Actions e desativar a publicação por tokens tradicionais quando possível, bem como adicionar verificações de atestação e assinaturas nos pipelines de entrega.

Este incidente destaca que a adoção de IA em desenvolvimento e operações traz benefícios, mas também introduz novos vectores de ataque. A segurança da cadeia de abastecimento já não é apenas da responsabilidade dos mantenedores de pacotes: envolve equipamentos de infra, desenvolvedores e plataformas que orquestram máquinas. Manter a confiança nos pacotes que instalamos exige, agora mais do que nunca, controlos finos sobre quem ou o que pode publicar, rastreabilidade das publicações e auditorias regulares dos fluxos automatizados.