Toate articolele

Noutăți20 octombrie 20265 min de citit

OVHcloud CLI: cinci versiuni deturnate pentru furtul de secrete

Cu contul GitHub al unui dezvoltator, un atacator a înlocuit binarele OVHcloud CLI de la 0.11.0 la 0.15.0: cine este afectat și ce trebuie făcut imediat.

Mâini pe tastatura unui laptop cu linii de cod pe ecran, lângă un al doilea monitor

Pe 19 octombrie 2026, un atacator a folosit contul GitHub al unui dezvoltator OVHcloud pentru a înlocui binarele a cinci versiuni deja publicate ale OVHcloud CLI, instrumentul open source în linie de comandă cu care administratorii și dezvoltatorii gestionează și automatizează serviciile cloud și de hosting ale furnizorului francez. În locul fișierelor originale a apărut un binar al cărui rol, potrivit fondatorului și CEO-ului Octave Klaba, este să recupereze secretele de pe disc. Au relatat BleepingComputer, SecurityWeek și The Hacker News; detaliile tehnice de mai jos provin din declarațiile lui Klaba pe X și din analiza platformei comunitare OpenSourceMalware, preluate de primele două publicații.

Ce s-a întâmplat

Versiunile compromise sunt v0.11.0, v0.12.0, v0.13.0, v0.14.0 și v0.15.0. Versiunea 0.10.0 și noua 0.16.0 sunt curate. Potrivit lui Klaba, versiunea compromisă a apărut la 14:47 (ora Parisului) și a fost blocată la 16:21, după semnalarea unui client: o fereastră de aproximativ 94 de minute. OpenSourceMalware, citată de SecurityWeek, arată că un utilizator a semnalat public modificarea pe GitHub după ce o verificare automată a hash-ului a eșuat.

Cauza indicată de OVHcloud ține de configurare: opțiunea release immutability din GitHub era dezactivată. Un cont cu permisiunile potrivite putea deci modifica direct versiunile existente, fără să treacă prin pipeline-ul CI/CD. Klaba precizează că pipeline-urile, cu teste unitare, teste funcționale și detectarea CVE, nu au fost afectate. Opțiunea este acum activă și, potrivit BleepingComputer, OVHcloud consideră incidentul rezolvat.

Klaba descrie binarul ca fiind „de calitate slabă, dar poate merge până la capăt” și le cere celor afectați să curețe sistemul și să schimbe toate secretele de pe disc.

Detalii tehnice

Potrivit OpenSourceMalware, atacatorul nu a folosit CI/CD: a încărcat binare compilate local peste fișierele originale ale versiunilor deja publicate. Au fost înlocuite doar build-urile pentru platformele cele mai răspândite, un indiciu care, pentru cercetători, arată spre colectarea de credențiale de pe stațiile de lucru ale dezvoltatorilor și ale echipelor de operațiuni:

  • afectate: macOS (Intel și ARM), Linux x86_64 și ARM64, Windows x86-64, dacă au fost instalate sau actualizate în fereastra respectivă prin scriptul de instalare oficial, Homebrew sau descărcarea directă de pe GitHub;
  • neafectate: cine a compilat din surse, cine a folosit comanda de instalare din Go și cine folosește imaginea Docker oficială.

Payload-ul nu a fost analizat: OpenSourceMalware nu a reușit să obțină o mostră înainte ca OVHcloud să șteargă fișierele. Prin urmare, nu există indicatori publici (hash-uri, domenii, adrese) pentru binarul distribuit cu CLI-ul.

Contul aparține unui contributor legitim al OVHcloud și, potrivit cercetătorilor, era compromis cel puțin din martie 2026: pe 5 martie, istoricul a patru dintre depozitele sale personale a fost rescris cu un script, iar în trei dintre ele a apărut un loader ascuns (preinstall.js). Etapa următoare a loader-ului interoghează blockchain-ul Solana (un dead drop în câmpul memo al tranzacțiilor) ca să afle de unde să descarce payload-ul, folosind un wallet care este un indicator cunoscut al GlassWorm, campania activă de la sfârșitul lui 2025 împotriva ecosistemelor VS Code, OpenVSX, GitHub și npm.

Legătura cu GlassWorm trebuie privită cu prudență: cercetătorii înșiși scriu că ideea ca același actor să fi compromis contul în martie și să fi atacat CLI-ul în octombrie este o deducție a lor, iar OVHcloud nu a menționat GlassWorm în declarațiile sale.

În lectura noastră, tehnicile MITRE ATT&CK relevante sunt T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1552.001 (Credentials In Files) și, pentru loader-ul din depozitele personale, T1102.001 (Dead Drop Resolver).

Impactul pentru companiile europene și italiene

OVHcloud este unul dintre principalii furnizori cloud europeni, iar multe companii își găzduiesc acolo servicii și infrastructură. CLI-ul rulează pe mașinile cu cele mai multe privilegii: stațiile de lucru ale administratorilor și dezvoltatorilor, serverele de administrare și runner-ele CI/CD. Sunt aceleași mașini care păstrează chei API, chei SSH, token-uri și fișiere de configurare pentru alte medii, așa că expunerea poate depăși contul OVHcloud.

Pentru entitățile NIS2, securitatea lanțului de aprovizionare și a dezvoltării este una dintre măsurile cerute: un binar malițios rulat pe o stație de lucru cu acces la infrastructură trebuie evaluat și ca posibil incident de notificat, în funcție de accesul obținut efectiv.

Ce trebuie făcut imediat

  1. Identifică instalările: caută OVHcloud CLI pe stații de lucru, servere și runner-e și verifică dacă a fost instalat sau actualizat pe 19 octombrie între 14:47 și 16:21, ora Parisului (12:47–14:21 UTC), prin scriptul oficial, Homebrew sau descărcarea de pe GitHub. Contează și imaginile de container construite în acea fereastră care descarcă binarul.
  2. Înlocuiește binarul cu 0.16.0 sau compilează din surse. Dacă ai o versiune 0.11.0–0.15.0 și nu știi când a fost descărcată, trateaz-o ca suspectă.
  3. Consideră compromise toate secretele de pe mașina care a rulat un binar afectat, așa cum cere Klaba: credențialele API OVHcloud și ale altor cloud-uri, cheile SSH, token-urile Git și ale registrelor, fișierele .env și configurațiile. Rotește-le și revocă-le pe cele vechi.
  4. Verifică utilizarea credențialelor începând cu 19 octombrie în jurnalele furnizorilor: autentificări de la adrese neobișnuite, chei noi, modificări ale infrastructurii.
  5. Curăță sau reinstalează mașinile afectate: fără o analiză a payload-ului nu se știe dacă lasă persistență.
  6. Întărește lanțul de aprovizionare: fixează versiunile instrumentelor și verifică hash-urile înainte de instalare, cum a făcut utilizatorul care a descoperit modificarea. Dacă publici software pe GitHub, activează release immutability, cere MFA contributorilor și urmărește modificările fișierelor din versiunile deja publicate.

Cum ajută ARXDOME

Cu agentul său, ARX Sentry colectează inventarul de software și procese al calculatoarelor și serverelor Windows, Linux și macOS, astfel încât poți găsi rapid mașinile pe care este instalat CLI-ul. Dacă o mașină este suspectă, ARX Shield îți permite să o izolezi de rețea până când este curățată și secretele îi sunt rotite.

Ultima actualizare:

Ai întrebări?

Hai să vorbim despre nevoile companiei tale, fără obligații.

Contactează-ne

Articole similare