// 1 CRITICAL · 4 ZERO-DAY · 5 CVE · 6 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Quattro attacchi in sette settimane hanno compromesso npm e PyPI. La provenanza Sigstore e SLSA e risultata inutile: l'attaccante ha rubato l'identita CI, non

Tra l'inizio di giugno e il 14 luglio 2026, quattro distinti attacchi alla supply chain hanno colpito gli ecosistemi npm e PyPI. Gli aggressori hanno dimostrato di saper aggirare le difese più recenti: dall'istallazione con script disabilitati per default alla verifica della provenanza tramite Sigstore e SLSA. La tecnica decisiva non e stata la falsificazione della firma, ma la compromissione dell'identita di build nella pipeline CI/CD. "Different entry points, one objective: land where the credentials live and leave with them." Cosi GitGuardian riassume la strategia comune ai quattro attacchi.

Punti chiave
  • Quattro attacchi distinti tra giugno e luglio 2026: Hades su PyPI, SDK di pagamento typosquat, token npm rubato per jscrambler, e compromissione CI/CD di AsyncAPI tramite exploit di pull_request_target
  • Gli aggressori hanno spostato l'esecuzione dai lifecycle script — disabilitati in npm v12 l'8 luglio 2026 — all'importazione del modulo, rendendo inefficaci le protezioni basate sull'installazione
  • I pacchetti AsyncAPI compromessi trasportavano attestazioni Sigstore e SLSA valide: l'attaccante non ha forgiato nulla, ha rubato l'identita OIDC del sistema di build
  • La vulnerabilita pull_request_target di AsyncAPI era stata segnalata 58 giorni prima con fix proposto non mergato, secondo GitGuardian e Wiz

Hades, Miasma e la memoria degli agent CI

La prima ondata, identificata come variante PyPI di Miasma con la stringa "Hades - The End for the Damned", ha colpito almeno 29 pacchetti in due fasi: un'ondata iniziale a inizio giugno e un secondo rilascio l'8 giugno. Il meccanismo tecnicamente rilevante e l'uso di file *-setup.pth, eseguiti automaticamente all'avvio di Python, che scaricano il runtime Bun JavaScript e avviano il payload.

StepSecurity ha documentato un'innovazione specifica: Hades include una routine di prompt injection avversariale progettata per ingannare gli analizzatori LLM automatizzati. Il testo inserito in cima al file e costruito per dirottare le istruzioni di sistema dell'analizzatore e classificare il pacchetto come infrastruttura pulita verificata. L'attacco non si limita all'esecuzione: un memory scraper cross-platform estrae dati dai runner GitHub Actions, sfruttando /proc/mem su Linux, le API Mach VM su macOS e ReadProcessMemory su Windows.

SecurityWeek ha riportato che il totale combinato di Miasma e Hades supera i 100 pacchetti e 471 artefatti malevoli tra npm e PyPI.

Il typosquat che aspetta sei minuti

Il 7 luglio 2026, un attacco coordinato su npm e PyPI ha piazzato circa 17 pacchetti con nomi typosquat di SDK di pagamento: paysafe-checkout, paysafe-node, neteller e varianti correlate. La tecnica di ritardo nella raccolta delle credenziali — progettata per eludere le sandbox di analisi dinamica — e risultata vulnerabile alla velocita di rilevamento: i pacchetti sono stati identificati e rimossi in circa sei minuti. I target dichiarati nella configurazione di filtraggio includevano AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN e NPM_TOKEN.

jscrambler: il token rubato che ha aggirato npm v12

L'11 luglio 2026, un token npm compromesso ha permesso la pubblicazione di cinque versioni malevole del pacchetto jscrambler e dei plugin correlati per webpack, gulp, grunt e metro. Il payload nativo multi-piattaforma e stato progettato per eseguire all'importazione del modulo o all'invocazione CLI, non durante l'installazione. Questa scelta rende inefficace la protezione introdotta da npm v12, che ha disabilitato gli install scripts per default l'8 luglio 2026. GitGuardian ha quantificato in 1.479 i download delle versioni malevole prima della rimozione. L'attacco e stato classificato come variante evoluta di IronWorm.

