Seu AI coding assistant pode estar executando comandos que você não consegue ver. A campanha TrapDoor planta instruções invisíveis em .cursorrules e CLAUDE.md usando caracteres Unicode de largura zero. O TanStack sofreu um segundo ataque que roubou tokens OIDC para publicar sob identidade confiável. 33 pacotes npm impersonam namespaces corporativos com flag de ativação remota. Três vetores, mesmo resultado: código malicioso entra pelo npm install ou pela configuração do AI assistant.
TrapDoor: quando o assistente de IA vira vetor de execução
34 pacotes maliciosos. 384+ versões publicadas. npm, PyPI e Crates.io. Ativa desde 19 de maio. O diferencial do TrapDoor não é o payload em si — é o alvo. A campanha explora deliberadamente arquivos de configuração de AI coding assistants.
O payload planta dois arquivos no projeto: .cursorrules com instruções para o Cursor, e CLAUDE.md com instruções para o Claude Code. As instruções maliciosas são escondidas com zero-width Unicode characters: U+200B, U+200C, U+200D e U+FEFF. Invisíveis em qualquer editor. Totalmente parseadas e executadas pelo AI assistant.
O ciclo é silencioso: desenvolvedor abre o projeto. O assistant lê a configuração. Executa as instruções ocultas. O humano não vê nada. O segundo vetor é ainda mais escalável — PRs maliciosos contra langchain, browser-use, llama_index, MetaGPT, OpenHands e langflow com commit messages como "docs: add .cursorrules". Se mergeados, todo clone teria o payload invisível. Todos foram rejeitados. Mas o vetor está provado.
TanStack round 2: OIDC token theft sob identidade confiável
O TanStack sofreu o segundo ataque em semanas. 84 versões maliciosas em 42 pacotes @tanstack/* publicadas em 6 minutos. CVE-2026-45321. CVSS 9.6. CISA KEV desde 27 de maio com prazo de remediação em 10 de junho.
A cadeia de ataque: pull_request_target com Pwn Request + cache poisoning fork↔base + extração do token OIDC do runner. O atacante usou o OIDC trusted-publisher binding do TanStack no GitHub Actions. Com o token, publicou sob a identidade confiável da organização. A mesma cadeia do primeiro ataque — GitHub Actions trust boundary → OIDC token theft → publicação sob identidade confiável — mas agora com refinamento. O primeiro round usou cache poisoning. O segundo roubou a chave do castelo.
A lição é direta: OIDC trusted-publisher binding é um mecanismo de delegação, não de segurança. O token atesta que a publicação veio do workflow autorizado. Não atesta que o workflow não foi comprometido.
npm dependency confusion: namespace impersonation com ativação remota
A Microsoft descobriu 33 pacotes npm sob scopes que imitam namespaces internos corporativos. Três aliases de operador — mr.4nd3r50n, ce-rwb, t-in-one — todos com emails Yandex. Um mesmo X-Secret hardcoded nos três aliases: operador único.
A técnica é dependency confusion clássica: versão pública com número mais alto que a interna. O npm resolve pela versão mais alta. Seu npm install baixa o pacote do atacante. Os package.json spoofam URLs de GitHub Enterprise, Jira e portais internos. Parece legítimo na code review.
O postinstall hook executa um stager obfuscado que fingerprinta o ambiente: hostname, env vars, pacotes instalados. O stager detecta CI: se a variável CI existe, aborta silenciosamente. Evita alertas em pipelines monitorados. RECON_ONLY = 1 por agora — flag toggleável server-side para full exploitation: exfiltração, credential theft, backdoor. C2 em oob.moika[.]tech. Scopes impersonados incluem @sber-ecom-core/sberpay-widget do Sberbank.
A convergência: AI coding assistants são o novo alvo de supply chain
30+ CVEs contra agentic AI tooling em 60 dias. A superfície de ataque foi instrumentada a machine speed. PraisonAI: scanners em 3h44min após disclosure. LMDeploy: exploração em 12h31min após advisory. A janela de patch para AI infra colapsou para horas. Pipelines com approval gates de dias são incompatíveis com essa realidade.
O TrapDoor prova que AI coding assistants não são apenas ferramentas — são vetores de execução. O desenvolvedor confia que o assistant vai sugerir código. O assistant confia que .cursorrules e CLAUDE.md contêm instruções legítimas. Essa cadeia de confiança delegada é explorável da mesma forma que o npm resolve pela versão mais alta: o sistema faz o que foi projetado para fazer, mas o input foi forjado.
npm install não é operação de confiança implícita. É confiança delegada. Você confia no registry, no publisher, no namespace. Cada um pode ser forjado. O mesmo vale para AI assistants: você confia no arquivo de configuração, no modelo, no contexto. Cada um pode ser envenenado.
Defesa prática: hardening para a nova superfície
Na Tech86, implementamos supply chain security em três camadas: registry privado com scope-to-registry mapping para eliminar dependency confusion, CI hardening com --ignore-scripts e validação de integridade antes de qualquer execução, e AI security-by-design com auditoria de arquivos de configuração e restrição de MCP server auto-execução.
Se seu time usa Cursor ou Claude Code sem hardening, está exposto. Se seu npm install resolve pacotes que ninguém da empresa publicou, o pipeline está exposto. Se seu CI não bloqueia egress para domínios de C2 conhecidos, a exfiltração já pode estar acontecendo. A convergência entre supply chain attacks e AI coding assistants não é uma tendência futura — é a realidade de maio de 2026.