TrapDoor: 34+ pacchetti malevoli trasformano gli AI assistant in insider threat

Il 19 maggio 2026 è emerso il primo artifact di una campagna cross-ecosystem senza precedenti: TrapDoor, un'operazione di supply chain che ha distribuito oltre 34 pacchetti malevoli con 384+ versioni su npm, PyPI e Crates.io. La novità non sta solo nella scala, ma in un vettore inedito — file di configurazione AI come .cursorrules e CLAUDE.md iniettati con istruzioni nascoste che inducono l'assistente a esfiltrare segreti locali, trasformando uno strumento di produttività in un insider threat silenzioso.

Come funziona il payload multi-ecosistema

TrapDoor non si limita a un singolo registro. Secondo le analisi di Socket Security e Phoenix Security, la campagna ha colpito npm con 21 pacchetti e 335 versioni, PyPI con 7 pacchetti e 10 versioni, e Crates.io con 6 pacchetti e 6 versioni. Ogni ecosistema ha ricevuto una variante ottimizzata del payload.

Su npm, il file trap-core.js da 48.485 byte rappresenta il cuore operativo. Questo script scansiona SSH keys, AWS credentials, GitHub tokens, profili browser e wallet crypto; valida i token trovati tramite chiamate API dirette; instaura persistenza con tecniche multiple; e implementa movimento laterale via SSH. La dimensionalità del file — 1.149+ linee — indica una maturità progettuale inconsueta per malware distribuito via package registry.

Su PyPI, il meccanismo cambia: i pacchetti Python scaricano un payload JavaScript remoto dal dominio ddjidd564.github[.]io e lo eseguono tramite node -e. Socket Security ha evidenziato che "questa tecnica permette al pacchetto Python di delegare l'esecuzione a un payload JavaScript remoto, dando all'attaccante maggiore flessibilità dopo la pubblicazione". Il decoupling tra package pubblicato e payload effettivo consente aggiornamenti in tempo reale senza traccia su PyPI.

I crate Rust utilizzano build.rs per cifrare i keystore con una chiave XOR hardcoded — la stringa cargo-build-helper-2026 — e esfiltrano i dati a GitHub Gists. La chiave hardcoded permette reverse engineering immediato da parte dei ricercatori, ma ha garantito operatività durante le prime fasi della campagna.

L'iniezione AI: zero-width Unicode e la trust relationship violata

La vera innovazione di TrapDoor risiede nell'abuso della trust relationship tra sviluppatori e AI assistant. I file .cursorrules e CLAUDE.md — documenti di configurazione legitimi usati per istruire Cursor, Claude e strumenti simili — sono stati iniettati con istruzioni nascoste tramite caratteri Unicode zero-width: U+200B, U+200C, U+200D, U+FEFF. Questi caratteri sono invisibili a occhio nudo e durante la normale revisione del codice.

L'effetto è che l'AI assistant legge e segue istruzioni di cui lo sviluppatore non ha consapevolezza. Phoenix Security ha osservato che "l'attaccante può piazzare istruzioni nel percorso dell'AI assistant di uno sviluppatore senza che il dev le legga mai". Il risultato: l'assistente esegue uno "security scan" che in realtà raccoglie ed esfiltra segreti locali, con l'autorità implicita del contesto di sviluppo.

Questo meccanismo non sfrutta una vulnerabilità nei tool AI. È abuso di funzionalità legittime di parsing config — il che lo rende particolarmente insidioso, perché nessun patch di sicurezza del vendor può mitigarlo completamente.

"TrapDoor shows how attackers are combining traditional package typosquatting with newer developer-environment attack paths" — Socket Security

Timeline e evoluzione in cinque fasi

Phoenix Security ha ricostruito una timeline a cinque fasi. La Phase 1 inizia il 19 maggio 2026 con crypto-credential-scanner v2.0.0 su npm, orientato al furto di credenziali crypto. The Hacker News/Socket riportano invece come "earliest activity" le 20:20 UTC del 22 maggio — una discrepanza minore che riflette probabilmente diverse soglie di rilevamento.

La Phase 2, sempre il 22 maggio, introduce i pacchetti AI-themed e il primo rilascio di trap-core.js. La Phase 3 vede l'espansione su PyPI con i pacchetti che delegano al payload remoto. La Phase 4, il 24 maggio, aggiunge Crates.io con la variante Rust XOR-encrypted. La Phase 5 è concorrente: l'apertura di pull request a progetti AI popolari come langchain-ai/langchain, langflow-ai/langflow, browser-use/browser-use, run-llama/llama_index, FoundationAgents/MetaGPT e OpenHands/OpenHands.

Le PR non risultano necessariamente mergeate — le fonti indicano "testing" e "opened", non accettazione. Il loro scopo era probabilmente sondare la facilità di iniezione o distribuire file config malevoli attraverso repository pubblici.

Perché gli scanner tradizionali non rilevano TrapDoor

