dYdX: terzo attacco supply chain, pacchetti npm e PyPI compromessi

I pacchetti ufficiali @dydxprotocol/v4-client-js su npm e dydx-v4-client su PyPI sono stati compromessi per distribuire malware: un wallet stealer su entrambi gli ecosistemi, con l'aggiunta di un Remote Access Trojan nel payload PyPI. Socket, vendor di sicurezza per supply chain open source, ha rilevato l'anomalia il 27 gennaio 2026 e notificato dYdX il giorno successivo, alle 12:19 UTC. È il terzo incidente che colpisce l'infrastruttura di distribuzione del protocollo dal 2022, questa volta con escalation cross-ecosystem e persistenza remota.

Il meccanismo: malware nel cuore dei pacchetti, non nelle dipendenze

L'attacco non ha sfruttato vulnerabilità tecniche nei registry npm o PyPI, ma è partito da un account maintainer legittimo, secondo la ricostruzione di Socket e The Hacker News. La modalità esatta del compromesso — phishing, credential stuffing, bypass MFA o insider — resta non confermata da dYdX al momento della pubblicazione.

Il ricercatore di sicurezza Kush Pandya di Socket ha evidenziato che l'attaccante "demonstrated detailed knowledge of the package internals, inserting malicious code into core registry files (registry.ts, registry.js, account.py) that would execute during normal package usage". Il malware si attiva nel flusso operativo standard: quando uno sviluppatore chiama createRegistry() passando una seed phrase, questa viene esfiltrata insieme a un fingerprint del dispositivo.

Su PyPI la complessità è superiore. Il payload RAT è protetto da 100 iterazioni di deobfuscazione: reverse della stringa, decoding base64, decompressione zlib con wbits=47. Il blob codificato misura 5.527 caratteri. Una volta deoffuscato, il RAT contatta il dominio dydx.priceoracle[.]site — typosquatting di dydx.xyz — per ricevere comandi da eseguire in subprocess isolato. Il token di autenticazione hardcoded è 490CD9DAD3FAE1F59521C27A96B32F5D677DD41BF1F706A0BF85E69CA6EBFE75. Un'API key esposta, dydx1gh6fj28w37rykqu6szgp9q0rzejslmj0umk55c, collega direttamente l'infrastruttura di attacco al brand dYdX.

Il fingerprinting cross-dispositivo calcola un hash SHA-256 concatenando MAC address e /etc/machine-id, permettendo all'attaccante di tracciare la stessa vittima su più installazioni.

"The 100-iteration obfuscation in the PyPI version and the coordinated cross-ecosystem deployment suggest the threat actor had direct access to publishing infrastructure rather than exploiting a technical vulnerability in the registries themselves" — Kush Pandya, Socket

Differenziazione cross-ecosystem: stesso attore, strategia adattiva

L'analisi di Socket evidenzia una progettazione deliberata: "The nearly identical credential theft implementations across languages indicate deliberate planning. The threat actor maintained consistent exfiltration endpoints, API keys, and device fingerprinting logic while deploying ecosystem-specific attack vectors".

Su npm l'obiettivo è il furto immediato di seed phrase — dato critico per wallet crypto non-custodial. Su PyPI si aggiunge la persistenza remota: il RAT permette esecuzione di codice arbitrario post-infiltrazione, aprendo scenari di movimento laterale, modifica di strategie di trading, o compromissione di infrastruttura backend. Il threat research team di Socket ha specificato che "Applications that use these packages in custodial contexts such as trading bots, automated strategies, or backend services that directly handle mnemonics or private keys for signing, are high-value targets for credential theft".

Il volume di trading cumulativo lifetime di dYdX è di circa 1,5 trilioni di dollari, con un daily average di 200-540 milioni di dollari, open interest di circa 175 milioni e oltre 70.700 token holder. Ogni integratore downstream — market maker, bot trader, aggregatore DeFi — costituisce una superficie d'attacco con esposizione finanziaria diretta.

Il pattern ricorrente: 2022, 2024, 2026

