TrapDoor supply chain malware expands secret theft across registries

At a glance

What this is: TrapDoor is a coordinated supply chain malware campaign using malicious packages across npm, PyPI, and Crates.io to steal secrets from developer and CI environments.

Why it matters: It matters because identity and secrets controls must now cover developer workstations, build pipelines, and AI coding tools where standing credentials, tokens, and keys are harvested.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Corgea's analysis of the TrapDoor supply chain malware campaign

Context

TrapDoor is best understood as supply chain malware aimed at identity material rather than only source code. The packages abuse normal developer trust paths in npm, PyPI, and Crates.io, then search for the credentials that give attackers persistence, cloud access, and publishing rights. In practice, this is a secrets governance problem as much as a malware problem, because the exposed material includes SSH keys, GitHub tokens, cloud credentials, and wallet seed data.

The most important shift is that the campaign reaches across install-time, import-time, build-time, and AI assistant surfaces. That means traditional package review is necessary but no longer sufficient, especially where AI coding tools read project instructions such as .cursorrules or CLAUDE.md. For teams managing NHI and secrets estates, the starting position exposed here is increasingly common, not exceptional.

Key questions

Q: What breaks when malicious packages reach build pipelines unchecked?

A: Unchecked packages can execute before conventional controls inspect them, which means secrets, environment variables, and internal tokens can be exposed during install or runtime. Once those credentials are captured, attackers may pivot into CI, cloud services, or downstream tools. The failure is not just malware execution, but trust in package provenance without continuous validation.

Q: Why do developer workstations increase supply-chain risk so quickly?

A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place. When an attacker compromises that endpoint, the impact is not limited to the laptop itself. The stolen identity material can be reused to modify code, access services, and push compromise downstream into customers and production pipelines.

Q: How do security teams know if a package compromise is actually contained?

A: They should confirm three things: the bad version no longer appears in lockfiles, SBOM records no longer resolve to it, and running services no longer load it. If any one of those still matches, the compromise is not contained. Re-scan after remediation and require evidence from both code and runtime.

Q: Who is accountable when a malicious dependency reaches a developer workstation?

A: Accountability usually spans application security, endpoint security, and the software delivery team because the failure sits at the intersection of dependency governance and runtime control. Frameworks like NIST SP 800-53 Rev 5 Security and Privacy Controls support shared responsibility across access, monitoring, and configuration management rather than leaving the issue to one team.

Technical breakdown

Why multi-registry package malware bypasses normal trust assumptions

Cross-registry malware works because each ecosystem has a different execution trigger, but the attacker only needs one trusted path into a developer machine or CI runner. npm can execute lifecycle scripts, PyPI can load code at import time, and Cargo can run build.rs during compilation. That creates a fragmented security boundary where package metadata looks harmless while the runtime payload is already active. In TrapDoor, the registries are just delivery systems for a broader credential-harvesting operation that targets local secrets stores and developer context.

Practical implication: inspect packages for execution behaviour, not just names and versions, before they reach developer or CI environments.

How malicious packages turn developer identity material into persistence

Once a package lands, the malware looks for high-value identity artefacts such as SSH private keys, GitHub tokens, npm tokens, cloud credentials, browser stores, and .env files. It then validates some of those credentials against live services so it can separate usable secrets from stale ones. That validation step matters because it accelerates follow-on abuse, including source tampering, package publication, and cloud access. The real objective is not a one-time steal but reusable access that can survive environment rebuilds unless the credentials are revoked.

Practical implication: treat exposed developer secrets as active identities and revoke them, not merely as leaked files to delete.

Why AI coding environments create a new secret exfiltration surface

AI-assisted development extends the attack surface because tools can consume repository-level instructions and local context files as part of normal workflow. TrapDoor targets .cursorrules and CLAUDE.md specifically because they can influence future coding sessions, environment validation, and discovery prompts. That makes the AI layer a governance problem, not just a productivity layer, because instructions can be abused to normalise secret collection under the guise of helper behaviour. Where AI tools can read local project state, they can also be manipulated into participating in persistence and exfiltration.

Practical implication: govern AI coding instructions as sensitive runtime input and review them with the same care as build scripts.

Threat narrative

Attacker objective: The attacker wants durable access to developer identity material that can be reused for source theft, cloud intrusion, and supply chain abuse.

1. Entry occurs through malicious npm, PyPI, or Crates.io packages that look like developer utilities and are installed into workstations, CI runners, or build environments.
2. Credential access follows when the payload searches local files, browser stores, wallet material, SSH keys, GitHub tokens, cloud credentials, and project instruction files.
3. Escalation occurs when stolen credentials are validated, reused, or embedded into persistence paths such as shell profiles, hooks, cron jobs, or AI assistant context.
4. Impact is credential reuse for source compromise, package publication abuse, cloud access, and broader lateral movement across developer and build environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret governance has become supply chain defence. TrapDoor shows that package malware is now optimised for identity material, not just code execution. When malicious packages hunt for SSH keys, cloud tokens, wallet data, and registry credentials, the control problem shifts from malware detection to secret lifecycle management. Practitioners should treat developer credentials as high-risk NHI assets that require the same lifecycle rigor as production service accounts.

