OVHcloud CLI: cinque release dirottate con un ruba-segreti
Con l’account GitHub di uno sviluppatore, un attaccante ha sostituito i binari di OVHcloud CLI dalla 0.11.0 alla 0.15.0: chi è colpito e cosa fare subito.

Il 19 ottobre 2026 un attaccante ha usato l’account GitHub di uno sviluppatore di OVHcloud per sostituire i binari di cinque release già pubblicate della OVHcloud CLI, lo strumento open source a riga di comando con cui amministratori e sviluppatori gestiscono e automatizzano i servizi cloud e di hosting del fornitore francese. Al posto dei file originali è comparso un binario che, secondo il fondatore e CEO Octave Klaba, ha il compito di recuperare i segreti presenti sul disco. Ne hanno scritto BleepingComputer, SecurityWeek e The Hacker News; i dettagli tecnici di seguito vengono dalle dichiarazioni di Klaba su X e dall’analisi della piattaforma comunitaria OpenSourceMalware, riprese dalle prime due testate.
Cosa è successo
Le versioni compromesse sono v0.11.0, v0.12.0, v0.13.0, v0.14.0 e v0.15.0. La 0.10.0 e la nuova 0.16.0 sono pulite. Secondo Klaba la release compromessa è apparsa alle 14:47 (ora di Parigi) ed è stata bloccata alle 16:21, dopo la segnalazione di un cliente: una finestra di circa 94 minuti. OpenSourceMalware, citata da SecurityWeek, riferisce che un utente ha segnalato pubblicamente la manomissione su GitHub dopo il fallimento di un controllo automatico dell’hash.
La causa indicata da OVHcloud è di configurazione: l’opzione release immutability di GitHub era disattivata. Un account con i permessi adeguati poteva quindi modificare direttamente le release esistenti, senza passare dalla pipeline CI/CD. Klaba precisa che le pipeline, con test unitari, test funzionali e controllo delle CVE, non sono state toccate. L’opzione ora è attiva e, secondo BleepingComputer, OVHcloud considera l’incidente risolto.
Klaba descrive il binario come «di scarsa qualità, ma può arrivare fino in fondo», e chiede a chi è stato colpito di ripulire il sistema e di cambiare tutti i segreti presenti sul disco.
Dettagli tecnici
Secondo OpenSourceMalware l’attaccante non ha usato la CI/CD: ha caricato binari compilati in locale sopra i file originali delle release già pubblicate. Sono state sostituite solo le build delle piattaforme più comuni, un indizio che per i ricercatori punta alla raccolta di credenziali sulle postazioni di sviluppo e di gestione operativa:
- colpiti: macOS (Intel e ARM), Linux x86_64 e ARM64, Windows x86-64, se installati o aggiornati nella finestra tramite lo script di installazione ufficiale, Homebrew o il download diretto da GitHub;
- non colpiti: chi ha compilato dai sorgenti, chi ha usato il comando di installazione di Go e chi usa l’immagine Docker ufficiale.
Il payload non è stato analizzato: OpenSourceMalware non è riuscita a ottenerne un campione prima che OVHcloud cancellasse i file. Non ci sono quindi indicatori pubblici (hash, domini, indirizzi) del binario distribuito con la CLI.
L’account usato appartiene a un contributore legittimo di OVHcloud e, secondo i ricercatori, era compromesso almeno da marzo 2026: il 5 marzo la storia di quattro suoi repository personali è stata riscritta con uno script, e in tre è comparso un loader nascosto (preinstall.js). La fase successiva del loader interroga la blockchain Solana (un dead drop nel campo memo delle transazioni) per sapere dove scaricare il payload, usando un wallet che è un indicatore noto di GlassWorm, la campagna attiva dalla fine del 2025 contro gli ecosistemi VS Code, OpenVSX, GitHub e npm.
Il collegamento con GlassWorm va letto con cautela: i ricercatori stessi scrivono che l’idea che lo stesso attore abbia compromesso l’account a marzo e colpito la CLI a ottobre è una loro deduzione, e OVHcloud non ha citato GlassWorm nelle sue dichiarazioni.
Nella nostra lettura le tecniche MITRE ATT&CK pertinenti sono T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1552.001 (Credentials In Files) e, per il loader dei repository personali, T1102.001 (Dead Drop Resolver).
Impatto per le aziende europee e italiane
OVHcloud è uno dei principali fornitori cloud europei e molte aziende italiane ci ospitano servizi e infrastrutture. La CLI gira sulle macchine con più privilegi: postazioni di amministratori e sviluppatori, server di gestione e runner di CI/CD. Sono le stesse macchine che conservano chiavi API, chiavi SSH, token e file di configurazione per altri ambienti, quindi l’esposizione può andare oltre l’account OVHcloud.
Per i soggetti NIS2 la sicurezza della catena di fornitura e dello sviluppo è una delle misure richieste: un binario malevolo eseguito su una postazione con accesso all’infrastruttura va valutato anche come possibile incidente da notificare, in base agli accessi effettivamente ottenuti.
Cosa fare subito
- Individua le installazioni: cerca la OVHcloud CLI su postazioni, server e runner, e verifica se è stata installata o aggiornata il 19 ottobre tra le 14:47 e le 16:21 ora di Parigi (12:47–14:21 UTC) con lo script ufficiale, Homebrew o il download da GitHub. Contano anche le immagini di container costruite in quella finestra scaricando il binario.
- Sostituisci il binario con la 0.16.0, oppure compila dai sorgenti. Se hai una 0.11.0–0.15.0 e non sai quando è stata scaricata, trattala come sospetta.
- Considera compromessi tutti i segreti della macchina che ha eseguito un binario colpito, come chiede Klaba: credenziali API di OVHcloud e degli altri cloud, chiavi SSH, token di Git e dei registri, file
.enve configurazioni. Ruotali e revoca quelli vecchi. - Controlla l’uso delle credenziali dal 19 ottobre nei registri dei fornitori: accessi da indirizzi insoliti, nuove chiavi, modifiche all’infrastruttura.
- Ripulisci o reinstalla le macchine colpite: senza un’analisi del payload non è noto se lasci persistenza.
- Rafforza la catena di fornitura: fissa le versioni degli strumenti e verifica gli hash prima dell’installazione, come ha fatto l’utente che ha scoperto la manomissione. Se pubblichi software su GitHub, attiva la release immutability, richiedi l’MFA ai contributori e sorveglia le modifiche ai file delle release già pubblicate.
Come aiuta ARXDOME
ARX Sentry raccoglie con il suo agent l’inventario di software e processi di computer e server Windows, Linux e macOS: permette di trovare rapidamente le macchine su cui è installata la CLI. Se una macchina è sospetta, ARX Shield consente di isolarla dalla rete in attesa della pulizia e della rotazione dei segreti.
Ultimo aggiornamento:


