OVHcloud CLI compromisă pe GitHub: ce trebuie să facă urgent administratorii și dezvoltatorii
OVHcloud a confirmat compromiterea distribuției oficiale pentru instrumentul său de linie de comandă, ovhcloud-cli, folosit de administratori și dezvoltatori pentru gestionarea serviciilor cloud, a serverelor, rețelelor și proiectelor de automatizare. Atacatorii nu au modificat codul sursă sau pipeline-urile CI/CD ale companiei, ci au preluat un cont GitHub de contributor și au înlocuit arhivele descărcabile ale unor release-uri deja publicate cu binare malițioase. Miza nu este o simplă eroare de actualizare: software-ul modificat urmărea să găsească și să fure secrete locale — chei API, token-uri, credențiale cloud sau chei SSH. Pentru echipele din România care folosesc OVHcloud în proiecte de hosting, VPS, cloud public ori automatizări DevOps, incidentul trebuie tratat ca unul de supply chain, nu ca o alertă care poate fi ignorată. (bleepingcomputer.com)
Ce s-a întâmplat și care sunt versiunile afectate
Incidentul a avut loc duminică, 19 octombrie 2026. Potrivit informațiilor publicate de OVHcloud și analizate ulterior de cercetători, un atacator a folosit un cont GitHub de contributor compromis pentru a înlocui fișierele binare din release-urile v0.11.0, v0.12.0, v0.13.0, v0.14.0 și v0.15.0.
Fișierele malițioase au fost disponibile aproximativ 94 de minute, între 12:47 și 14:21 UTC. Fereastra pare scurtă, dar este suficientă pentru a afecta automatizări: un pipeline CI care descarcă mereu cea mai recentă versiune sau un script de instalare rulat într-un interval nepotrivit poate introduce binarul compromis direct pe o stație de administrare ori pe un runner de CI/CD. (thehackernews.com)
OVHcloud a indicat că versiunea v0.10.0 nu este afectată, iar v0.16.0, lansată după incident, este versiunea curată recomandată. Release-ul nou este marcat ca immutable pe GitHub, ceea ce înseamnă că activele deja publicate nu mai pot fi înlocuite ulterior; pot fi modificate doar titlul și notele release-ului. (github.com)
Afectate au fost arhive pentru macOS — Intel și Apple Silicon —, Linux x86_64 și ARM64, precum și Windows x86_64. Nu orice utilizator care avea una dintre versiunile enumerate instalată este automat compromis: riscul concret apare pentru cei care au descărcat, instalat sau actualizat binarul în fereastra de expunere din 19 octombrie. (thehackernews.com)
De ce este grav un malware care caută „secrete”
Un instrument CLI de cloud rulează, de regulă, pe laptopul administratorului, pe un bastion, într-un runner CI/CD sau pe o mașină de build. Exact în aceste locuri sunt stocate cele mai valoroase date pentru un atacator: token-uri GitHub, chei de acces la furnizorul cloud, credențiale SSH, variabile de mediu cu parole, configurații Docker sau Kubernetes și fișiere .env.
Pentru mai multe detalii despre această parte a subiectului, vezi Nu mai plăti pe minut pentru GitHub Actions: Cum să îți găzduiești propriile CI/CD runners pe un VPS de 5 €.
Cu un token valid, un atacator nu trebuie să „spargă” infrastructura de la zero. Poate acționa ca un utilizator legitim: să citească date din storage, să creeze mașini virtuale pentru mining sau atacuri, să modifice DNS, să copieze backup-uri ori să acceseze alte servicii conectate. De aceea, recomandarea de a schimba secretele nu este excesivă. Ștergerea CLI-ului sau actualizarea sa rezolvă doar problema binarului; nu anulează ce ar fi putut fi deja extras.
Ghid ServerSpan relevant: Bitwarden CLI compromis printr-un atac supply chain – Ce s-a întâmplat și ce trebuie să faci chiar acum (23 aprilie 2026).
Pentru o firmă mică din România, consecința poate fi disproporționată. Un singur laptop al unei persoane tehnice poate păstra acces la website-ul companiei, la contul de cloud, la repo-uri, la email tranzacțional și la infrastructura de backup. În acest scenariu, o cheie API compromisă poate deveni drumul către mai multe sisteme, nu doar către contul OVHcloud.
Merită făcută distincția între risc și certitudine: informațiile publice spun că malware-ul urmărea secrete locale, însă analiza completă a payload-ului nu a fost posibilă deoarece exemplarele malițioase nu au fost păstrate pentru cercetare independentă. Așadar, nu există o listă confirmată și exhaustivă a tuturor datelor pe care le putea extrage. Tocmai această lipsă de certitudine justifică rotația preventivă a credențialelor. (bleepingcomputer.com)
Cum a fost ocolită protecția normală a procesului de release
Partea cea mai instructivă a incidentului este că atacatorii nu au spart pipeline-urile CI/CD ale OVHcloud și nu au modificat codul sursă al proiectului. Au înlocuit direct arhivele de release, încărcând local un build malițios. Cu alte cuvinte, un repository poate avea teste automate, scanare de vulnerabilități și semnături pentru commit-uri, dar toate acestea nu protejează complet utilizatorul dacă activele publicate pot fi modificate ulterior de un cont cu privilegii.
În acest caz, setarea GitHub de „release immutability” nu era activată. După incident, OVHcloud a activat-o și a publicat versiunea 0.16.0 ca release imuabil. Este o corecție importantă, dar lecția este mai largă: în software supply chain, integritatea codului nu este identică cu integritatea fișierului executabil descărcat de utilizator. (bleepingcomputer.com)
Mai există un detaliu practic relevant. Scriptul oficial de instalare descărca arhiva de release fără verificare de hash, iar aceeași problemă exista pentru anumite fluxuri de actualizare. Dacă un atacator înlocuiește și fișierul cu sumele de control, verificarea hash-ului descărcat din același release nu mai oferă protecție reală. Un hash ajută doar dacă este comparat cu o valoare obținută dintr-un canal separat, de încredere și ideal semnat. (thehackernews.com)
Pentru organizații, răspunsul nu este renunțarea la open source sau la automatizare. Răspunsul este controlul versiunilor: dependințe fixate, checksum-uri păstrate intern, artefacte aprobate într-un registry propriu și separarea token-urilor personale de credențialele folosite în producție.
Legătura cu GlassWorm: relevantă, dar încă neconfirmată
Cercetătorii de la OpenSourceMalware au asociat contul GitHub compromis cu indicii care seamănă cu activitatea campaniei GlassWorm. În istoricul public al acelui cont au fost observate rescrieri de istoric și un loader ascuns care folosea un mecanism de tip „dead drop” în memo-urile tranzacțiilor Solana pentru a recupera etapa următoare a atacului.
GlassWorm este cunoscută pentru atacuri asupra ecosistemelor de dezvoltare, inclusiv extensii VS Code și OpenVSX, cu interes pentru credențiale GitHub, npm, Git și alte secrete de dezvoltare. CERT-EU a documentat anterior folosirea codului Unicode invizibil, a infrastructurii bazate pe Solana și capacitatea de propagare prin conturi compromise. (cert.europa.eu)
Totuși, legătura dintre GlassWorm și binarele malițioase OVHcloud trebuie tratată cu precauție. Cercetătorii vorbesc despre o inferență, bazată în principal pe contul compromis și pe urmele lăsate în alte repository-uri. Nu există, la acest moment, o atribuire tehnică definitivă a payload-ului distribuit prin CLI către aceeași grupare. (thehackernews.com)
Ce merită ignorat: speculațiile care transformă imediat cazul într-un atac confirmat asupra tuturor serviciilor OVHcloud. Incidentul public vizează pachetele de release ale ovhcloud-cli, nu platforma OVHcloud în ansamblu, iar compania spune că sursele și pipeline-urile CI/CD nu au fost afectate. Ce nu trebuie ignorat este faptul că un simplu update de utilitar poate deschide accesul la infrastructura unei organizații.
Pași practici pentru echipele afectate:
- Verificați dacă ați instalat sau actualizat
ovhcloud-clipe 19 octombrie 2026, în special versiunilev0.11.0–v0.15.0. - Opriți utilizarea binarului suspect și treceți la
v0.16.0din release-ul oficial curent. - Rotiți token-urile OVHcloud, cheile SSH, credențialele GitHub, secretele CI/CD și variabilele de mediu disponibile pe sistemul afectat.
- Verificați logurile pentru autentificări neobișnuite, chei API nou create, modificări DNS, instanțe cloud neașteptate sau descărcări de date.
- Pentru viitor, fixați versiunile și hash-urile în pipeline-uri, în loc să descărcați automat „latest”.
Concluzia este simplă: acest caz nu este important pentru că OVHcloud a avut un release compromis timp de puțin peste o oră, ci pentru că arată cât de fragil poate fi lanțul dintre cod, release și infrastructura reală. Pentru administratori și dezvoltatori, actualizarea la versiunea sigură este doar primul pas. Cel mai important este să presupună că secretele expuse pot fi deja în posesia altcuiva și să le invalideze rapid, controlat și documentat.