AI coding environments introduce a governance gap we should name as instruction persistence risk. Files such as .cursorrules and CLAUDE.md can be abused as durable inputs to future sessions, which makes the AI layer an identity and trust surface in its own right. This is where OWASP-NHI and agentic AI governance start to converge with software supply chain controls. The practical conclusion is that AI assistant context must be reviewed, monitored, and reset as part of security operations.

Registry trust is no longer a binary allow or block decision. The campaign used npm, PyPI, and Crates.io with execution paths tailored to each ecosystem, which means static allowlists alone will not solve the problem. Teams need policy that distinguishes package provenance from runtime behaviour and validates what code actually executes during install, import, or build. In framework terms, this aligns with NIST CSF protections around access and configuration management, plus OWASP-NHI controls for secret exposure.

Validated credentials are the real blast-radius multiplier. Malware that checks whether AWS or GitHub tokens work can prioritise the most useful identities immediately and discard dead material. That shortens attacker dwell time and increases the chance that stolen secrets become usable access before defenders notice. The practitioner takeaway is clear: revocation and token scoping matter more than post-event hunting alone.

Developer machines are now part of the identity perimeter. This campaign targets the assets that sit closest to code creation and release rights, which means workstation hygiene, CI runner hardening, and registry token governance are part of the same control plane. The broader pattern is not accidental opportunism, it is identity-focused supply chain targeting. Security teams should design accordingly.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Also from our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means leaked developer credentials remain a live attack path long after discovery.
• Forward view: Read the Guide to the Secret Sprawl Challenge for the remediation patterns that reduce exposure windows and improve revocation discipline.

What this signals

Secret sprawl is now a software supply chain risk, not a hygiene issue. When malicious packages target the credentials that developers and CI systems already trust, the control question becomes how fast the organisation can detect and revoke exposed identities. The practical benchmark is whether secret inventory, rotation, and publishing rights are governed as one lifecycle across build, runtime, and AI-assisted development.

AI tooling expands the blast radius of local secret handling. Repository instruction files and coding assistants can become persistence channels if they are not treated as governed inputs. Teams that already map the identity layer around workloads should extend that discipline to developer context files and agent prompts, then align the control set with the OWASP Non-Human Identity Top 10 where machine-accessed secrets are involved.

For practitioners

• Map developer secrets as NHI assets Inventory SSH keys, GitHub tokens, cloud keys, package registry credentials, and wallet material on developer laptops and CI runners. Assign owners, rotate schedules, and revocation paths for each identity type so the response is not ad hoc when a package compromise occurs.
• Block and hunt on package execution behaviour Detect install-time scripts, Python import loaders, and Cargo build.rs execution in dependency review, then flag packages that fetch remote JavaScript or create new persistence files. Correlate this with registry proxy logs and package cache inspection during incident response.
• Review AI assistant context as sensitive input Treat .cursorrules, CLAUDE.md, Git hooks, shell profiles, and local agent instructions as governed files. Rebuild them from known-good baselines after any suspicious package install and inspect whether they reference security scans or environment-audit prompts.
• Revoke and reissue exposed credentials immediately Assume compromise on machines that installed the listed packages, then rotate tokens, SSH keys, npm and PyPI publishing credentials, cloud access keys, and any wallet seed material reachable from the host. Validate that revoked identities cannot still authenticate through cached sessions or delegated tooling.
• Segment CI runners from publishing rights Separate build execution from package publication and production access, then remove long-lived registry tokens from runners wherever possible. Use short-lived credentials and isolated service identities so a malicious build does not inherit publish or deploy capability.

Key takeaways

• TrapDoor shows that malicious packages increasingly target identity material, not just source code or binaries.
• The strongest evidence of scale is the volume of exposed secrets and the persistence of leaked credentials after discovery.
• Teams need lifecycle control over developer secrets, build identities, and AI coding context before package compromise becomes account compromise.

Key terms

• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.
• Developer Secret: A developer secret is a credential used to access code, services, or infrastructure, such as an API key, SSH key, token, or certificate. In practice, it becomes an identity artifact when it can authorize action, not just authenticate a person. Its risk lies in spread, reuse, and weak revocation.
• Workflow Trigger: A workflow trigger is the event or condition that starts or advances an automated process. In digital agreements, it matters because the trigger can function like a policy decision point, determining whether a signing action occurs and which downstream systems receive the document or status update.
• Persistence artifact: A persistence artifact is any file, hook, service, or configuration that lets malware survive after the initial execution window ends. In build and developer environments, these artifacts often hide in editor settings, system services, or startup hooks and can reactivate the compromise later.

What's in the full analysis

Corgea's full report covers the operational detail this post intentionally leaves for the source:

• Package-by-package indicators for the 34 malicious names across npm, PyPI, and Crates.io
• Registry-specific execution behaviour, including install-time, import-time, and build-time triggers
• Filesystem and network indicators such as trap-core.js, ddjidd564.github.io, and suspicious AI context files
• Recommended response steps for rebuild, revocation, and hunting across developer estates

👉 Corgea's full post covers the package list, execution paths, and remediation details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build lifecycle controls that reduce exposure across developer, build, and runtime environments.