TrapDoor Hit npm, PyPI, and Crates at Once. Provenance Is the Signal That Catches It.

June 21, 2026 · 6 min read · HVTracker Research

In May 2026, a campaign researchers named TrapDoor became the first confirmed supply-chain attack to weaponize npm, PyPI, and Crates.io simultaneously — more than 34 packages across 384 versions, each with an execution path tailored to its registry: postinstall hooks on npm, import-time remote fetch on PyPI, malicious build.rs scripts on Crates.io.

The detail that should worry anyone using AI coding tools: some TrapDoor packages shipped poisoned CLAUDE.md and .cursorrules files containing zero-width Unicode instructions. Open the project in an AI assistant, and it silently reads those files and runs a "security scan" that exfiltrates your local secrets. Weeks earlier, a separate mass campaign pushed hundreds of malicious versions of legitimate packages including TanStack and Mistral AI, harvesting GitHub tokens, CI/CD secrets, and cloud credentials.

These attacks share one mechanic: the package you download no longer matches the source you reviewed. The repo on GitHub looks clean. The artifact on the registry is not. And from the outside, you have no way to tell — unless the project publishes build provenance.

What provenance actually does

Build provenance is a cryptographic attestation — via SLSA on npm or PEP 740 on PyPI — that binds a published package to the exact commit, build system, and CI workflow that produced it. It doesn't stop an attacker from trying. It makes a swapped or tampered artifact fail verification, because the malicious build can't reproduce a signed attestation from the real project's pipeline.

Provenance is detection, not prevention. It won't stop a maintainer account from being phished. What it gives you is the ability to check — automatically, at install time — that the bytes you're running came from the workflow you trust. Without it, "the GitHub source is clean" and "the package is clean" are two different claims, and you can only verify one.

How ready are open-source AI agents? Not very.

We track build and package provenance across 272 open-source AI agents. Here's where the ecosystem stands going into the second half of 2026:

83%

ship no build provenance attestation

72%

of the 170 published to a registry have no package provenance

20%

have zero signed commits

In other words, for roughly four out of five AI agents, a TrapDoor-style registry injection would be undetectable by the one mechanism designed to detect it. These are the same tools being wired into CI pipelines and handed cloud credentials — the exact blast radius TrapDoor was built to reach.

The agents that would have caught it

A minority do publish provenance, and they are disproportionately the projects at the top of our trust rankings. Provenance rarely travels alone: teams that attest builds also tend to sign commits and run OSSF Scorecard.

Agent	Package provenance	Signed commits	HVTrust Rank
LangGraph	Verified	Yes	#2
Codex	Verified	Yes	#4
Vercel AI SDK	Verified	Yes	#5
PydanticAI	Verified	Yes	#8

What to do about it

If you maintain an agent: turn on provenance. On npm it's a single --provenance flag in a GitHub Actions release. On PyPI, trusted publishing with PEP 740 attestations is built in. It is one of the highest-leverage, lowest-effort security upgrades available to you right now.

If you depend on one: check whether the package you install carries an attestation before you wire it into anything with secrets. You can look up any agent's provenance, signed-commit ratio, and OSSF Scorecard on its HVTracker profile.

See which agents publish provenance

HVTracker grades 270+ open-source AI agents on build provenance, package provenance, signed commits, and OSSF Scorecard — refreshed throughout the day.

Browse the trust registry

Provenance and signing data from HVTracker signals as of June 21, 2026. Attack details summarized from public reporting on the TrapDoor campaign (The Hacker News) and the npm/PyPI TanStack & Mistral campaign (SafeDep). Full methodology. Related: the MCP servers you can't verify.