O Runtime do Agente Virou a Nova Superfície de Persistência

Em 11 e 12 de maio de 2026, a campanha Mini Shai-Hulud atingiu uma escala que vira a história conhecida do avesso. A Socket contou 416 artefatos de pacote comprometidos entre npm e PyPI. A Aikido registrou 373 entradas maliciosas de versão de pacote distribuídas em 169 nomes no npm. A Endor Labs colocou o número no npm acima de 160. A lista de namespaces afetados parece um inventário do stack moderno: TanStack, Mistral AI, Guardrails AI, OpenSearch, UiPath, Bitwarden CLI e os pacotes oficiais da SAP. Só o @tanstack/react-router movimenta 12 milhões de downloads semanais.

A história conhecida é “um pacote malicioso foi publicado, audite suas dependências, fixe as versões”. Essa história não basta mais. A mecânica nova, reportada pela BleepingComputer e confirmada por Snyk e StepSecurity, é o que o malware faz depois que o npm install termina. Ele se grava em hooks do Claude Code e em tarefas de execução automática do VS Code. Desinstalar a versão ruim não remove a infecção. O pacote some. O hook fica. O runtime do agente executa o payload em toda sessão seguinte.

Essa é uma mudança de categoria, e ela merece nome. O runtime do agente, aquele diretório de dotfiles que você trata como configuração de desenvolvedor, agora é uma superfície de nível persistência.

O Que Aconteceu de Fato

Snyk e StepSecurity descrevem uma campanha coordenada e auto-propagante atribuída a um grupo que se apresenta como TeamPCP, construindo em cima do worm Shai-Hulud original que atingiu o npm no final de 2025. A mecânica é consistente entre as detecções de Socket, Endor Labs, Aikido, StepSecurity, Snyk, Microsoft Threat Intelligence, SafeDep e Wiz. O malware coleta credenciais da máquina do desenvolvedor na primeira execução: chaves SSH, credenciais AWS, tokens do GitHub CLI, tokens npm, credenciais RubyGems, arquivos .netrc, contas de serviço Kubernetes. Ele exfiltra tudo e usa os tokens de publicação roubados para empurrar versões envenenadas dos pacotes que a vítima mantém. Esse é o loop auto-propagante. Uma máquina de mantenedor comprometida vira a fonte de publicação da próxima onda.

A etapa de persistência é a peça nova. A BleepingComputer reporta que o payload se instala em hooks do Claude Code e em tarefas de execução automática do VS Code na máquina do desenvolvedor. Hooks disparam em eventos documentados do agente. Tarefas de execução automática disparam ao abrir o workspace. As duas superfícies executam comandos shell. As duas vivem em diretórios versionados ou em nível de usuário que nenhuma ferramenta de detecção de endpoint observa como ponto de execução de código. O malware persiste através de npm uninstall. Persiste através de apagar o node_modules. Persiste através de reinstalar versões limpas do pacote original. O pacote era o veículo de entrega. O runtime do agente é o alojamento.

Um paralelo útil existe no mundo Ruby. A equipe de segurança do RubyGems, apoiada em ferramentas que se originam do trabalho de Maciej Mensfeld em cadeia de suprimentos, roda análise estática e dinâmica em toda gem publicada no registro. O blog deles relata que esse pipeline captura uma estimativa de 70 a 80 por cento das gems maliciosas antes da divulgação pública. Note onde esse pipeline vive. Vive no registro. Não na máquina do desenvolvedor. Não no diretório de hooks do agente. A rota de ataque atual contorna o registro esperando o install acontecer e então gravando em um diretório que o registro nunca enxerga.

Por Que Isso É Mudança de Categoria

A defesa de cadeia de suprimentos de software, como praticada hoje, se apoia em três premissas. Assume que o registro é o ponto de estrangulamento, então escaneamos pacotes lá. Assume que o pacote é a unidade de comprometimento, então fixamos versões e rotacionamos quando uma versão ruim aparece. Assume que o passo de instalação é o limite, então remover a versão ruim devolve o sistema a um estado conhecido. A Mini Shai-Hulud quebra a terceira premissa em público.

A partir do momento em que um pacote malicioso consegue escrever em .claude/hooks.json ou .vscode/tasks.json, remover o pacote deixa de ser o procedimento de limpeza. Vira o início da perícia. Você passa a precisar enumerar toda superfície de execução controlada pelo agente na máquina, comparar com uma baseline limpa e provar que nenhum hook, nenhuma task, nenhum script de startup, nenhuma definição de servidor MCP foi adicionado ou modificado. A maioria dos times não consegue responder a essa pergunta para um único laptop, quanto mais para uma frota.

Este é o terceiro ato de uma história que vimos acompanhando. O primeiro ato foi a injeção de prompt como arma de cadeia de suprimentos, em que texto controlado pelo atacante levava um agente a vazar credenciais. O segundo ato foi o Clinejection, em que o próprio bot de triagem virou o veículo que empurrou um pacote envenenado para milhares de instalações. Este terceiro ato é persistência. O pacote é o mensageiro. O runtime do agente é o bunker.

