TrapDoor: Coordinated Supply-Chain Attack on npm, PyPI and Crates – What CI/CD Teams Must Check Now

By Alec Chizhik · May 25, 2026 · 9 min read

On 22 May 2026 at 20:20 UTC, a PyPI account uploaded the package eth-security-auditor 0.1.0. By the time Socket classified the wave as TrapDoor, 34 further packages had already landed in npm, PyPI and Crates.io. Median detection time per release: 5 minutes 27 seconds. Anyone who starts a CI/CD run within that window is facing a problem no vendor demo can explain.

Key takeaways

Coordinated multi-registry attack. Socket documents 34 packages across more than 384 versions, simultaneously on npm, PyPI and Crates.io via the account asdxzxc, all bearing the same marker P-2024-001.
AI-coding setups become the attack surface. TrapDoor hides zero-width Unicode instructions in cursorrules and CLAUDE.md files so that Cursor or Claude Code kick off bogus security scans.
CI/CD pipelines are the target, not the developer laptop. If you haven’t disabled postinstall, build.rs and Python import hooks in your build, you have an unpatched supply-chain path that must be documented under NIS2 Article 21 and DORA ICT risk management.

Why this wave doesn’t look like typosquatting

What is TrapDoor? TrapDoor is the name Socket’s security researchers gave to a coordinated supply-chain attack in May 2026 in which more than 34 malicious packages were slipped in parallel across npm, PyPI and Crates.io to steal wallet keystores, SSH keys, cloud credentials and AI editor configurations. The cluster carries the internal marker P-2024-001 and is linked to the GitHub account ddjidd564 and the npm account asdxzxc.

Typical typosquat campaigns rely on chance: someone mistypes during npm install, a similarly named package delivers a hidden payload. TrapDoor works differently. The packages are named prompt-engineering-toolkit, solidity-deploy-guard and defi-threat-scanner-posing as tools for the very audience the attacker wants to harvest: developers in crypto, DeFi, Solana and AI environments.

The second departure from a normal npm wave is the breadth of registries. Three package managers simultaneously, sharing the same threat-actor fingerprint, the same GitHub account ddjidd564 and the same marker. That’s an operational setup, not a script-kiddie run.

And it’s fast. Socket reports a median detection time of 5 minutes 27 seconds across 381 release records with full timestamps. The fastest find came 58 seconds after publication. Anyone who triggers an npm install or pip install in an uncontrolled CI runner within that window is out of luck.

How the attack branches out per registry

1 149

lines of code in the npm loader trap-core.js, the central credential harvester and propagation module of TrapDoor.

Source: Socket Threat Research, May 2026

The packages share a target architecture but use different triggers per ecosystem. In npm the payload is hooked to postinstall, in Rust the code is pulled via build.rs, and in Python it fires at import time. This separation matters because it precisely targets the three points where build systems automatically execute foreign code without the user ever explicitly running it.

Harvested are SSH keys, AWS credentials, GitHub tokens, browser login databases, wallet keystores for Sui, Solana and Aptos, environment variables, API keys and local dev configurations. That is the complete supplier view of an average developer workstation profile, including all cloud persistences.

Where TrapDoor truly breaks new ground: AI coding configurations

This attack vector is one supply-chain malware usually does not possess. TrapDoor directly manipulates the configuration files of Cursor and Claude Code. Specifically, cursorrules and project-CLAUDE.md are injected with zero-width Unicode characters that remain invisible to human reviewers in the editor but are interpreted by the AI assistant as prompts.

The upshot is a cloaked instruction that nudges the assistant into running its own security scans or diagnostics-routines that in reality exfiltrate data from the project context. Anyone using an AI-powered editor who does not rigorously version-control repository configuration files now has a path invisible to conventional endpoint detection. This is the first documented supply-chain wave that weaponizes AI agents as an execution layer.

Teams that take this seriously will treat cursorrules and project-CLAUDE.md like build scripts from today on: diff reviews per commit, encoding checks for Unicode anomalies, no merges without two sets of eyes.

CI/CD mitigations: what works and what breaks

What breaks

Build runners with internet access and no egress filtering
npm install without –ignore-scripts in CI
Lock files restored without hash verification
Shared service accounts across multiple projects
cursorrules and project-CLAUDE.md untracked in the workspace

What works

npm ci –ignore-scripts, pip –no-build-isolation enforced
SBOM generation per build, signed
Allowlists instead of denylists on registries
Ephemeral build credentials via OIDC, no static tokens
Reproducible builds with hash comparison against last green run

