TrapDoor: 34+ pacchetti malevoli colpiscono sviluppatori crypto e AI
La campagna TrapDoor ha diffuso malware ruba-credenziali su npm, PyPI e Crates.io con oltre 384 versioni, esfiltrando wallet crypto e manipolando assistenti AI.
Contenuto
TrapDoor non è un attacco a singoli pacchetti, ma un assalto al flusso di lavoro dello sviluppatore crypto e AI. La campagna ha distribuito oltre 34 pacchetti malevoli e 384 versioni su npm, PyPI e Crates.io trasformando l'ambiente di sviluppo in una superficie d'attacco continua: dai registry agli assistenti AI, ogni fase della pipeline è diventata un vettore di esfiltrazione credenziali e wallet.
- TrapDoor colpisce il flusso di lavoro dello sviluppatore, non solo i registry.
- Oltre 34 pacchetti e 384 versioni su npm, PyPI e Crates.io esfiltrano credenziali e wallet.
- L'attacco manipola assistenti AI tramite file nascosti nelle repository open source.
"Several npm packages also deploy a shared payload, trap-core.js, that scans for credentials, validates AWS and GitHub tokens, attempts SSH-based lateral movement, and plants persistence through .cursorrules, CLAUDE.md, Git hooks, shell hooks, systemd, cron, and SSH." — Socket, via The Hacker News
Come TrapDoor aggredisce tre ecosistemi con tecniche diverse
La campagna dimostra una comprensione rara della meccanica interna di ogni registry. Su npm, il payload trap-core.js — 1.149 righe di JavaScript — si attiva al momento dell'installazione tramite l'hook postinstall.
Il codice scansiona il filesystem alla ricerca di chiavi SSH, variabili d'ambiente, credenziali cloud, token di servizio e wallet crypto tra cui Coinbase, Binance, MetaMask, Solana, Sui e Aptos. Valida i token AWS e GitHub tramite chiamate API live e stabilisce persistenza multipla: cron job, servizi systemd, SSH authorized keys, Git hooks e shell hooks.
Il payload è condiviso tra diversi pacchetti npm, rendendo la manutenzione del malware centralizzata per l'intero vettore.
Su PyPI, la strategia è diversa. I pacchetti malevoli non contengono il payload completo: al momento dell'import, scaricano JavaScript remoto da ddjidd564.github[.]io e lo eseguono con node -e. Questa delegazione rende l'attacco particolarmente agile: l'operatore può aggiornare il payload senza pubblicare nuove versioni su PyPI, eludendo i controlli del registry e rendendo il malware resilientemente remoto.
Rust e Crates.io rappresentano il terzo vettore. Qui il malware sfrutta build.rs, lo script di build eseguito automaticamente durante la compilazione. Cerca keystore locali, cifra i dati con una chiave XOR hardcoded ed esfiltra il risultato su GitHub Gists — tutto prima che il codice Rust effettivo venga compilato. L'attacco sfrutta la natura compilata di Rust per nascondere l'attività malevola in una fase che molti sviluppatori non ispezionano abitualmente.
La novità: weaponization degli assistenti AI tramite file nascosti
Ciò che distingue TrapDoor da campagne precedenti è il tentativo sistematico di manipolare gli strumenti AI adottati rapidamente dagli sviluppatori. L'account GitHub ddjidd564 — collegato alla campagna — ha aperto pull request su repository di rilievo: langchain-ai/langchain, browser-use/browser-use, run-llama/llama_index, FoundationAgents/MetaGPT e OpenHands/OpenHands. I titoli delle PR erano studiati per apparire innocui, spesso riferiti a sicurezza o configurazione ambientale.
I file iniettati — .cursorrules per Cursor e CLAUDE.md per Claude — contenevano istruzioni occultate mediante zero-width Unicode. Queste istruzioni inducevano l'assistente AI a eseguire "security scan" che, in realtà, esfiltravano segreti dal progetto. La tecnica sfrutta la fiducia implicita che gli sviluppatori ripongono nei file di configurazione del progetto, che raramente vengono sottoposti a code review attenta.
L'efficacia reale di questa manipolazione su larga scala resta non verificata: le fonti la descrivono come tecnica potenzialmente sperimentale, ma il suo inserimento in una campagna operativa segnala l'intenzione di normalizzarla come vettore standard.
Socket, tempi di rilevamento e nomi studiati per il trust
Socket ha rilevato le release TrapDoor con un tempo mediano di 5 minuti e 27 secondi su 381 record pacchetto-versione, con il rilevamento più veloce a 58 secondi dalla pubblicazione. Questi numeri, pur essendo interni al vendor e non verificabili indipendentemente, suggeriscono che la campagna ha generato segnali anomali sufficientemente marcati per essere individuata rapidamente — forse proprio per la sua stessa aggressività.
I nomi dei pacchetti rivelano il targeting preciso: wallet-security-checker, defi-env-auditor, sui-move-build-helper, prompt-engineering-toolkit. Non si tratta di typosquatting classico, ma di nomi plausibili che sfruttano le esigenze reali di sviluppatori in crypto, DeFi e AI. L'account ddjidd564 ha mantenuto repository lure come env-security-scanner e pubblicato issue e discussioni su sicurezza fittizia per costruire credibilità prima dell'attacco.
Socket ha confermato che TrapDoor non ha collegamenti con l'omonima campagna di ad fraud su Android descritta da HUMAN/Satori: omonimia casuale, nessuna sovrapposizione tecnica o di infrastruttura.
Cosa fare adesso
Le contromisure devono essere immediate e specifiche, perché TrapDoor colpisce in fasi diverse del flusso di sviluppo.
- Ispezionare postinstall, build.rs e script di import nei progetti esistenti: i tre vettori di TrapDoor si attivano in fasi diverse del flusso di sviluppo, non tutte visibili durante la normale esecuzione del codice applicativo.
- Verificare la presenza di .cursorrules, CLAUDE.md e file di configurazione AI in ogni repository, anche quelli che non installano direttamente dipendenze sospette: la superficie d'attacco si è estesa agli strumenti di editing.
- Validare ogni PR esterna su file di configurazione, particolarmente quelle che modificano percorsi di sicurezza o workflow: l'account ddjidd564 ha dimostrato che questo vettore è operativo e scalabile.
- Trattare l'installazione di dipendenze da npm/PyPI/Crates.io come potenziale compromissione totale della workstation e delle pipeline CI/CD, non come rischio isolato al singolo pacchetto: il lateral movement di TrapDoor è progettato per propagarsi.
Nessuna fase della pipeline può essere considerata implicitamente sicura dopo questa campagna.
Perché TrapDoor cambia la prospettiva sul rischio supply chain
La campagna segnala un'inflessione: l'attacco non punta più solo al registry come punto di ingresso, ma all'ambiente di sviluppo nel suo complesso. La convergenza di crypto, DeFi e AI ha creato una popolazione di sviluppatori che gestisce asset di valore elevato con strumenti sempre più complessi e spesso meno auditati. TrapDoor sfrutta questa asimmetria: più superficie tecnica, stessa attenzione alla sicurezza.
La manipolazione degli assistenti AI e il supply chain attack tradizionale non sono rischi separati, ma due fasi dello stesso assalto alla fiducia dello sviluppatore. Se i file di configurazione del progetto diventano canali di prompt injection, la distinzione tra 'codice mio' e 'codice esterno' si dissolve rapidamente. La risposta non può essere solo tecnica: richiede una revisione dei processi di review e della fiducia riposta negli strumenti automatizzati.
L'ambiente di sviluppo è diventato la nuova superficie d'attacco privilegiata: non più un mero canale di distribuzione, ma il bersaglio stesso della campagna.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html
- https://sqmagazine.co.uk/trapdoor-malware-npm-pypi-rust-developers/
- https://www.cryptotimes.io/2026/05/25/trapdoor-malware-hits-npm-pypi-crates-io-steals-crypto-wallets-ssh-keys/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.