THREAT BRIEFING · 13.10.2026 DEENFRES

Practice & Implementation

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

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

7 Min. read time

On May 22, 2026, at 20:20 UTC, a PyPI account uploaded package eth-security-auditor 0.1.0. By the time Socket flagged the wave as TrapDoor, 34 more packages had landed on npm, PyPI, and Crates.io. Median detection time per release: 5 minutes 27 seconds. Anyone who triggers a CI/CD run within that window has 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 tagged with the same marker P-2024-001.
  • AI coding configurations become the attack surface. TrapDoor embeds hidden instructions in cursorrules and CLAUDE.md files using zero-width Unicode, tricking Cursor or Claude into initiating false security scans.
  • CI/CD pipelines are the target, not the developer’s 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.

Related:NIS2 meets CLOUD Act  /  NIS2 compliance for SMEs

Why this wave doesn’t look like typosquatting

What is TrapDoor? TrapDoor is the name given by Socket’s security researchers to a coordinated supply chain attack in May 2026, where over 34 malicious packages were simultaneously injected into npm, PyPI, and Crates.io to steal wallet keystores, SSH keys, cloud credentials, and AI editor configurations. The cluster is internally marked as P-2024-001 and linked to the GitHub account ddjidd564 and the npm account asdxzxc.

Typical typosquatting campaigns rely on chance. Someone mistypes an npm install, and a similarly named package delivers a hidden payload. TrapDoor operates differently. The packages bear names like prompt-engineering-toolkit, solidity-deploy-guard, and defi-threat-scanner. They pose as tools for precisely the audience the attacker wants to target: developers in crypto, DeFi, Solana, and AI environments.

The second departure from a standard npm wave is its registry breadth. Three package managers at once, with the same threat actor fingerprint, the same GitHub account ddjidd564, and the same marker. This is 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 complete timestamps. The fastest detection occurred 58 seconds after publication. If you trigger an npm install or pip install in an uncontrolled CI runner during one of these windows, you’re out of luck.

How the attack branches per registry

1 149
Lines of code in the npm loader trap-core.js, TrapDoor’s central credential harvester and propagation module.
Source: Socket Threat Research, May 2026

The packages share a common target architecture, but use different triggers per ecosystem. In npm the payload rides on postinstall, in Rust the code is pulled in via build.rs, and in Python it fires at import time. That separation matters because it hits exactly the three points where build systems automatically execute third-party code without the user starting it explicitly.

What gets harvested: 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-side view of a typical developer workstation profile, including every cloud persistence layer.

Where TrapDoor truly breaks new ground: AI coding configurations

The attack has a vector that ordinary supply-chain malware does not. TrapDoor manipulates the configuration files of Cursor and Claude Code directly. Concretely: cursorrules and project-level CLAUDE.md files are laced with zero-width Unicode characters that stay invisible to a reviewer in the editor, yet are interpreted by the AI assistant as prompt content.

The result is a cloaked instruction that pushes the assistant to run its own security scans or diagnostic routines that in truth export data from the project context. Anyone working with an AI-assisted editor who does not version-control repository configuration files has a path that conventional endpoint detection never sees. This is the first documented supply-chain wave that uses AI agents as a co-execution layer.

Teams that take this seriously treat cursorrules and project-level CLAUDE.md files like build scripts from today on. Diff reviews per commit, encoding checks for Unicode anomalies, no merge without a second pair of eyes.

CI/CD mitigations: what holds up, what breaks

What breaks

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

What holds up

  • npm ci –ignore-scripts, pip –no-build-isolation under control
  • SBOM generation per build, signed
  • Allowlist instead of denylist on registries
  • Short-lived build credentials via OIDC, no static token
  • Reproducible builds with hash comparison against the last green run

Egress filters are the underestimated lever. Even if a malicious postinstall runs during the build, without an outbound path into third-party networks it has nowhere to send the credentials. Anyone still running a GitHub Actions runner or GitLab executor in a flat VPC with no egress rules will not get far with npm audit alone.

The second quiet winner is OIDC. A build that only fetches its short-lived AWS token at execution time from the CI OIDC issuer has no long-lived cloud key for TrapDoor to steal. That shrinks the attack window from a permanent secret to the duration of the build.

NIS2 and DORA: Where Compliance Already Demands Documentation

