In korte tijd is er veel impact gemeld rondom de gecompromitteerde OVHcloud CLI. Op 19 oktober 2026 wisselden aanvallers via een gehijackte GitHub-account de download-archieven van meerdere bestaande releases van de OVHcloud command-line tool. Het aangepaste build was bedoeld om secrets te stelen die op de machine van de gebruiker zijn opgeslagen.
OVHcloud verwijderde de gemanipuleerde bestanden en publiceerde diezelfde avond een opgeschoonde versie (v0.16.0). Toch is het voor getroffen gebruikers belangrijk om snel te controleren en vooral om alle gevoelige gegevens die op het systeem staan te roteren.
Wat is er precies gebeurd met de OVHcloud CLI?
Volgens OVHcloud werd een contributor-account op GitHub gebruikt om in bestaande releases de bijbehorende downloadarchieven te vervangen. De vervanging ging live voor een beperkte periode: van 12:47 tot 14:21 UTC. In die tijd werden alleen mensen geraakt die in die window de tool installeerden of updateerden via bepaalde paden op macOS, Linux (x86_64 en arm64) of Windows (x86_64).
De broncode, de release tag en OVHclouds buildpipeline zouden niet zijn aangepast. In plaats daarvan werd er een “gewone” Go-build van een latere commit geüpload die zich als de release voordeed, terwijl hij in de praktijk bedoeld was voor het stelen van secrets op de draaiende machine.
Welke releases waren kwetsbaar?
OVHcloud gaf aan dat de releases v0.11.0 tot en met v0.15.0 als gecompromitteerd moeten worden beschouwd. Voor v0.10.0 meldt OVHcloud dat die versie schoon is.
Op v0.15.0 werden onder andere deze onderdelen vervangen:
- macOS x86_64 en arm64 archieven
- Linux x86_64 en arm64 archieven
- Windows x86_64 archief
- de checksums.txt
Doordat ook de checksums werden meegerekend, klopten de gepubliceerde hashes nog met de gemanipuleerde bestanden. Dat maakte detectie op basis van alleen “hash controleren” lastiger—zeker wanneer installatiestromen geen hash-verificatie deden.
Voor andere platformen zijn de archieven volgens het bericht niet geraakt: Linux i386, Windows i386, Windows arm64 en WebAssembly bleven op elke release buiten schot.
Hoe kon een gebruiker de gemanipuleerde CLI binnenkrijgen?
Je had een “swapped file” als je in de periode rond de swap één van de getroffen installatieroutes volgde. Concreet ging het om scenario’s waarin er geen hash-check plaatsvond:
1) Installeren via het officiële install-script
Wie het install-script draaide:
curl -fsSL https://raw.githubusercontent.com/ovh/ovhcloud-cli/main/install.sh | sh
… downloadde de nieuwste release-archive en installeerde die zonder hashcontrole. Juist dat maakte de route gevoelig tijdens het window van 12:47–14:21 UTC.
2) Archieven downloaden van GitHub release-pagina’s
Als je een archive pakte uit de releases van GitHub—van een van de vijf gecompromitteerde versies—dan kon je ook de gemanipuleerde build binnenkrijgen.
3) CI/jobs die de release-URL ophalen zonder vaste hash
Ook buildstappen of CI-jobs die een archive ophalen van de release download-URL zonder een ge-pinned hash liepen risico. Had je een pipeline die “automatisch” bijwerkt, dan kon de verkeerde file terechtkomen in je omgeving.
4) Upgraden met de CLI zelf
Een gebruiker die vanaf installaties van v0.12.0, v0.13.0 of v0.14.0 een upgrade draaide op een macOS- of Linux-systeem, kon eveneens de vervangende binary krijgen. Volgens de beschrijving was er bij sommige installaties een extra “print” stap, maar de kern is dat de tool de nieuwe archive ophaalde zonder hashcheck en het binaire bestand verving.
Wanneer was je juist niet geraakt?
Er waren ook duidelijke uitzonderingen. Zo bleek dat installatie via Homebrew in deze periode anders liep: Homebrew pinnde de oorspronkelijke SHA-256 per archive. Daardoor weigerde Homebrew een download wanneer de hash niet klopte, waardoor een gemanipuleerde versie niet zou kunnen worden geïnstalleerd via brew.
Verder gold dat je niet geraakt werd wanneer je:
- gebruikte go install of de bron bouwde (het v0.15.0 tag wees nog naar de commit van september)
- de Docker image pakte: de laatst gepushte tag dateerde van 21 september en werd niet opnieuw gebouwd tijdens het swap-moment
- al vóór 12:47 UTC installeerde en daarna niet meer update-de
Hoe kun je vaststellen of je te maken hebt met de kwaadwillende build?
De melding beschrijft dat een getroffen klant de buildinformatie uit de nieuwe v0.15.0 Linux arm64 binary haalde zonder de software uit te voeren (via go version -m). Die aanpak helpt omdat je niet “even” hoeft te draaien wat mogelijk kwaadaardig is.
De slechte build werd onder andere gekenmerkt door drie indicatoren:
- De module-regel bevatte een pseudo-version string in plaats van een echte release-tag
- De geregistreerde commit kwam niet overeen met wat de v0.15.0 tag normaal naar verwees
- Er was een -ldflags regel zichtbaar die OVHclouds normale releasepipeline niet op die manier toont
Er circuleerde daarnaast het idee dat een build met +dirty of bepaalde VCS-gerelateerde velden als verdacht zou moeten worden gezien. In het bericht wordt echter ook benoemd dat bij de schone v0.16.0 binary dergelijke kenmerken ook kunnen voorkomen (met “vcs.modified=true”), dus je kunt dat niet blind als enige beslisregel gebruiken.
OVHcloud gaf ook één specifiek bekend verschil in SHA-256 voor een gemanipuleerde file (Linux arm64 v0.15.0). Maar omdat het draaien van een verdachte binair om “meer te checken” niet aangeraden wordt, is het verstandig om je validatie te baseren op informatie die je kunt extraheren zonder executie.
Welke stappen moet je nu nemen?
De kernboodschap van OVHcloud is helder: rotteer alle secrets die op de machine staan wanneer je mogelijk een swapped build hebt gedraaid. OVHcloud noemt ook dat de CLI OVHcloud API-credentials uit een configuratiebestand (zoals ~/.ovh.conf) en uit omgevingsvariabelen kan lezen. Maar de waarschuwing gaat verder dan alleen OVHcloud-gegevens: alle secrets die op de machine leesbaar waren moeten worden gezien als potentieel blootgesteld.
Concreet luiden de aanbevolen acties:
1) Ga uit van blootstelling en roteer secrets
Als je de verkeerde build mogelijk hebt uitgevoerd, behandel dan elk geheim op die host als gecompromitteerd. OpenSourceMalware raadt daarnaast aan om dit uit te voeren vanaf een andere machine, om herbesmetting of onbedoelde toegang te verminderen.
2) Verwijder de verdachte binary en installeer v0.16.0
Vervang de tool door v0.16.0. OVHcloud beschrijft dat deze release als immutable is gepubliceerd en dat GitHub de bestanden niet laat wijzigen. Belangrijk detail: het rotatieadvies komt voor het vervangen. Updating vervangt wel het programma, maar “revoked” bestaande kopieën of eerder gekopieerde secrets worden niet automatisch teruggedraaid.
3) Verifieer het gedownloade archief
GitHub biedt een mechanisme om assets te verifiëren tegen een release (via gh release verify-asset). OVHcloud adviseert dit te gebruiken met de v0.16.0 release en het juiste bestand, zodat je zeker weet dat je de juiste artefactversie hebt.
Waarom dit type aanval zo effectief is
Deze incidenten passen in een bekend patroon binnen de software supply chain: iemand met rechten op een GitHub repository kan release-bestanden vervangen en daarbij dezelfde bestandsnamen gebruiken. Als bovendien release-immutability nog niet aan staat, kan het kwaad ook maandenlang door blijven lopen totdat een controlepartij het ontdekt.
OVHcloud heeft aangegeven dat de immutability-optie niet geactiveerd was. Daardoor kon de aanvaller direct bestaande release-assets aanpassen, zonder dat de normale CI/CD checks het blokkeerden. Inmiddels is die optie geactiveerd, zodat toekomstige releases beter beschermd zijn tegen dit type wissel.
Dit is vergelijkbaar met andere supply-chain incidenten waarbij de distributiekanalen of artefacts worden gemanipuleerd. Als je de bredere context wilt, lees ook: AOMEI Backupper supply chain backdoor: wat te doen.
Is er een link met bestaande malwarecampagnes?
OpenSourceMalware suggereert een relatie met de GlassWorm-campagne. De onderzoekers koppelen het gebruikte GitHub-account aan eerder gedwongen force-pushes in persoonlijke repositories in maart, waar ze loaders zagen met kenmerken die bij GlassWorm passen.
Het is volgens de onderzoekers een inference (dus geen hard bewijs in de vorm van een compleet gedocumenteerde keten), mede doordat er geen exemplaren van de oktober-binary bewaard bleven. Toch is de gedeelde infrastructuur (het account) voor hen een sterke aanwijzing.
Als je meer wilt over hoe incidenten rond softwaredistributie en supply-chain risico’s samenkomen, sluit dit ook aan bij eerdere meldingen over misbruik in installatiestromen en updates, zoals bij Plex2Shell: crypto miners via Plex-kwetsbaarheden.
Conclusie: handel nu, zelfs als je “niet zeker weet”
De gecompromitteerde OVHcloud CLI is een duidelijke waarschuwing dat aanvallen zich niet altijd richten op een kwetsbaarheid in runtime-code—maar op de distributie van tooling. Hoewel de gemanipuleerde releases slechts een beperkte tijd actief waren, konden slachtoffers precies in die window de verkeerde archieven binnenhalen.
Heb je OVHcloud CLI geïnstalleerd of geüpdatet tussen 12:47 en 14:21 UTC op één van de getroffen platformen, ga dan uit van blootstelling: roteer secrets, verwijder de verdachte versie en installeer v0.16.0. Met die volgorde beperk je de schade het snelst.
Bron: https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html