Questo non è il primo episodio. A settembre 2022, account npm staff di dYdX furono hijacked per compromettere i pacchetti @dydxprotocol/solo e @dydxprotocol/perpetual, come documentato da BleepingComputer. A luglio 2024 un DNS hijacking colpì la v3 dell'exchange. Ora, nel gennaio 2026, l'escalation passa da singolo ecosistema npm a npm + PyPI coordinati, con aggiunta di RAT.

La ricorrenza triennale con meccanismi diversi — hijack account 2022, DNS 2024, account maintainer cross-ecosystem 2026 — suggerisce un targeting sistematico dell'ecosistema dYdX piuttosto che attacchi opportunistici generici. Il dato che più colpisce: nonostante tre incidenti, la pubblicazione su npm e PyPI avviene ancora senza MFA obbligatoria verificata o controlli di coerenza automatici tra repository GitHub e artefatti pubblicati. Socket ha rilevato il pacchetto malevolo in "minuti" dalla pubblicazione, ma il tempo di rimozione non è quantificato nel dossier.

Cosa fare adesso

• Isolare macchine che hanno installato le versioni compromesse: dYdX ha raccomandato esplicitamente questo passaggio su X, dato il RAT PyPI con capacità di esecuzione remota
• Spostare fondi da wallet le cui seed phrase sono state passate a createRegistry(): esposizione diretta del seed = compromissione totale del wallet, non mitigabile con rotazione
• Ruotare API keys eventualmente inserite in configurazioni che usavano i pacchetti infetti, dato il tracciamento cross-device implementato dall'attaccante
• Verificare integrità installazioni confrontando hash dei file registry.ts, registry.js, account.py, config.py, _bootstrap.py con versioni su GitHub ufficiale dydxprotocol — esplicitamente confermate non compromesse

Perché questo caso apre una falla strutturale

Il problema non è dYdX-specifico, ma dYdX lo incarna con brutalità: un protocollo con miliardi di volume gestisce la propria supply chain open source con controlli che un singolo account maintainer compromesso può aggirare. L'assenza di MFA obbligatoria su publishing infrastructure, di firma artifact automatica, e di scanning pre-pubblicazione sui file core — non solo sulle dipendenze — è una vulnerabilità di design, non di implementazione.

Il ricorso all'obfuscation a 100 iterazioni e al typosquatting di domini noti indica che l'attaccante ha investito in anti-analisi e credibilità visiva, non solo in delivery. Il payload non è grezzo: è pensato per resistere a scansione statica rapida e per fondersi nel traffico legittimo verso endpoint dydx-branded. Questo livello di cura, combinato alla conoscenza interna dei pacchetti, separa l'incidente da una compromissione opportunistica di credenziali generica.

dYdX non ha riportato perdite quantificate né vittime identificate, ma non esclude compromissioni individuali. Il dossier non specifica se il dominio C2 sia stato sequestrato o se resti attivo. L'identità dell'attaccante e il numero esatto di download dei pacchetti infetti restano ignoti.

FAQ

Il malware è nei repository GitHub ufficiali?
No. dYdX e Socket hanno confermato esplicitamente che il codice sorgente su GitHub non contiene il payload malevolo; la compromissione è avvenuta a livello di pubblicazione npm/PyPI.

È lo stesso attaccante del 2022?
Non emergono sovrapposizioni infrastrutturali che colleghino l'attore del 2026 all'incidente del 2022; sono eventi separati con tecniche e timeline distinte.

Posso aver installato il pacchetto senza saperlo?
Solo se hai aggiornato o installato esplicitamente @dydxprotocol/v4-client-js nelle versioni 3.4.1, 1.22.1, 1.15.2, 1.0.31, o dydx-v4-client da PyPI, nel periodo di esposizione. Non è una dipendenza transitiva automatica di sistemi generici.

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

Fonti

• https://thehackernews.com/2026/02/compromised-dydx-npm-and-pypi-packages.html
• https://www.bleepingcomputer.com/news/security/npm-packages-used-by-crypto-exchanges-compromised/
• https://thehackernews.uk/ai-vuln-protection-d
• https://socket.dev/blog/malicious-dydx-packages-published-to-npm-and-pypi