OVHcloud meldt dat een aanvaller via een gecompromitteerde ontwikkelaars-GitHubaccount een kwaadaardige component heeft weten te plaatsen in de officiële OVHcloud CLI. Het doel: een binary die geheimen van de schijf kan ophalen. Voor organisaties die de CLI gebruiken voor beheer is dit extra relevant, omdat de impact zich richt op het stelen van credentials of andere gevoelige data op werkstations.
In dit artikel zetten we op een rij welke versies getroffen zijn, wie mogelijk risico loopt en welke stappen je snel kunt nemen om de schade te beperken.
Wat is er gebeurd met de gecompromitteerde OVHcloud CLI?
Volgens OVHcloud is de supply-chain aanval ontstaan op 19 oktober. Een aanvaller gebruikte het GitHub-account van een (legitieme) ontwikkelaar van OVHcloud om een binair bestand toe te voegen aan releases van de officiële CLI. Die binairy had als functie om secrets van de lokale schijf te verzamelen.
De kwaadwillende versie zag er volgens OVHcloud uit als een “inferieure” implementatie, maar de functionaliteit kon volgens de melding toch doorlopen tot het geheimen kan ophalen. OVHcloud geeft bovendien aan dat de CI/CD-pijplijnen niet direct getroffen zijn: de oorzaak lag in het feit dat een GitHub “release immutability”-optie niet was ingeschakeld.
Welke OVHcloud CLI-versies zijn gecompromitteerd?
OVHcloud noemt deze releases als gecompromitteerd: v0.11.0 t/m v0.15.0. De versies 0.10.0 en de recent uitgebrachte v0.16.0 zijn volgens de melding niet geraakt.
Daarnaast lijkt de aanval beperkt tot de meest gebruikte platformvarianten. Onderzoekers verwachten dat dit vooral past bij credential harvesting op developer- en operations-werkstations, omdat je dan snel aan relevante inloggegevens kunt komen.
Wanneer was het probleem actief?
OVHcloud stelt dat de gecompromitteerde releases rond 14:47 (Parijs-tijd) opdoken en dat ze weer werden geblokkeerd op 16:21, nadat een klant het probleem had gemeld. Een openbare melding op GitHub werd bovendien gedaan nadat een geautomatiseerde hashcontrole faalde.
De onderzoekers geven aan dat het incident in totaal ongeveer 94 minuten duurde voor systemen die via distributiekanalen hun updates binnenhaalden.
Hoe werden systemen geraakt?
Volgens de informatie uit de melding zijn gebruikers die tijdens het actieve tijdvak updates/installs deden via specifieke distributiewegen mogelijk geraakt. Denk aan:
- installatie of update op macOS;
- installatie of update op 64-bit Linux;
- installatie of update op Windows x86_64;
- via het officiële install-script;
- via Homebrew;
- of via een directe GitHub-download.
Niet getroffen volgens OVHcloud/berichtgeving zijn gebruikers die de CLI zelf vanuit bron codeerden, die de Go install command gebruikten, of die de officiële Docker image inzetten.
Waarom kon dit zo doorwerken? (release immutability)
Een cruciaal inzicht uit de melding is dat GitHub’s optie voor release immutability niet aanstond. Daardoor konden gebruikers met voldoende permissies bestaande releases direct aanpassen, zonder dat de gebruikelijke checks uit de CI/CD-keten “er bovenop” zaten.
OVHcloud zegt dat deze optie inmiddels is ingeschakeld. Voor veel teams is dit een belangrijke les: zelfs als je CI/CD niet wordt beïnvloed, kan een zwakke plek in releasebeheer alsnog leiden tot schadelijke binaries in officiële artefacten.
Wat was de mogelijke volgende stap van de aanvaller?
Onderzoekers beschrijven dat de aangeleverde loader in een volgende fase de Solana blockchain bevraagt om de locatie van een verdere payload te bepalen. Daarbij wordt een wallet gebruikt die eerder bekend stond als indicator (gekoppeld aan GlassWorm).
Belangrijk: OVHcloud noemt in de eigen statements niet expliciet die koppeling met GlassWorm. Bovendien kunnen onderzoekers niet met zekerheid bevestigen of dezelfde actor verantwoordelijk was voor zowel een eerdere (maart 2026) account-compromittering als de aanval van oktober. Ze formuleren dit als een aanname.
Wat betekent dit voor jouw team? Praktische acties
Of je direct risico hebt, hangt af van welke versie je hebt geïnstalleerd en hoe je dat deed. Omdat het doel gericht is op het ophalen van secrets, is het verstandig om het incident te behandelen alsof gevoelige data mogelijk is benaderd.
1) Controleer je OVHcloud CLI-versie en installatieweg
Ga na welke release je gebruikt. Als je in het bereik v0.11.0 t/m v0.15.0 zit, is dat een directe aanwijzing dat je actie moet nemen. Let ook op het pad: installeer je via het officiële script, Homebrew of een GitHub-download, dan is de kans groter dat je tijdens de vensterperiode een aangepaste release hebt binnengekregen.
2) Werk direct bij naar v0.16.0
Voor getroffen gebruikers is de eenvoudigste herstelroute: update naar v0.16.0, die volgens OVHcloud schoon is. Als je strict wilt zijn: valideer ook dat je update echt de bedoelde release is (bijvoorbeeld via je eigen proces voor versie- en artefactcontrole).
3) Denk aan credential hygiene en monitoring
Omdat het incident expliciet gericht lijkt op secret stealing, is het verstandig om inloggegevens die op systemen met de CLI beschikbaar waren te beoordelen. Denk aan het resetten van relevante tokens/wachtwoorden en het controleren van verdachte activiteiten (zoals onbekende sessies of aanmaak van authenticatiegegevens).
Hoe je dit gestructureerd aanpakt, kun je ook vergelijken met bekende incidentrespons-werkwijzen. Als je wilt focussen op het sneller terugbrengen van risico na een beveiligingsgebeurtenis, kan dit overzicht helpen: aanpak bij kritieke RCE-lekken: zo pak je het praktisch aan.
4) Voorkom herhaling met release governance
Het kernpunt uit de OVHcloud-melding is release governance: zorg dat “immutable” releasebescherming is ingesteld waar je die kunt toepassen. Daarnaast helpt het als je release-artefacten volgt met checks die niet alleen op CI/CD vertrouwen.
Supply-chain risico’s: les voor meer dan één tool
Dit incident laat opnieuw zien dat supply-chain aanvallen niet per se via kwetsbaarheid in de runtime plaatsvinden, maar via de aanlevering van software: officiële builds, releases en distributiekanalen. Het feit dat een kwaadwillende binary in bestaande releases kon worden opgenomen (door het ontbreken van immutable release checks) maakt het scenario realistisch voor elke organisatie die afhankelijk is van externe CLI’s en tooling.
Ook elders zie je dit terug in andere campagnes en misbruikscenario’s. Als je meer context wilt op hoe supply-chain-issues in breder cyberbeeld passen, is dit gerelateerd: AOMEI Backupper-compromis via short-burst supply chain.
Conclusie
De gecompromitteerde OVHcloud CLI is een supply-chain incident waarbij een aanvaller via een GitHub-account schadelijke binaries heeft toegevoegd aan officiële releases. Concreet zijn de versies v0.11.0 t/m v0.15.0 geraakt; 0.10.0 en v0.16.0 zijn volgens OVHcloud schoon. Gebruikers die tijdens het korte venster installeerden via het install-script, Homebrew of GitHub-downloads lopen de meeste kans.
De belangrijkste acties: controleer je versie, update naar v0.16.0 en neem maatregelen rond credential hygiene en monitoring. Zo verklein je de kans dat eventuele gestolen secrets ook daadwerkelijk misbruikt worden.
Bron: https://www.securityweek.com/hijacked-developer-account-used-to-plant-stealer-in-ovhcloud-cli/
1 reactie