Egress filters are the oft-overlooked lever. Even if a malicious postinstall runs during the build, without an outbound connection to external networks there is no destination for the harvested credentials. Teams still running GitHub Actions runners or GitLab executors in a flat VPC without egress rules will not get far with npm audit.

The second silent winner is OIDC. A build that fetches its ephemeral AWS token only at execution time from the CI OIDC issuer leaves no long-lived cloud key for TrapDoor to steal-shifting the attack window from a permanent secret to the duration of the build itself.

NIS2 and DORA: Where the topic is already subject to documentation requirements today

NIS2 Article 21 lists supply-chain security as one of the minimum risk-management measures that an essential or important provider must implement. Specifically: documented assessment of direct suppliers and service providers, including software dependencies. A single npm dependency in a production build is legally no less a supplier than an externally procured control module.

DORA requires the financial sector, in Articles 28 and 30, to maintain a complete inventory of ICT third parties plus documented concentration risks. If a bank or financial-services provider runs an npm repository with hundreds of transitive dependencies without listing them in the ICT third-party registry, the next audit will expose a gaping vulnerability.

Neither regulation demands absolute protection against zero-day packages, but both require a traceable process. This is precisely where the NIS2 and DORA lever comes into play for security leaders: TrapDoor becomes the concrete case study against which their own supply-chain processes can be measured.

30-day action plan

Days 1–3

Enable egress filters on CI/CD runners and restrict outgoing targets to a registry allowlist. Immediate impact, low complexity.

Days 4–10

Switch npm ci and pip to –ignore-scripts or controlled build isolation. Anchor SBOM generation per build.

Days 11–20

Roll out OIDC federation for cloud credentials in CI, deprecate and rotate long-lived service tokens.

Days 21–30

Version control cursorrules and project CLAUDE.md everywhere, add encoding-diff pre-commit hook. Bring NIS2 and DORA documentation in line per repository.

Four weeks is a realistic window if the security team writes the tickets and the platform team builds the pipeline. The sequence is deliberately asymmetrical: egress before SBOM before OIDC before AI configuration. Those who follow this order first close the channels through which TrapDoor exfiltrates data and only then address structural issues.

What remains unresolved

Socket describes an attacker who knows a great deal about modern build systems and AI editors. The next wave will likely not hide in pep or npm packages, but in Helm charts, container base images, or directly in GitHub-Action workflows. Dismissing TrapDoor as merely an npm incident means planning for the next vector.

From today on, treat your CI/CD platform like a live production system-not a utility. That means: hardening baseline, monitoring, incident playbook, documented responsibilities.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

Which packages are currently flagged as malicious?

Socket lists 34 packages and more than 384 versions across npm, PyPI, and Crates.io. Examples from the Socket report include prompt-engineering-toolkit, solidity-deploy-guard, and defi-threat-scanner. A complete, continuously updated list is maintained in Socket’s original blog post. Mirror your own build inventories against this list.

Am I affected if I run npm install locally?

Locally the risk is high because postinstall scripts fire without further restrictions. In CI/CD the risk is even higher because build runners often have access to long-lived cloud credentials and SSH keys. If you operate in both environments without egress filters, without npm ci –ignore-scripts, and without SBOM comparison, review the logs from the last 72 hours today.

What exactly should be done with Cursor and Claude Code?

Configuration files such as cursorrules and project-CLAUDE.md should be versioned in every repository. A pre-commit hook that checks for zero-width Unicode characters prevents the most obvious attack variant. Additionally, the question of which external sources an AI editor reads at runtime should be included in every onboarding document.

How does TrapDoor fit into the NIS2 risk assessment?

Article 21 NIS2 requires a documented assessment of supply-chain risks. An open-source dependency with an unclear maintainer is legally a supplier. Teams without a process to evaluate packages before adoption and monitor them afterward face clear audit findings.

Is switching to private registry mirrors worth it?

For teams with high build frequency and production-like codebases, yes. An internal mirror with an allowlist and hash verification shifts the trust model away from the public registry. The effort is real, but the protection is verifiable and auditable-something explicitly valued under NIS2 and DORA.

Editor’s Reading Tips

Editor’s Picks

Editor’s PickZero Trust at the energy supplier: What the NIS2 audits are now revealing Editor’s PickNIS2 meets CLOUD Act: Who is liable for the third-country gap?Editor’s PickAI-Driven Threat Analysis: What German Security Operations Centers Need Now

More from the MBF Media Network

cloudmagazinPlatform Engineering for Compliance: IDPs Enforce NIS2 and DORA MyBusinessFutureProcess optimization fails at the handover, not at the tool Digital ChiefsSaaS Renewals: Where the Silent Price Increase Lies