Phoenix Security ha sottolineato un limite strutturale: "Per i team che si affidano solo a prioritizzazione basata su CVSS, TrapDoor è invisibile". La campagna non ha CVE associato, nessuna vulnerabilità software dichiarata, nessuna versione da patchare. I pacchetti sono funzionalmente legittimi — installano ciò che promettono, spesso strumenti di scanning o utility di sicurezza — e attivano il payload malevolo in fasi ritardate: postinstall, import, o build.

Socket Security ha rilevato la maggior parte dei pacchetti entro minuti dalla pubblicazione, con un record di 58 secondi. Questo dato, riportato anche da CCN, illustra la necessità di rilevamento comportamentale in tempo reale piuttosto che scan statici su database di vulnerabilità.

L'account GitHub ddjidd564 ha ospitato documentazione interna del malware — file denominati AUDIT-MATRIX.md, PAYLOAD.md, BYPASS.md — che CCN ha identificato come indicatore dell'organizzazione operativa dell'attore. L'account è lo stesso che gestisce il dominio ddjidd564.github[.]io usato per il payload remoto PyPI.

Cosa fare adesso

Le raccomandazioni operative derivano direttamente dai meccanismi documentati nelle fonti.

• Auditare i lockfile (package-lock.json, poetry.lock, Cargo.lock) per presenza di pacchetti con nomi pertinenti a crypto development, AI tooling, local environment setup e security workflows, che Socket Security ha identificato come pattern di naming della campagna.
• Ispezionare i file di configurazione AI (.cursorrules, CLAUDE.md, e equivalenti) con strumenti che rivelino caratteri zero-width Unicode, poiché le istruzioni nascoste sono invisibili alla revisione standard.
• Ruotare le credenziali esposte in ambienti di sviluppo che hanno installato pacchetti da registry pubblici nel periodo 19-25 maggio 2026, con focus su SSH keys, AWS credentials, GitHub tokens e wallet crypto.
• Implementare rilevamento comportamentale sui workflow di build e installazione per identificare chiamate a domini esterni durante postinstall o build.rs, in particolare verso GitHub Pages non affiliati al progetto.

Il brief non documenta misure correttive da parte dei registry (npm, PyPI, Crates.io) né la presenza di rimozioni automatiche: lo stato attuale dei singoli pacchetti richiede verifica manuale.

La lezione operativa: quando l'ambiente diventa superficie d'attacco

Socket Security ha incorniciato TrapDoor come segnale di cambiamento: "I nomi dei pacchetti sono calibrati per apparire rilevanti allo sviluppo crypto, agli strumenti AI, al setup di ambiente locale e ai workflow di sicurezza". Questa calibrazione non è casuale. L'attaccante ha studiato il percorso decisionale dello sviluppatore moderno — dalla ricerca del pacchetto giusto all'accettazione implicita delle dipendenze — e ha inserito il payload esattamente dove la pressione del tempo e la fiducia nell'ecosistema open source generano cecità operativa.

La componente AI injection aggiunge una dimensione che i controlli tradizionali non coprono. Non è più sufficiente chiedersi se un pacchetto è malevolo; occorre chiedersi se l'intero ambiente di sviluppo — inclusi i file che l'AI assistant legge automaticamente — è stato compromesso in modi non rilevabili dalla revisione umana. Il confine tra tool e minaccia si dissolve, e TrapDoor è il primo esempio documentato su scala di questa fusione.

Domande frequenti

TrapDoor sfrutta una vulnerabilità nei tool AI come Cursor o Claude?

No. Il meccanismo non è un exploit di sicurezza nel software AI, ma abuso di funzionalità legittime di parsing dei file di configurazione. I tool AI leggono e seguono le istruzioni in .cursorrules e CLAUDE.md per design; l'attacco inserce istruzioni nascoste che lo sviluppatore non percepisce.

Perché la campagna non ha un CVE?

TrapDoor non sfrutta una vulnerabilità software identificabile in un prodotto specifico. Distribuisce pacchetti che funzionano come dichiarato e attivano payload malevoli in fasi ritardate. Senza CVE, senza CVSS, senza advisory vendor tradizionale, la minaccia non compare nei database standard di vulnerabilità.

I pacchetti malevoli sono ancora disponibili sui registry?

Le fonti non specificano lo stato attuale di rimozione per tutti i pacchetti. Alcuni sono stati rilevati e probabilmente rimossi entro minuti dalla pubblicazione, ma altri potrebbero persistere o essere stati ripubblicati con varianti. La verifica manuale dei lockfile resta necessaria.

Fonti

• https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html
• https://phoenix.security/trapdoor-supply-chain-ai-poisoning-npm-pypi-crates/
• https://www.rescana.com/post/trapdoor-supply-chain-attack-actively-exploiting-npm-pypi-and-cratesio-to-steal-developer-credentials-in-crypto-defi-sol
• https://thomasharris6.wordpress.com/2026/05/25/trapdoor-supply-chain-attack-spreads-credential-stealing-malware-via-npm-pypi-and-cratesio/
• https://www.ccn.com/news/crypto/trapdoor-malware-npm-pypi-rust-packages-steal-crypto-wallets/
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability
• https://thehackernews.com/search/label/Cyber%20Attack

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti