A coordinated supply chain attack spanning three major package registries is distributing credential-stealing malware to developers worldwide. The campaign, tracked as TrapDoor, has published more than 34 malicious packages across over 384 versions on npm, PyPI, and Crates.io since May 22, 2026, according to a report by The Hacker News.
Threat actors are releasing packages in calculated waves designed to saturate repository moderation queues and bypass automated security scanners. By flooding registries with hundreds of version releases in rapid succession, the attackers exploit the implicit trust development teams place in published packages — a structural weakness inherent to decentralized open-source ecosystems.
Technical Execution
The malware embedded in TrapDoor packages functions as a credential harvester, extracting authentication tokens, API keys, and developer secrets from compromised environments. Once installed as a dependency, the payload executes during standard build or runtime processes, silently transmitting stolen credentials to attacker-controlled infrastructure.
The campaign relies on typosquatting — registering package names that closely resemble legitimate, widely-used libraries — to deceive developers into pulling compromised code into their projects. Combined with the wave-based publishing strategy, this creates a narrow detection window: by the time security teams or registry moderators identify and remove malicious packages, affected organizations may already have exposed credentials.
Risk for Enterprise Development Teams
For IT teams managing large-scale software portfolios, the TrapDoor campaign exposes a critical vulnerability in modern development workflows. Organizations that depend heavily on third-party libraries without rigorous verification face elevated risk, particularly where automated CI/CD pipelines resolve dependencies without cryptographic provenance checks.
The attack reveals a systemic imbalance: package registries prioritize rapid publication and developer velocity, while security vetting mechanisms lag behind. This gap allows malicious actors to inject compromised code into production environments before detection occurs.
Recommended Audit Checklist
Security teams should take immediate action to assess exposure and strengthen dependency management practices:
- Run dependency audits using software composition analysis tools such as Snyk, Dependabot, or OWASP Dependency-Check to identify any packages matching published TrapDoor indicators of compromise.
- Remove or quarantine any unverified or suspicious packages discovered during the audit until their provenance can be confirmed.
- Enforce package allowlists that restrict installations to pre-approved, verified libraries with known cryptographic signatures.
- Integrate automated scanning into CI/CD pipelines to block unverified packages before they reach production builds.
- Rotate exposed credentials immediately if any TrapDoor packages are found in your dependency tree, and enforce multi-factor authentication across all developer and cloud accounts.
- Eliminate hardcoded secrets from version control repositories and migrate to secure secrets management solutions.
Moving to Zero-Trust Dependencies
The TrapDoor campaign demonstrates that treating third-party packages as inherently trusted is no longer defensible. Organizations must adopt a zero-trust dependency model where every library — regardless of popularity or registry status — is verified before integration. Cryptographic provenance checks, continuous pipeline scanning, and strict credential hygiene are now baseline requirements.
As open-source ecosystems expand, the responsibility for supply chain security falls increasingly on individual engineering teams. Organizations that fail to implement proactive verification workflows risk becoming the next victims of campaigns like TrapDoor.
一場橫跨三大主要套件註冊表的協調供應鏈攻擊，正向全球開發人員分發竊取憑證的惡意軟件。據 The Hacker News 報道，這項名為 TrapDoor 的攻擊活動自 2026 年 5 月 22 日起，已在 npm、PyPI 及 Crates.io 上發布超過 34 個惡意套件，涵蓋逾 384 個版本。
威脅行為者正以精心計算的波浪式方式發布套件，旨在淹沒註冊表的審核隊列並繞過自動化安全掃描器。通過在短時間內向註冊表湧入數百個版本發布，攻擊者利用了開發團隊對已發布套件的隱含信任——這是去中心化開源生態系統固有的結構性弱點。
技術執行細節
TrapDoor 套件中嵌入的惡意軟件作為憑證收集器運作，從受感染環境中提取認證令牌、API 金鑰及開發人員機密資訊。一旦作為依賴項安裝，惡意載荷會在標準構建或運行時過程中執行，靜默地將竊取的憑證傳輸至攻擊者控制的基礎設施。
此攻擊活動依賴「近似名稱搶註」手法——註冊與合法、廣泛使用的程式庫極為相似的套件名稱——以誘騙開發人員將受感染的代碼引入其專案中。結合波浪式發布策略，這造成了狹窄的檢測窗口：當安全團隊或註冊表管理員識別並移除恶意套件時，受影響的組織可能已經暴露了憑證。
企業開發團隊的風險
對於管理大規模軟件組合的 IT 團隊而言，TrapDoor 活動暴露了現代開發工作流程中的一個關鍵漏洞。嚴重依賴第三方程式庫而缺乏嚴格驗證的組織面臨更高的風險，特別是當自動化 CI/CD 流程在沒有加密來源驗證的情況下解析依賴項時。
此次攻擊揭示了一種系統性失衡：套件註冊表優先考慮快速發布和開發人員效率，而安全審查機制則落後於此。這一差距使惡意行為者能夠在檢測發生之前將受感染的代碼注入生產環境。
建議審計清單
安全團隊應立即採取行動評估暴露情況並加強依賴項管理實踐：
- 執行依賴項審計，使用 Snyk、Dependabot 或 OWASP Dependency-Check 等軟件組成分析工具，識別任何符合已發布 TrapDoor 入侵指標的套件。
- 移除或隔離在審計期間發現的任何未經驗證或可疑套件，直至其來源得到確認。
- 實施套件允許清單，僅限安裝預先批准、已驗證且具有已知加密簽名的程式庫。
- 將自動化掃描整合至 CI/CD 流程，以在未經認證的套件到達生產構建之前予以攔截。
- 立即輪換已暴露的憑證（如在依賴項樹中發現任何 TrapDoor 套件），並對所有開發人員及雲端帳戶實施多因素認證。
- 從版本控制儲存庫中消除硬編碼機密資訊，並遷移至安全的機密資訊管理解決方案。
邁向零信任依賴項
TrapDoor 攻擊活動表明，將第三方套件視為固有可信的做法已不再站得住腳。組織必須採用零信任依賴模型，在整合之前驗證每一個程式庫——無論其受歡迎程度或註冊表狀態如何。加密來源驗證、持續流程掃描及嚴格的憑證衛生現已成為基本要求。
隨著開源生態系統不斷擴展，供應鏈安全的責任日益落在個別工程團隊身上。未能實施主動驗證工作流程的組織，面臨成為 TrapDoor 等攻擊活動下一批受害者的風險。