Se você enxergou a natureza de duas frentes da crise de cadeia de suprimentos principalmente como uma questão de velocidade, esta atualização é sobre profundidade. Os atacantes não estão mais correndo pela porta da frente. Estão alugando o porão.

Seu Diretório de Configuração Virou um Plano de Controle

Trate o enquadramento operacionalmente. Um plano de controle é qualquer superfície que decide qual código roda, quando roda e com quais privilégios. Por essa definição, .claude/, .vscode/, .cursorrules, .mcp.json, .aider.conf.yml e qualquer outro diretório de configuração de agente já é um plano de controle há pelo menos um ano. Apenas não governamos esses diretórios como tal.

Compare a higiene em torno de três superfícies.

A tabela cron de um servidor. Qualquer pessoa que proponha adicionar um job cron passa por gestão de mudança. O job é revisado. É versionado como infraestrutura como código. É monitorado. Modificações disparam alertas.

Um arquivo de unidade systemd. Mesma resposta. Revisado, versionado, alertado, com dono na engenharia de plataforma.

Um arquivo hooks.json no diretório home do desenvolvedor. Ninguém revisa. Não está em nenhum inventário. Nenhuma ferramenta alerta quando o hash dele muda. Pode abrir shells, gerar tráfego de rede, modificar arquivos e ler segredos, e a stack padrão de endpoint nem pisca. Isso não é hipótese. É o alojamento duradouro que a Mini Shai-Hulud foi buscar, porque atacantes sempre procuram o que é menos observado.

O runtime do agente fica dentro da fronteira de confiança do desenvolvedor por padrão. Essa fronteira fazia sentido quando o único conteúdo dela era a configuração pessoal do editor. Deixa de fazer sentido quando a fronteira passa a conter um runtime que executa instruções arbitrárias a partir de texto que chega pela rede.

O Que Fazer Esta Semana

A remediação é nada glamourosa e bem concreta. Nenhum item exige fornecedor novo.

Audite todo diretório de hooks de agente no seu ambiente. Trate .claude/, .vscode/, .cursor/, .mcp.json, .aider*, ~/.config/claude* e caminhos equivalentes como privilegiados. Capture uma baseline limpa. Compare contra ela. Alerte em qualquer modificação não autorizada, da mesma forma que você alertaria em uma nova entrada cron em um host de produção.

Mova esses diretórios para versionamento, onde eles deveriam estar, e exija revisão em mudanças. Se um desenvolvedor não consegue articular por que um hook existe, o hook não deve existir.

Trate instalações de pacote como eventos de execução não confiável, não como eventos de configuração. Use instalação somente via lockfile (npm ci, pip install --require-hashes, bundle install --frozen) em toda máquina que toque credenciais de produção. Proíba scripts de post-install em runners de CI que carregam tokens de publicação. Onde não puder proibir, isole em sandbox.

Se qualquer máquina na sua organização instalou qualquer versão dos pacotes afetados, trate essa máquina como comprometida até prova em contrário. Os namespaces comprometidos incluem TanStack, Mistral AI, Guardrails AI, OpenSearch, UiPath, Bitwarden CLI e pacotes oficiais da SAP. Rotacione toda credencial que a máquina poderia alcançar: SSH, AWS, GitHub, npm, RubyGems, GitHub CLI, contas de serviço Kubernetes. Rotacione e verifique se as credenciais antigas morreram de verdade. O caso Clinejection mostrou quanto custa “rotacionou mas ainda funciona”.

Separe o escopo de leitura do agente do escopo de execução do agente. Um agente que precisa ler arquivos de código não precisa escrever hooks. Um agente que precisa escrever hooks não precisa de acesso à rede. A maioria dos times ainda não traçou essa linha.

Pressione seus registros a fazer o que o RubyGems faz. Análise estática e dinâmica em tempo de publicação não captura tudo, mas o blog do RubyGems relata uma taxa de captura de 70 a 80 por cento sobre gems maliciosas antes da divulgação pública. É o tipo de defesa upstream que compõe. O ataque atual ainda instalaria. O ataque atual não teria se espalhado nessa escala.

O runtime do agente agora faz parte do seu inventário de superfície de ataque. Se ele não está no inventário, o inventário está errado.

Fontes

BleepingComputer. “Shai Hulud attack ships signed malicious TanStack, Mistral npm packages.” Maio de 2026.
Snyk. “TanStack npm Packages Hit by Mini Shai-Hulud.” Maio de 2026.
StepSecurity. “Mini Shai-Hulud Is Back.” Maio de 2026.
BleepingComputer. “New npm supply-chain attack self-spreads to steal auth tokens.” Abril de 2026.
RubyGems Blog. “How RubyGems.org Protects Our Community’s Critical OSS Infrastructure.” Agosto de 2025.

A Victorino apoia líderes de governança, segurança e engenharia a reconstruir a contenção em torno das suas ferramentas de IA: contato@victorino.com.br | www.victorino.com.br