Article 21 of NIS2 lists supply chain security as one of the minimum risk management measures that essential and important providers must implement. Specifically: documented assessments of direct suppliers and service providers, including software dependencies. An npm dependency in a production build is legally no different from an externally sourced control module.

For the financial sector, DORA requires under Articles 28 and 30 a complete inventory of ICT third-party providers plus documented concentration risks. Any bank or financial services firm using an npm repository with hundreds of transitive dependencies – without listing them in the ICT third-party registry – will face a gaping vulnerability in the next audit.

Neither regulation demands complete protection against zero-day packages, but both require a traceable process. This is precisely where NIS2 and DORA give security leaders leverage: TrapDoor becomes a concrete test case against which to measure their own supply chain processes.

30-Day Action Plan
Days 1–3
Activate egress filters on CI/CD runners, restrict outbound targets to a registry allowlist. Immediate impact, low complexity.
Days 4–10
Switch npm ci and pip to –ignore-scripts or controlled build isolation. Embed 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 cursorrules and PROJECT-CLAUDE.md across all repos, add encoding diffs in pre-commit hooks. Update NIS2 and DORA documentation per repository.

Four weeks is a realistic window if the security team writes the tickets and the platform team executes. The sequence is deliberately asymmetrical: egress controls first, then SBOMs, followed by OIDC, and finally AI configuration. Those who follow this order close the pathways TrapDoor exploits to exfiltrate data before addressing structural issues.

Unresolved Questions

Socket describes an attacker with deep knowledge of modern build systems and AI editors. The next wave likely won’t target pep or npm packages but Helm charts, container base images, or even GitHub Actions workflows. Treating TrapDoor as just an npm incident means missing the next attack vector.

From today, it pays to treat your CI/CD platform like a live production system – not an auxiliary tool. That means hardening baselines, monitoring, incident playbooks, and clearly documented responsibilities.

Frequently Asked Questions

Each question is locked. Tap to unlock the answer.

Which packages are currently flagged as malicious?

Socket documents 34 packages and over 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 available in Socket’s original blog post. Your own build inventory should be cross-checked against this list.

Am I at risk if I run npm install locally?

The risk is high locally because postinstall scripts execute without restrictions. In CI/CD pipelines, the risk is even greater since build runners often have access to long-lived cloud credentials and SSH keys. If you operate in either environment without egress filtering, without npm ci --ignore-scripts, or without SBOM comparison, you should review the logs from the last 72 hours today.

What specific steps should I take with Cursor and Claude Code?

Configuration files like cursorrules and PROJECT-CLAUDE.md should be version-controlled in every repository. A pre-commit hook that scans for zero-width Unicode characters can prevent the most obvious attack vector. Additionally, every onboarding document should address which external sources an AI editor accesses at runtime.

How does TrapDoor fit into NIS2 risk assessments?

Article 21 of NIS2 requires a documented assessment of supply chain risks. An open-source dependency with an unclear maintainer legally qualifies as a supplier. If you lack a process to evaluate packages before adoption and monitor them afterward, you’ll have a clear audit finding.

Is switching to private registry mirrors worth it?

For teams with high build frequency and production-grade codebases, yes. An internal mirror with an allowlist and hash verification shifts the trust model away from public registries. The effort is significant, but the protection is verifiable and audit-ready – exactly what NIS2 and DORA demand.

Editors’ Reading Picks

Reading TipZero Trust at energy utilities: What NIS2 audits are uncovering nowReading TipNIS2 meets the CLOUD Act: Who is liable for the third-country gapReading TipAI-driven threat analysis: What German SOCs need now

**Risks**
– URLs and image paths stay DE-slugged; EN page may look mixed if targets are not localized.
– Label “Reading Tip” vs. “Editor’s Pick”: house style not specified.
– “Energieversorger” rendered as “energy utilities” (sector, not one company).

**Open questions**
– Preferred label: “Reading Tip”, “Editor’s Pick”, or “Recommended”?
– Keep “German SOCs” explicit, or broaden to “SOCs in Germany”?

More from the MBF Media Network

cloudmagazinPlatform Engineering for Compliance: IDPs Enforce NIS2 and DORAMyBusinessFutureProcess Optimization Fails at Handoffs, Not the ToolsDigital ChiefsSaaS Renewals: Where Silent Price Hikes Hide

Image source: AI-generated (July 2026)

Translated from the German original using artificial intelligence. The German version is authoritative.

Further reading

A magazine by Evernine Media GmbH