Pacchetto PyPI imita SymPy: cryptomining silenzioso nella supply chain Python

0

SymPy è diventata il cavallo di Troia perfetto per un nuovo attacco di supply chain nel mondo Python. Il pacchetto sympy-dev, pubblicato su PyPI il 17 gennaio 2026, ha imitato in modo quasi indistinguibile la celebre libreria matematica simbolica, riuscendo a superare la soglia dei 1.000 download in meno di 24 ore e a distribuire in silenzio un payload di cryptomining Monero mirato a server Linux e ambienti CI/CD. L’operazione, individuata dal team di ricerca di Socket, dimostra quanto la fiducia implicita negli ecosistemi open-source resti uno dei punti più fragili della sicurezza moderna.

SymPy come bersaglio ideale per il typosquatting

La libreria SymPy registra circa 85 milioni di download mensili, secondo le metriche pubbliche, ed è ampiamente utilizzata in ricerca scientifica, ingegneria, didattica e data science. Questa diffusione capillare rende SymPy un target ideale per il typosquatting, una tecnica che sfrutta errori di digitazione o nomi “credibili” per indurre gli sviluppatori a installare dipendenze malevole.

Il pacchetto sympy-dev, pubblicato dall’account Nanit, ha copiato descrizione, stile e riferimenti del progetto legittimo, aumentando drasticamente la probabilità di installazioni accidentali. Le versioni 1.2.3, 1.2.4, 1.2.5 e 1.2.6 risultano tutte contaminate, segno che l’intento malevolo era presente sin dalla prima release.

Un malware che si attiva solo quando serve

A differenza di molti pacchetti malevoli, sympy-dev non esegue codice sospetto all’importazione iniziale. Il payload è nascosto all’interno di file chiave come polytools.py e polyroots.py e si attiva solo quando lo sviluppatore invoca funzioni specifiche, tra cui groebner() e roots_cubic(). Questo comportamento riduce drasticamente le possibilità di rilevamento in fase di test superficiale o scansione statica.

Quando il trigger viene attivato, il codice scarica una configurazione JSON remota e un binario ELF controllato dall’attaccante. L’esecuzione avviene interamente in memoria sfruttando la syscall Linux memfd_create, con lancio del payload da /proc/self/fd/<id>, evitando la scrittura di file persistenti su disco e complicando le analisi forensi.

Esecuzione in-memory e resilienza del payload

Il binario ELF distribuito è un miner XMRig, compresso con UPX e configurato per il mining CPU di Monero, con connessione a pool remoti via Stratum TLS sulla porta 3333. Sono stati osservati due endpoint di comando e controllo, utilizzati in modo ridondante per garantire continuità operativa anche in caso di blocco parziale dell’infrastruttura.

La scelta dell’esecuzione in-memory, unita alla soppressione silenziosa delle eccezioni, consente al malware di non interferire con il normale funzionamento di SymPy, evitando crash o anomalie evidenti. Per lo sviluppatore, l’unico segnale visibile può essere un improvviso consumo anomalo di CPU su sistemi che dovrebbero eseguire solo calcoli matematici o job CI temporanei.

Socket e la risposta dell’ecosistema PyPI

Il team di Socket ha classificato sympy-dev come malware e typosquat ad alto rischio, richiedendo formalmente la rimozione del pacchetto da PyPI e la sospensione dell’account del maintainer. Al momento della segnalazione, il pacchetto risultava ancora accessibile, a conferma delle difficoltà strutturali nel contenimento rapido degli abusi all’interno degli ecosistemi open-source più grandi.

L’incidente evidenzia un pattern ormai consolidato: attori malevoli non puntano più su zero-day complessi, ma su errori umani, automazioni CI e fiducia implicita nei repository pubblici. Un singolo pip install errato può trasformare una pipeline di build in una fonte di reddito per cryptominer criminali.

Rilevamento e segnali di compromissione

Le analisi statiche e dinamiche indicano alcuni segnali chiave. La presenza di chiamate a memfd_create, richieste HTTP dirette verso IP hardcoded, o l’esecuzione di binari da /proc/self/fd rappresentano indicatori forti di compromissione. Anche la comparsa di file come config.json in contesti SymPy è altamente sospetta, così come traffico outbound Python inatteso verso host esterni.

Nei sistemi colpiti, i processi Python risultano spesso associati a XMRig, con utilizzo CPU costante e assenza di file miner visibili su disco, proprio grazie all’esecuzione in-memory.

Una lezione per la sicurezza della supply chain open-source

Il caso sympy-dev conferma che la supply chain open-source è oggi uno dei vettori di attacco più redditizi. Ambienti CI/CD Linux, container di build e server di calcolo rappresentano obiettivi ideali: sempre accesi, ricchi di CPU e spesso poco monitorati sul piano del traffico di rete.

Per difendersi, le organizzazioni devono vincolare le dipendenze a versioni esplicite, verificare l’integrità dei pacchetti, isolare gli ambienti di build e monitorare costantemente comportamenti runtime anomali, non solo firme statiche. In un ecosistema dove un nome sbagliato può costare migliaia di cicli CPU, la vigilanza sulle dipendenze è ormai parte integrante della sicurezza applicativa.

Domande frequenti su sympy-dev e il malware PyPI