Op 19 oktober 2026 kwam aan het licht dat hackers tijdens een kort tijdvak bestanden van de gecompromitteerde OVHcloud CLI op GitHub hebben vervangen. Het doel was niet alleen om een “programma te vermommen”, maar om informatie te stelen: de gemanipuleerde builds waren ontworpen om secrets op een schijf te verzamelen zodra iemand de CLI installeerde of update.
OVHcloud verwijderde de getroffen bestanden, publiceerde later een schone versie en benadrukt vooral één maatregel: roteer alle geheimen op systemen die mogelijk de aangepaste release hebben gedraaid.
Wat is er precies gebeurd met de OVHcloud CLI?
Volgens OVHcloud werd een GitHub-account van een contributor misbruikt om downloadarchieven te vervangen die aan bestaande releases van de OVHcloud command-line tool hingen. De aanvallers uploadden daarbij alternatieve buildbestanden onder dezelfde bestandsnamen op de releasepagina’s.
De omwisseling duurde niet lang. De kwaadaardige bestanden waren gedurende maximaal 94 minuten live, van 12:47 tot 14:21 UTC. In die periode bereikten de gemanipuleerde downloads vooral mensen die:
- de installscript-opdracht uitvoerden die de “laatste” releasearchieven ophaalt, of
- een archive downloadden van de GitHub releasepagina’s van de getroffen versies, of
- een CI-job of bouwstap draaiden die zonder hash-pinning de releasearchieven binnenhaalde, of
- de CLI’s upgradecommando gebruikten op systemen waar de tool al stond (binnen bepaalde versies en platforms).
Welke releases waren getroffen?
OVHcloud kwalificeert v0.11.0 t/m v0.15.0 als gecompromitteerd. v0.10.0 wordt door OVHcloud als schoon gezien. De latere v0.16.0 is de gepubliceerde herstelde versie.
De aanval richtte zich niet op alle platform-binaries. Sommige doelsets bleven ongemoeid, waaronder onder meer builds voor Linux i386, Windows i386, Windows arm64 en een WebAssembly-variant. Daarmee was het risico vooral gekoppeld aan specifieke besturingssystemen en architecturen.
Hoe weet je of jouw systeem geraakt is?
Het belangrijkste is het “venster” en de manier waarop je installeerde of update. Als je in de periode 12:47–14:21 UTC op een getroffen platform:
- het officiële installscript met curl … | sh draaide (dat verifieert niet op hashes), dan is de kans reëel dat je een gemanipuleerde archive installeerde.
- handmatig een archive van een van de vijf gecompromitteerde releases downloadde, dan kan je ook het aangepaste bestand hebben geïnstalleerd.
- een CI of buildstap gebruikte zonder een “pinned hash”, dan kan die stap de gemanipuleerde download hebben opgehaald.
- een upgrade uitvoerde vanuit bepaalde oudere versies (v0.12.0 t/m v0.14.0) op macOS of Linux waar de tool al aanwezig was, dan kon de CLI zichzelf bijwerken zonder hashcheck.
Volgens de berichtgeving waren sommige installroutes juist minder kwetsbaar. Homebrew zou in de beschreven periode de originele SHA-256’s hebben gepind; een mismatch had dan installatie moeten verhinderen. Ook gold dat wie vóór het venster installeerde en niet update tijdens die tijd, niet automatisch is blootgesteld.
Wat deed de gemanipuleerde build?
De aangepaste builds waren ontworpen om secrets op schijf te verzamelen van elke machine waarop de CLI werd uitgevoerd. OVHcloud specificeerde daarbij niet publiekelijk alle exacte bestandslocaties, maar de algemene verwachting is dat de tool bekende configuraties en gegevens leest waar API- of andere vertrouwelijke waarden opgeslagen kunnen staan.
OVHcloud stelt bovendien dat de CLI OVHcloud API-credentials opslaat in ~/.ovh.conf en kan lezen uit omgevingsvariabelen, zoals beschreven in de documentatie. Het advies van OVHcloud gaat echter verder dan alleen die configuratie: “alles wat als geheim kan worden beschouwd” op dezelfde machine moet worden geroteerd.
Waarom werd dit überhaupt mogelijk op GitHub?
In essentie gaat het om het risico van het wijzigen van bestanden die aan bestaande GitHub releases hangen. Wie schrijfrechten heeft in een repository (en dus bestanden bij releases kan vervangen), kan binnen bepaalde instellingen downloads onder dezelfde namen opnieuw uploaden zonder dat een andere download-URL verandert.
Een belangrijke factor: OVHcloud had de immutability-optie nog niet geactiveerd voor de betrokken releases. Toen die bescherming niet actief was, konden bestaande release-assets gewijzigd worden zonder dat de eigen CI/CD-pijplijn ingreep. OVHcloud geeft aan dat dit inmiddels is aangepast, zodat vergelijkbare wijzigingen bij nieuwe releases worden geblokkeerd.
Hoe kun je dit zo vroeg mogelijk detecteren?
In de berichtgeving werd een klant genoemd die de afwijkingen technisch terugvond. Die methode was gebaseerd op het analyseren van buildmetadata zonder de binair echt “uit te voeren”. Dat leverde indicatoren op zoals:
- een pseudoversie in de module-informatie (een teken dat het niet om een “echte” release-tagbuild ging),
- een commitrecord dat niet overeenkwam met de commit waar de versie-tag naar verwees, en
- een aanwezigheid van bepaalde buildflags die in de normale pipeline niet terugkwamen.
Er circuleerde bovendien advies om op bouwlabels zoals “+dirty” of specifieke buildmetadata te letten. Tegelijk is het gebruikelijk dat alleen OVHcloud en de volledige buildinformatie exact kunnen bevestigen welke artefacten precies zijn gemanipuleerd.
Wat moet je nu doen (praktische stappen)
OVHcloud’s kernadvies is helder: verander alle secrets die op de getroffen machines zijn opgeslagen. Omdat je niet met zekerheid weet wat er is gelezen of gekopieerd, is het veiliger om als “mogelijk blootgesteld” te behandelen.
1) Roteer alle geheimen op de betrokken systemen
Kun je niet met zekerheid uitsluiten dat je de gecompromitteerde build hebt gedraaid? Ga dan uit van blootstelling en roteer elk geheim dat vanaf die machine benaderbaar is. OVHcloud noemt daarbij alle secrets op disk. Onderzoekers adviseerden daarnaast om die rotatie bij voorkeur uit te voeren vanaf een andere machine.
2) Verwijder de oude CLI en installeer v0.16.0
Installeer vervolgens v0.16.0. OVHcloud geeft aan dat de release immutability is ingeschakeld voor die schone release, en dat GitHub de bestanden niet zomaar meer kan laten wijzigen. Let op: het roteren komt vóór het “repareren” van je software, omdat een al gekopieerde sleutel niet vanzelf wordt ingetrokken.
3) Controleer downloads met de juiste GitHub release verificatie
Controleer je download of de release-assets kloppen met de bijbehorende checks. In de berichtgeving wordt expliciet verwezen naar de GitHub-achtige verificatie via het commando gh release verify-asset voor v0.16.0, zoals GitHub dat documenteert.
Welke extra aandacht verdient je CI/CD?
Een terugkerend patroon bij supply-chain incidenten is dat automatische pipelines zonder hash-pinning precies doen wat een aanvaller nodig heeft: de “nieuwste” of geavanceerde download ophalen. Als jouw CI een archive ophaalt op basis van een release-URL zonder pinned hash, dan is het verstandig om nu direct:
- hashes te pinnen in scripts en CI-steps,
- installatiemodules te beperken tot expliciete versies in plaats van “laatst beschikbare”, en
- een mechanisme te bouwen om downloads te verifiëren vóór installatie.
Zo verklein je de kans dat een onverwachte wijziging in een releasepagina direct leidt tot het installeren van gemanipuleerde binaries.
Relatie met een bredere malwarecampagne
Onderzoekers koppelden de gebruikte aanvalleraccount aan GlassWorm, een campagne die code kan verstoppen in ogenschijnlijk onschuldige Unicode-tekens en vervolgstappen kan ophalen via memo-velden in transacties op het Solana-netwerk. Vier persoonlijke repositories van het account zouden force-pushed zijn met commitwijzigingen die zo’n loadercomponent toevoegde.
De onderzoekers geven aan dat het om een inferentie gaat: er is geen publiek geverifieerd bewijs dat de exacte October CLI-binary direct aan GlassWorm is gekoppeld, omdat er geen kopie van het gemanipuleerde binary-artefact publiek is bewaard.
Vergelijkbare incidenten: waarom dit jou kan raken
Supply-chain aanvallen raken niet alleen “eindgebruikers”, maar ook teams die tooling beheren, automatiseren en uitrollen. Als je in je omgeving vaker tools installeert via scripts of release-URL’s, dan is de kans groter dat een vergelijkbaar scenario ook bij jou kan landen.
Ter vergelijking van hoe supply-chain en geautomatiseerde installpaden misbruikt kunnen worden, kun je ook lezen over eerder gemelde incidenten met softwarecomponenten, zoals:
Conclusie
De gecompromitteerde OVHcloud CLI releases laten zien hoe snel een vertrouwd installpad kan veranderen in een route naar secret theft. Als je in het venster van 19 oktober 12:47–14:21 UTC een getroffen installatie- of updatepad gebruikte, behandel je systeem dan als mogelijk blootgesteld.
Roteer als eerste al je secrets, installeer daarna v0.16.0 en controleer de assets met verificatie. Daarmee beperk je de schade en voorkom je dat je omgeving opnieuw een gemanipuleerde versie binnenkrijgt.
Bron: https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html
