OVHcloud waarschuwt dat er iets is misgegaan in de software supply chain rondom de OVHcloud CLI. Een aanvaller zou toegang hebben gekregen tot het GitHub-account van een (legitieme) developer en daarmee een geheime-verzamelende component hebben toegevoegd aan een reeks officiële CLI-releases. Het resultaat: bepaalde gebruikers konden een gemanipuleerde versie installeren die gegevens van lokale schijven kan uitlezen.
De gebeurtenis valt op 19 oktober. OVHcloud noemt een reeks versies als gecompromitteerd en geeft ook aan welke distributiekanalen en platforms wél en niet zijn geraakt. Hieronder zet ik de belangrijkste punten op een rij, zodat je snel kunt bepalen of jij actie moet ondernemen.
Wat er is gebeurd bij de OVHcloud CLI gehackt
Volgens OVHcloud is de aanval uitgevoerd via GitHub. De hacker gebruikte het GitHub-profiel van een ontwikkelaar om in de officiële command-line interface (CLI) een extra binary te plaatsen. Die component heeft als doel secrets van de disk op te halen.
De basis van het incident is dus niet een klassiek “runtime”-exploit in de CLI, maar een supply chain verstoring: wat als officiële release werd aangeboden, bevatte een ongewenste toevoeging. OVHcloud noemt dat de kwaliteit van de binary in technische zin beperkt was, maar dat het effect kon doorreiken tot het verzamelen van gevoelige gegevens.
Welke OVHcloud CLI versies zijn gecompromitteerd
OVHcloud maakt duidelijk welke releases risico liepen. De volgende versies worden als besmet beschouwd:
- v0.11.0 t/m v0.15.0 (gecompromitteerd)
Daarentegen meldt OVHcloud dat:
- v0.10.0 en
- v0.16.0 (nieuw uitgebracht)
als clean worden beschouwd. Met andere woorden: als je versie buiten deze besmette range valt, is de kans op een geïnjecteerde secret-stealer kleiner.
Hoe de aanval de releases kon manipuleren
Een cruciale factor volgens OVHcloud is de inrichting van release management op GitHub. OVHcloud geeft aan dat de immutability-optie voor releases niet was ingeschakeld. Daardoor konden gebruikers met de juiste rechten bestaande releases aanpassen zonder dat de gebruikelijke checks vanuit CI/CD automatisch gingen meelopen.
OVHcloud stelt ook dat de CI/CD pipelines zelf niet zijn geraakt. De verstoring zat in het feit dat de release-artifacts op GitHub achteraf konden worden gemodificeerd, in plaats van dat de aanval via de bouwstap van de pipeline is gelopen.
Toen de kwestie werd gemeld door een klant, zou OVHcloud het probleem binnen ongeveer 1,5 uur hebben kunnen blokkeren. Onderzoekers merkten bovendien op dat openbare hashes niet klopten nadat geautomatiseerde controles faalden.
Via welke distributiekanalen was de OVHcloud CLI gehackt te installeren?
Niet iedereen die de CLI ooit gebruikte, zat in hetzelfde risicoprofiel. OVHcloud geeft aan dat gebruikers die de CLI tijdens het incident hebben geïnstalleerd of geüpdatet via de officiële installscript, Homebrew of via een directe GitHub download, geraakt konden zijn.
Dat gold met name voor de platformen:
- macOS
- 64-bit Linux
- Windows x86_64
Daartegenover staat dat mensen die:
- de CLI uit broncode bouwden,
- Go’s install command gebruikten, of
- de officiële Docker image ophaalden
volgens OVHcloud niet zijn geraakt. Voor incident-respons is dat relevant: de manier van installeren bepaalt deels of je een gemanipuleerd artifact hebt binnengehaald.
Wie was betrokken en wat zeggen onderzoekers hierover?
Onderzoekers stellen dat het GitHub-account van een legitieme OVHcloud contributor al langere tijd mogelijk gecompromitteerd was. Ze koppelen dat aan ten minste maart 2026, toen meerdere persoonlijke repositories werden herschreven en daarbij een verborgen loader werd toegevoegd.
De volgende fase van die loader zou, volgens onderzoekers, de Solana blockchain raadplegen om de locatie van een additionele payload te vinden. Ze koppelen die activiteit aan een bekende indicator die eerder bij GlassWorm is gezien.
Belangrijk: onderzoekers konden niet met zekerheid bevestigen dat dezelfde actor verantwoordelijk was voor zowel de maartcompromissie als de aanval van oktober. Ze formuleren het als een inference (hun inschatting). OVHcloud noemt in de gepubliceerde statements daarbij niet expliciet GlassWorm.
Verder geldt dat onderzoekers vóór verwijdering door OVHcloud geen volledige payload konden bemachtigen voor grondige analyse. Dat beperkt de mogelijkheid om harde conclusies te trekken over de volledige kill chain.
Waarom dit vooral raakt aan werkstations en operations
De onderzoekers concluderen dat alleen builds voor de meest voorkomende platforms waren vervangen. Dat patroon past volgens hen bij een doelgerichte strategie rond credential harvesting op plekken waar ontwikkelaars en operations teams werken.
Met andere woorden: niet alleen “servers” zijn mogelijk interessant geweest, maar juist ook machines waarop credentials lokaal aanwezig zijn (bijvoorbeeld in configbestanden of omgevingsvariabelen). Ook al is de exacte inhoud van de verzameling niet gedeeld in de bron, het type doel is duidelijk: secrets uit de omgeving halen.
Wat moet je nu doen als je OVHcloud CLI gebruikt?
Omdat dit een supply chain incident is met potentieel directe impact op gevoelige informatie, is het verstandig om snel te handelen. Je aanpak hangt af van jouw installatiehistorie.
1) Check je versie
Ga na welke OVHcloud CLI versie je gebruikt. Als je één van de gecompromitteerde releases v0.11.0 t/m v0.15.0 draait, neem dan aan dat er een risico is geweest.
2) Controleer waar je vandaan installeerde
Als je de CLI installeerde via de officiële installscript, Homebrew of directe GitHub downloads, vergroot dat de kans dat je het gemanipuleerde artifact binnenhaalde. Gebruikte je bronbouw of Go-install, of de officiële Docker image, dan is de kans kleiner.
3) Herzie je secret hygiene
Als er een mogelijkheid is dat een secret-stealer op jouw machine gedraaid heeft, is het verstandig om sleutels en tokens die mogelijk lokaal aanwezig waren te rotaten en opnieuw in te stellen waar nodig. Concentreer je daarbij op credentials die je gebruikt voor CI/CD, cloud, deployment en toegang tot interne systemen.
4) Let op signalen en procesrichtlijnen
Maak daarnaast afspraken over supply chain governance: verifieer artifacts waar mogelijk, maak gebruik van checksums waar dit past, en borg dat release processen geen enkele “bypass” laten ontstaan wanneer CI/CD niet betrokken is.
Als je wilt zien hoe dit soort incidenten organisatorisch te benaderen is, kun je ook kijken naar eerdere artikelen over AI- en security-governance: AI-software security: focus op volwassenheid. Hoewel het onderwerp anders is, gaat het daar om dezelfde kern: volwassen processen voorkomen dat kwetsbaarheden via tooling of workflow doorsijpelen.
Breder perspectief: supply chain aanvallen blijven terugkomen
Dit incident past in een patroon waarin aanvallers niet alleen kwetsbaarheden in code zoeken, maar ook vertrouwen in distributiekanalen misbruiken. Denk aan het manipuleren van binaries, het herverpakken van artifacts, of het inzetten van gecompromitteerde accounts om “legitieme” updates te distribueren.
Op onze site staan meerdere voorbeelden van supply chain problemen. Zo is er een vergelijkbaar verhaal over een gecompromitteerde backupketen: Gecompromitteerde AOMEI Backupper: supply chain in minuten. Die context helpt om te begrijpen waarom incidenten als deze vaak snel meerdere organisaties of omgevingen raken.
Conclusie
De kern van het incident is dat OVHcloud CLI gehackt werd via een gecompromitteerd GitHub-account en gemanipuleerde release-artifacts. OVHcloud noemt specifiek dat v0.11.0 t/m v0.15.0 zijn gecompromitteerd, terwijl v0.10.0 en v0.16.0 schoon worden geacht. Gebruikers die de CLI tijdens het incident installeerden via installscript, Homebrew of directe GitHub downloads op macOS, 64-bit Linux of Windows x86_64 lopen het meeste risico.
Heb je één van de genoemde versies gedraaid? Dan is het verstandig om nu je installatie te verifiëren, verdachte secret exposure aan te nemen en passende rotaties uit te voeren. In supply chain security geldt: snelle, praktische checks leveren vaak meer winst dan afwachten.
Bron: https://www.securityweek.com/hijacked-developer-account-used-to-plant-stealer-in-ovhcloud-cli/