AsyncAPI: quando il CI firma il malware con provenanza valida

L'attacco del 14 luglio 2026 contro AsyncAPI e quello che riassume il paradosso tecnico della campagna. L'aggressore ha aperto 37 pull request come camuffamento; una ha sfruttato la configurazione vulnerabile del workflow pull_request_target per rubare il personal access token dell'account asyncapi-bot. Con quel token, ha pushato commit malevoli sui branch next e master, pubblicando quattro pacchetti in cinque versioni con oltre 2,25 milioni di download settimanali combinati.

La finestra di esposizione e stata di circa quattro ore: dalle 07:10 UTC alle 11:18 UTC, secondo GitGuardian. StepSecurity conferma il push a 06:58 UTC e la pubblicazione a 07:10 UTC. I payload eseguono su require(), scaricano un RAT multi-stadio da IPFS, stabiliscono persistenza via systemd e comunicano con infrastrutture C2 su HTTP, Nostr, Ethereum smart contract e rete peer-to-peer mesh.

"The most concerning piece of this for security teams... was that those backdoored packages carried valid Sigstore and SLSA provenance. The attacker did not forge anything. They compromised the CI identity, so the build system signed the malware honestly." — GitGuardian, riferendo analisi di Chainguard

Wiz ha esaminato lo smart contract Ethereum 0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710 usato come fallback C2, confermando l'indirizzo. Unit 42 di Palo Alto Networks ha invece tracciato la campagna come "miasma-train-p1" del 14 luglio 2026, con payload discendente dal RAT Miasma. Il C2 decentralizzato — che sfrutta Ethereum, Nostr e BitTorrent DHT — rappresenta un'evoluzione strutturale rispetto ai server centralizzati tradizionali.

La provenanza Sigstore e SLSA, in questo scenario, ha funzionato esattamente come progettato: ha attestato che il pacchetto proveniva dalla pipeline CI di AsyncAPI. Il problema e che la pipeline era compromessa. "Provenance proved where the package came from. It said nothing about whether the source was trustworthy when it was built." La distinzione tra autenticita dell'origine e integrita del processo e diventata il punto cieco.

Cosa fare adesso

Per i team che gestiscono dipendenze open source, la campagna impone quattro priorità operative:

  • Verificare la configurazione dei workflow pull_request_target nei repository pubblici e privati: la vulnerabilita AsyncAPI era stata segnalata 58 giorni prima con fix proposto non mergato, secondo GitGuardian e Wiz
  • Ispezionare i lock file: le versioni malevole di AsyncAPI possono ancora essere risolte da installazioni esistenti anche dopo la rimozione dai registry
  • Valutare che gli strumenti di analisi statica e dinamica non siano vulnerabili a prompt injection avversariali come quella documentata in Hades
  • Rivedere la fiducia accordata alle attestazioni di provenanza: Sigstore e SLSA attestano l'origine, non la sicurezza del codice sorgente al momento della build

Il confine spostato: da chi installa a chi importa

Gli attacchi hanno spostato il perimetro del rischio. La disabilitazione degli install scripts in npm v12 — risposta corretta al problema del preinstall — e stata aggirata semplicemente cambiando momento di esecuzione. L'importazione del modulo e diventata il nuovo trigger. Parallelamente, la trust architecture della CI/CD — OIDC, provenance, firme automatizzate — e stata weaponizzata contro chi la implementa.

La frequenza degli attacchi — quattro in sette settimane, con tecniche che si evolvono tra un incidente e l'altro — normalizza un rischio che l'ecosistema open source non e strutturato per assorbire. Endor Labs, citato da Cybernews, aveva anticipato il problema: "The practical implication for defenders: a package can now carry a valid provenance badge and still be malicious." La campagna AsyncAPI e Hades non e una violazione della promessa di Sigstore: e il rispetto letterale di quella promessa applicato a un CI compromesso.

Fonti

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

Fonti


Fonti e riferimenti
  1. blog.gitguardian.com
  2. rapidfort.com
  3. unit42.paloaltonetworks.com
  4. cybernews.com
  5. stepsecurity.io
  6. securityweek.com
  7. wiz.io