Olá a todos!
Hoje vim cá vos alertar de mais um filme que está a ocorrer, não porque seja um ataque de dia zero com exploits exóticos e técnicas de hacking de cinema, mas precisamente pelo contrário. Porque é assustadoramente simples, assustadoramente elegante, e porque podia ter sido catastroficamente pior do que foi. Estou a falar do ataque de supply chain ao Cline CLI que aconteceu a 17 de fevereiro de 2026, e que instalou silenciosamente o OpenClaw em milhares de máquinas de developers durante uma janela de oito horas.
Se usam o Cline CLI no vosso workflow de desenvolvimento — e muitos de vós usam, porque é um assistente de codificação com IA genuinamente útil — leiam isto até ao fim.
O que aconteceu, em linguagem humana
A 17 de fevereiro de 2026, às 3:26 da manhã (hora do Pacífico), alguém publicou a versão 2.3.0 do pacote cline no registry npm. Não foi um dos maintainers do projeto. Foi um atacante que obteve acesso a um npm publish token comprometido.
O que esse atacante fez com esse acesso? Poderia ter injetado malware direto. Poderia ter roubado credentials. Poderia ter instalado um backdoor que ficasse quieto durante semanas. Em vez disso — e aqui está a parte que levanta mais questões do que respostas — limitou-se a adicionar uma linha ao package.json:
"postinstall": "npm install -g openclaw@latest"
Uma linha. É tudo. Quando qualquer developer instalava [email protected], o npm executava automaticamente esse postinstall script, e o OpenClaw era instalado globalmente na sua máquina. Sem confirmação. Sem aviso. Silenciosamente, em background, no contexto da instalação de uma ferramenta de desenvolvimento que o developer estava ativamente a confiar.
Segundo os dados da StepSecurity, o pacote comprometido foi descarregado aproximadamente 4.000 vezes durante essa janela de oito horas, antes de os maintainers do Cline conseguirem revogar o token comprometido e publicar a versão 2.4.0 às 11:30 da manhã. A Microsoft Threat Intelligence confirmou que observou um aumento notório nas instalações de OpenClaw nesse dia, diretamente atribuível ao compromisso.
“Mas o OpenClaw não é malware…”
E aqui está onde eu preciso de parar e ter uma conversa honesta convosco, porque ouvi esta frase repetida várias vezes nas horas que se seguiram ao incidente, e acho que ela representa uma falha perigosa de raciocínio.
É verdade. O OpenClaw em si não é malware. É um agente de IA autónomo self-hosted, que ganhou popularidade considerável nos últimos meses. Os maintainers do Cline foram explícitos no seu advisory: não foi observado comportamento malicioso, e a instalação do OpenClaw não incluiu o arranque do daemon Gateway que seria necessário para atividade de rede. O impacto imediato foi considerado baixo pelo investigador Henrik Plate da Endor Labs.
Mas — e este “mas” é enorme — o facto de desta vez o payload ter sido benigno não significa que o ataque foi benigno. Um atacante que tinha acesso ao npm publish token do Cline podia ter publicado qualquer coisa. Podia ter injetado um keylogger. Podia ter instalado um cryptominer. Podia ter exfiltrado as API keys e tokens que os vossos projetos de desenvolvimento têm espalhados por ficheiros .env. Podia ter instalado um backdoor que dormia durante trinta dias antes de ativar.
O facto de não ter feito isso é uma sorte. Não é uma proteção. E confundir sorte com proteção é um dos erros mais caros que se pode cometer em segurança informática.
A anatomia técnica: Clinejection e cache poisoning
Agora a parte que genuinamente me fez levantar as sobrancelhas, porque a técnica usada para obter o token comprometido — caso a análise da mbgsec.com esteja correta, o que parece ser o caso — não é um simples phishing de credenciais. É uma cadeia de ataque sofisticada que combina prompt injection, GitHub Actions cache poisoning, e má configuração de permissões.
Tudo começa com algo que o investigador de segurança Adnan Khan descobriu e baptizou de Clinejection. O repositório do Cline tem um workflow automatizado no GitHub Actions que, quando é aberta uma nova issue, lança automaticamente o Claude com acesso ao repositório e a um conjunto alargado de ferramentas para fazer triagem e responder à issue. A ideia é legítima e compreensível — automatizar a primeira resposta para reduzir a carga dos maintainers.
O problema é que este workflow foi configurado com permissões excessivas que permitiam execução de código arbitrário no branch principal. E quando combinamos permissões excessivas com um agente de IA que processa input não confiável — neste caso, o título de uma issue aberta por qualquer utilizador com conta GitHub — temos os ingredientes perfeitos para prompt injection.
A sequência de ataque funciona assim: um atacante abre uma issue com um título especialmente construído que instrui o agente Claude a executar comandos arbitrários. Claude, seguindo as instruções no contexto da issue, executa esses comandos dentro do workflow de triagem. O atacante usa essa execução para encher a cache do GitHub Actions com mais de 10GB de dados de lixo, forçando a política LRU de eviction do GitHub a remover entradas legítimas. Em seguida, injeta entradas de cache envenenadas que correspondem às cache keys usadas pelo workflow de publicação noturna. Quando o workflow de publicação corre às 2 da manhã UTC e vai buscar a sua cache, apanha as entradas envenenadas — e nesse contexto com privilégios muito maiores, o atacante consegue exfiltrar os tokens de publicação.
É uma cadeia de ataque elegante no pior sentido da palavra. Cada passo usa uma técnica conhecida — prompt injection, GitHub Actions cache poisoning, privilege escalation via cache — mas a combinação dos três numa sequência coordenada é sofisticada.
O Chris Hughes da Zenity disse algo no comunicado partilhado com o The Hacker News que ficou a ressoar comigo: “Temos falado de supply chain security de IA em termos teóricos durante demasiado tempo, e esta semana tornou-se numa realidade operacional. Quando um único título de issue pode influenciar um pipeline de build automatizado e afetar um release publicado, o risco já não é teórico.”
Não podia estar mais de acordo.
O que isto significa para vós, concretamente
Se instalaram [email protected] entre as 3:26 e as 11:30 da manhã do dia 17 de fevereiro de 2026, aqui está o que devem fazer.
Primeiro, verifiquem se o OpenClaw está instalado globalmente no vosso sistema. Corram npm list -g openclaw e which openclaw. Se estiver presente e não o instalaram intencionalmente, removam-no com npm uninstall -g openclaw.
Segundo, atualizem para [email protected] ou superior. A versão 2.3.0 foi depreciada pelo npm e o token comprometido foi revogado, mas mais vale garantir que estão numa versão limpa.
Terceiro, e este é o ponto mais importante: reflitam sobre o vosso modelo de confiança em relação ao npm. Quantos pacotes têm instalados globalmente na vossa máquina de desenvolvimento? Sabem quem são os maintainers de cada um? Verificam os postinstall scripts antes de instalar?
Provavelmente não. Eu também não fazia isso sistematicamente antes deste incidente começar a fazer-me pensar mais seriamente no assunto.
O problema real: AI agents como atores privilegiados
Mas o que me preocupa genuinamente neste incidente vai além do ataque específico. O que me preocupa é o padrão que está a emergir.
Estamos numa fase em que as ferramentas de IA estão a ser integradas em pipelines de desenvolvimento com um entusiasmo completamente desproporcionado à nossa compreensão dos riscos. O workflow do Cline que permitiu este ataque foi bem-intencionado — automatizar triagem de issues é uma ideia razoável. Mas quem o configurou não pensou suficientemente na pergunta: “O que acontece se alguém tentar abusar deste agente?”
E a resposta, neste caso, foi: acontece cache poisoning, privilege escalation, e um supply chain attack a uma ferramenta com dezenas de milhares de utilizadores.
Os agentes de IA com acesso a repositórios, capacidade de executar código, e permissões de publicação são atores privilegiados. Precisam de ser tratados como tal. Precisam de ter o menor privilégio possível. Precisam de operar em sandboxes. Precisam de ter as suas ações monitorizadas e auditadas. E acima de tudo, precisam de ser configurados por pessoas que pensaram seriamente em como um atacante pode abusar deles.
O Henrik Plate foi certeiro na análise que publicou: este evento sublinha a necessidade de os maintainers de pacotes não só habilitarem trusted publishing, mas também desabilitarem a publicação via tokens tradicionais. A distinção é importante — o mecanismo de OIDC via GitHub Actions que o Cline adoptou após o incidente é substancialmente mais difícil de comprometer, porque os tokens são efémeros e vinculados a workflows específicos, em vez de serem secrets de longa duração que podem ser exfiltrados e reutilizados.
A lição do trusted publishing
Vou aproveitar esta secção para ser didático, porque acho que este ponto merece mais atenção do que normalmente recebe.
O modelo tradicional de publicação no npm — e no PyPI, e noutros registries — funciona com tokens de longa duração. Criam um token, guardam-no como secret no vosso CI/CD, e esse token é válido enquanto não o revogarem. O problema é óbvio: se alguém conseguir esse token — por phishing, por exfiltração via um workflow comprometido, por um desenvolvedor que o guardou no lugar errado — tem acesso completo à vossa conta de publicação até vocês darem conta e revogarem.
O trusted publishing muda este modelo. Em vez de usar um token de longa duração, o workflow de CI/CD usa OIDC para se autenticar diretamente com o registry, obtendo um token efémero que é válido apenas para aquela execução específica do workflow. O token não pode ser exfiltrado e reutilizado noutro contexto, porque expira em minutos e está criptograficamente vinculado ao workflow que o pediu.
Não é uma solução mágica — um workflow suficientemente comprometido pode usar o token efémero durante a sua execução — mas eleva substancialmente a fasquia para um atacante. E neste caso específico, se o Cline tivesse usado OIDC desde o início e desabilitado os tokens tradicionais, o NPM_RELEASE_TOKEN exfiltrado não teria servido de nada.
A questão é: quantos dos pacotes npm que usam no vosso dia a dia ainda publicam com tokens tradicionais? A resposta é: provavelmente a maioria.
Protejam os vossos pipelines de desenvolvimento
Deixem-me terminar com algumas recomendações concretas, porque alertas sem acção prática são de pouca utilidade.
Se são maintainers de pacotes npm, PyPI, ou outros registries, migrem para trusted publishing já. Não é complicado, está bem documentado, e remove uma classe inteira de riscos. Desabilitem os tokens tradicionais após a migração. Não os deixem como fallback — são uma porta traseira que não precisam.
Se usam GitHub Actions, auditem as permissões dos vossos workflows. O princípio do menor privilégio aplica-se aqui com força redobrada quando há agentes de IA envolvidos. Um workflow de triagem de issues não precisa de permissões de escrita no repositório. Um agente que responde a issues não precisa de acesso aos vossos secrets de publicação. Separem as permissões com cirurgia, não com um bisturi.
Se integram agentes de IA no vosso pipeline de desenvolvimento — e cada vez mais equipas fazem isso — tratem-nos como se fossem utilizadores externos com acesso limitado, não como extensões confiáveis da vossa equipa. Qualquer input que o agente processa pode potencialmente ser controlado por um atacante. Qualquer ferramenta que o agente tem acesso é uma superfície de ataque potencial.
E se instalam ferramentas de desenvolvimento via npm, pip, ou outros gestores de pacotes, desenvolvam o hábito de rever os postinstall scripts de pacotes que vos dão acesso significativo ao sistema. Não é uma solução escalável para todos os pacotes — ninguém consegue auditar centenas de dependências transitivas — mas para ferramentas que instalais globalmente com npm install -g, vale a pena os trinta segundos que demora.
Última nota
O Cline respondeu bem a este incidente — comunicação transparente, advisory detalhado, revogação rápida do token comprometido, e adoção de OIDC para publicação futura. Isso merece reconhecimento. Não foi o Huntarr a censurar reports e a banir utilizadores que levantam preocupações legítimas.
Mas a velocidade da resposta depois do facto não substitui a necessidade de melhor configuração à partida. E o facto de o payload ser benigno desta vez é uma sorte que não devemos confundir com competência ou proteção.
O Chris Hughes disse que a indústria precisa de reconhecer os agentes de IA como atores privilegiados que requerem governance. Concordo completamente. E acrescentaria: a indústria também precisa de parar de configurar esses agentes com permissões de “funciona” em vez de permissões de “mínimo necessário.”
Porque a próxima vez, o atacante pode não ter a contenção de instalar apenas o OpenClaw.
Mantenham-se vigilantes, auditem os vossos postinstall scripts, e migrem para trusted publishing.
Um abraço, Nuno
P.S.: Se são maintainers de projetos open source e ainda usam tokens tradicionais de longa duração para publicar nos vossos registries, este é o vosso sinal. A documentação do npm sobre trusted publishing está em docs.npmjs.com. A do PyPI está em docs.pypi.org. Não é uma tarde de trabalho. Pode ser a tarde de trabalho que evita que o vosso projeto seja o próximo caso de estudo num post como este.