Tra il 18 e il 19 luglio 2026, tre pacchetti RubyGems distribuiti da account mantainer dormienti da anni hanno eseguito codice malevolo al momento del caricamento della libreria, non durante l'installazione. L'attacco, denominato SleeperGem, ha bypassato i controlli di sicurezza basati su CI e ha stabilito backdoor persistenti su macchine di sviluppatori, dimostrando che RubyGems ha ora gli stessi problemi di npm e PyPI.
- Le versioni malevole 2.8.0-2.8.3 di
git_credential_managersono state pubblicate in circa nove ore dal 18 luglio, con l'esecuzione attivata alrequiredalla versione 2.8.2 e resa operativa nella 2.8.3 dopo 17 minuti - Il malware ha verificato circa 30 variabili d'ambiente CI (GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins, Vercel) e ha terminato l'esecuzione se rilevava un ambiente di build, eludendo così i controlli pipeline
- StepSecurity ha confermato via Harden-Runner la catena runtime: processo Ruby figlio, download di
deploy.shdagit.disroot.orgcon verifica SSL disabilitata, installazione di persistenza via systemd e cron, tentativo di shell setuid root in/usr/local/sbin/ping6 - I due account compromessi confermati — LR-DEV (Dendreo) e pinkroom (fastlane plugin) — erano dormienti rispettivamente da ottobre 2020 e marzo 2019; il plugin Fastlane contava 574.661 download totali prima del compromesso
Il require-time execution: il momento che l'AppSec ignora
Nella maggior parte delle pipeline di sicurezza software, il pericolo viene localizzato nel momento dell'installazione: gli hook post-install, gli script pre-compilazione, le azioni di build. RubyGems, come npm e PyPI, consente esecuzione di codice in fase di installazione, e questo è ciò che gli strumenti di sicurezza monitorano.
La versione 2.8.2 di git_credential_manager ha introdotto una inversione di questa logica. L'installer è stato collegato direttamente al percorso di caricamento della gemma, secondo l'analisi di Aikido Security. Il semplice require 'git_credential_manager' — un'operazione routine e invisibile per milioni di sviluppatori Ruby — attivava l'intera catena.
Questo è particolarmente insidioso nei linguaggi interpretati. In Ruby, require è un gesto quotidiano, automatico, spesso nascosto dentro Bundler o framework come Rails. Nessuno controlla cosa accade quando una libreria entra in memoria. Il confine tra "installazione sicura" e "runtime pericoloso" si dissolve.
La dormienza come vettore d'attacco
"A RubyGems account che è rimasto inattivo per sei o sette anni non sembra rischioso a nessuno. È esattamente il profilo che vale la pena prendere di mira." — Charlie Eriksen, Aikido Security
L'account LR-DEV aveva pubblicato l'ultima versione di Dendreo nell'ottobre 2020. L'account pinkroom era inattivo dal marzo 2019. Questa cronologia ha due effetti: elimina la vigilanza — nessuno segnala anomalie su un account che non pubblica — e preserva la legittimità: le gemme accumulate download, stelle, dipendenze transitive nel tempo.
Dendreo 1.1.3 e 1.1.4 sono state pubblicate il 18 luglio. fastlane-plugin-run_tests_firebase_testlab 0.3.2 è arrivata il 19 luglio. Nessuna di queste release aveva commit o tag GitHub corrispondenti, secondo StepSecurity. La firma mancante era evidente, ma rilevabile solo se qualcuno controllava — e nessuno controlla account dormienti.
La catena runtime documentata da Harden-Runner
StepSecurity ha eseguito la detonazione controllata della gemma tramite Harden-Runner, catturando l'albero dei processi e gli eventi di rete. Il risultato: un processo Ruby figlio che genera sh, poi cp, chmod, e infine un demone nativo. Il demone viene installato in $HOME/.local/share/gcm/git-credential-manager e configurato per la persistenza tramite servizio systemd utente e voce cron.
L'evento di rete registrato alle 14:04:57 del 19 luglio 2026 mostra due chiamate API verso git.disroot.org, una istanza Forgejo controllata dall'attaccante. Il download avviene con OpenSSL::SSL::VERIFY_NONE: la verifica del certificato TLS è disabilitata esplicitamente nel codice, come riportato da Aikido Security con estratto del sorgente.
StepSecurity ha inoltre documentato il tentativo di installare una copia setuid della shell di sistema in /usr/local/sbin/ping6, un percorso scelto per mimetizzarsi come utility di rete. L'operazione è stata osservata ma bloccata dalla mancanza di sudo senza password nell'ambiente di test. Resta documentato come intento, non come successo garantito.
Cosa fare adesso
Le workstation che hanno caricato qualsiasi delle tre gemme devono essere considerate compromesse a pieno titolo. Questo implica la rotazione di tutte le credenziali — non solo quelle RubyGems, ma chiavi SSH, token API, accessi cloud, password manager — memorizzate o accessibili dalla macchina.
Le organizzazioni che usano Ruby, Bundler o Fastlane devono controllare i lockfile per verificare la presenza di git_credential_manager versioni 2.8.x, dendreo 1.1.3-1.1.4, o fastlane-plugin-run_tests_firebase_testlab 0.3.2. RubyGems ha rimosso le versioni malevole, ma chi le aveva già in cache locale resta esposto.
Le macchine degli sviluppatori richiedono ispezione manuale per meccanismi di persistenza: servizi systemd a livello utente, voci cron, file in ~/.local/share/gcm/, e binari sospetti in percorsi di sistema come /usr/local/sbin/. Il malware ha specificamente evitato l'ambiente CI: un test di build superato non costituisce garanzia di sicurezza.
I team security devono estendere il monitoraggio alle dipendenze dormienti. Gemme senza aggiornamenti da anni ma con download sostanziali devono essere segnalate per verifica periodica, come già avviene per npm e PyPI. Il profilo di rischio è identico: account abbandonato, riutilizzato, sfruttato per la sua patina di legittimità.
Perché RubyGems, perché ora
L'attacco non sfrutta una vulnerabilità di RubyGems.org come piattaforma, ma una vulnerabilità del modello di fiducia: la mancanza di meccanismi di revoca o verifica per account che tornano attivi dopo anni di silenzio. npm ha affrontato campagne simili nel 2022-2024; PyPI ha introdotto verifiche obbligatorie per account inattivi. RubyGems, fino a SleeperGem, era rimasto relativamente indenne — non per robustezza, ma per minore appetibilità dell'ecosistema.
Questo presupposto è ora morto. Il valore di un attacco supply chain non sta solo nel numero di download immediati, ma nella qualità dei bersagli: sviluppatori con accesso a codice sorgente, infrastrutture di rilascio, segreti di produzione. Una gemma Fastlane con 574.661 download totali è un ponte diretto verso pipeline CI/CD mobile, ambienti di test distribuiti, e — attraverso le macchine degli sviluppatori — verso reti aziendali segmentate.
Domande e risposte
Perché il malware evitava esplicitamente i CI?
Perché gli ambienti CI sono monitorati: log verbosi, strumenti di rilevamento anomalie, sandboxing. Le macchine degli sviluppatori sono più opache, meno controllate, e spesso hanno accesso privilegiato a repository e infrastrutture. Il malware ha invertito il modello di minaccia classico: non il build server, ma il laptop dello sviluppatore.
Le versioni malevole sono ancora disponibili?
No. Il team di sicurezza di RubyGems ha rimosso le versioni compromesse dal repository. Tuttavia, la rimozione dal registro centrale non elimina le copie locali in cache, nei lockfile, o nelle immagini Docker già costruite.
Quanti account sono stati compromessi in totale?
Due sono confermati con certezza: LR-DEV e pinkroom. Il dossier non esclude account aggiuntivi, ma non documenta né numeri né nomi oltre questi due. La dichiarazione assertiva si ferma qui.
Fonti
- https://www.aikido.dev/blog/sleepergem-rubygems-supply-chain-attack
- https://forum.devtalk.com/t/sleepergem-rubygems-supply-chain-attack-targets-dormant-maintainer-accounts/248124
- https://corgea.com/research/sleepergem-rubygems-dormant-maintainer-backdoor-july-2026
- https://mallory.ai/stories/019f79a2-1d28-725b-9e14-d9c191786265
- https://thehackernews.com/2026/07/sleepergem-uses-three-malicious.html
- https://www.stepsecurity.io/blog/sleepergem-compromised-rubygems-drop-persistent-backdoor
- https://www.tipranks.com/news/private-companies/supply-chain-vulnerability-in-rubygems-highlights-growing-software-security-risks
- https://app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/29690115671?tab=network-events&jobId=88201233434
- https://docs.stepsecurity.io/github-actions/harden-runner/baseline
- https://docs.stepsecurity.io/developer-machines
- https://www.stepsecurity.io/github-actions-audit?utm_source=blog&utm_medium=in_post_cta&utm_campaign=sleepergem-compromised-rubygems-drop-persistent-backdoor&utm_content=rung2_actions_audit
- https://app.stepsecurity.io/action-advisor?utm_source=blog&utm_medium=in_post_cta&utm_campaign=sleepergem-compromised-rubygems-drop-persistent-backdoor&utm_content=rung1_action_advisor
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.