Your AI coding assistant may be executing commands you can't see. The TrapDoor campaign plants invisible instructions in .cursorrules and CLAUDE.md using zero-width Unicode characters. TanStack suffered a second attack that stole OIDC tokens to publish under a trusted identity. 33 npm packages impersonate corporate namespaces with a remote activation flag. Three vectors, same result: malicious code enters through npm install or AI assistant config.
TrapDoor: when the AI assistant becomes an execution vector
34 malicious packages. 384+ published versions. npm, PyPI and Crates.io. Active since May 19. TrapDoor's differentiator isn't the payload itself — it's the target. The campaign deliberately exploits AI coding assistant configuration files.
The payload plants two files in the project: .cursorrules with instructions for Cursor, and CLAUDE.md with instructions for Claude Code. The malicious instructions are hidden using zero-width Unicode characters: U+200B, U+200C, U+200D and U+FEFF. Invisible in any editor. Fully parsed and executed by the AI assistant.
The cycle is silent: developer opens the project. The assistant reads the config. Executes the hidden instructions. The human sees nothing. The second vector is even more scalable — malicious PRs against langchain, browser-use, llama_index, MetaGPT, OpenHands and langflow with commit messages like "docs: add .cursorrules". If merged, every clone would carry the invisible payload. All were rejected. But the vector is proven.
TanStack round 2: OIDC token theft under a trusted identity
TanStack suffered its second attack in weeks. 84 malicious versions across 42 @tanstack/* packages published in 6 minutes. CVE-2026-45321. CVSS 9.6. CISA KEV since May 27 with a remediation deadline of June 10.
The attack chain: pull_request_target Pwn Request + fork↔base cache poisoning + OIDC token extraction from the runner. The attacker used TanStack's OIDC trusted-publisher binding in GitHub Actions. With the token, they published under the organization's trusted identity. The same chain as the first attack — GitHub Actions trust boundary → OIDC token theft → publication under trusted identity — but now refined. Round one used cache poisoning. Round two stole the keys to the castle.
The lesson is direct: OIDC trusted-publisher binding is a delegation mechanism, not a security mechanism. The token attests that the publication came from the authorized workflow. It does not attest that the workflow wasn't compromised.
npm dependency confusion: namespace impersonation with remote activation
Microsoft discovered 33 npm packages under scopes that mimic corporate internal namespaces. Three operator aliases — mr.4nd3r50n, ce-rwb, t-in-one — all with Yandex emails. A single hardcoded X-Secret across all three aliases: one operator.
The technique is classic dependency confusion: public version with a higher number than the internal one. npm resolves by highest version. Your npm install pulls the attacker's package. The package.json files spoof GitHub Enterprise URLs, Jira and internal portals. Looks legitimate in code review.
The postinstall hook runs an obfuscated stager that fingerprints the environment: hostname, env vars, installed packages. The stager detects CI: if the CI variable exists, it aborts silently. Avoids alerts in monitored pipelines. RECON_ONLY = 1 for now — a server-side toggleable flag for full exploitation: exfiltration, credential theft, backdoor. C2 at oob.moika[.]tech. Impersonated scopes include @sber-ecom-core/sberpay-widget from Sberbank.
The convergence: AI coding assistants are the new supply chain target
30+ CVEs against agentic AI tooling in 60 days. The attack surface has been instrumented at machine speed. PraisonAI: scanners deployed in 3h44min after disclosure. LMDeploy: exploitation in 12h31min after advisory. The patch window for AI infrastructure has collapsed to hours. Pipelines with multi-day approval gates are incompatible with this reality.
TrapDoor proves that AI coding assistants aren't just tools — they're execution vectors. The developer trusts the assistant to suggest code. The assistant trusts .cursorrules and CLAUDE.md to contain legitimate instructions. This chain of delegated trust is exploitable the same way npm resolves by highest version: the system does what it was designed to do, but the input was forged.
npm install is not implicit trust — it's delegated trust. You trust the registry, the publisher, the namespace. Each one can be forged. The same applies to AI assistants: you trust the config file, the model, the context. Each one can be poisoned.
Practical defense: hardening for the new attack surface
At Tech86, we implement supply chain security in three layers: private registry with scope-to-registry mapping to eliminate dependency confusion, CI hardening with --ignore-scripts and integrity validation before any execution, and AI security-by-design with config file auditing and MCP server auto-execution restrictions.
If your team uses Cursor or Claude Code without hardening, you're exposed. If your npm install resolves packages that no one in your company published, your pipeline is exposed. If your CI doesn't block egress to known C2 domains, exfiltration may already be happening. The convergence between supply chain attacks and AI coding assistants isn't a future trend — it's the reality of May 2026.