Ein Angreifer hat über ein gekapertes GitHub-Konto fünf Releases des OVHcloud-CLI mit einem Infostealer ausgetauscht. Die Fassung v0.10.0 und das neue v0.16.0 sind sauber. Betroffen sind Installationen per Skript, Brew oder Tarball auf macOS, Linux und Windows. Wer eine der Versionen genutzt hat, sollte alle Geheimnisse auf dem Rechner ersetzen.
Fünf Versionen des OVHcloud-CLI enthielten am 19. Oktober 2026 Schadcode, der Geheimnisse vom Rechner holt. Wer eine davon installiert hat, muss alle Zugangsdaten auf dem Gerät wechseln.
Das Wichtigste in Kürze
- Fünf Versionen waren manipuliert. Betroffen sind v0.11.0 bis v0.15.0, die Fassungen v0.10.0 und v0.16.0 sind sauber.
- Der Angriff lief über ein gekapertes GitHub-Konto. Die Pipelines von OVHcloud blieben unberührt, der Quellcode ebenfalls.
- Betroffen sind Downloads von GitHub. Wer aus dem Quellcode gebaut oder das Docker-Image genutzt hat, war nicht betroffen.
- Alle Geheimnisse auf dem Rechner sind zu ersetzen. Das gilt für jede Maschine, auf der eine der Versionen lief.
Was passiert ist
OVHcloud ist ein französischer Anbieter für Cloud und Webhosting. Das Unternehmen warnte seine Kundschaft vor einem manipulierten Kommandozeilenwerkzeug. Firmenchef Octave Klaba machte den Vorfall auf X publik. Help Net Security hat die Meldung am 21. Oktober 2026 erstmals veröffentlicht. Die Quelle nennt kein späteres Update. Der letzte Stand ist daher der 21. Oktober 2026.
Die manipulierte Fassung ging am 19. Oktober um 14.47 Uhr online. Um 16.21 Uhr wurde sie gesperrt. Ein Kunde hatte das Problem gemeldet. Klaba dankte ihm dafür öffentlich.
Der Angreifer nutzte das GitHub-Konto eines Entwicklers. Er lud eine Binärdatei hoch, die Geheimnisse von der Festplatte abgreift. Klaba beurteilte ihre Qualität als schlecht. Sie könne aber trotzdem weit kommen.
So kam der Schadcode ins OVHcloud-CLI
Dabei griff der Angreifer nicht die Build-Kette an. Laut der Analyse von OpenSourceMalware entstand die Schaddatei auf einer Workstation. Sie ersetzte die echten Dateien in fünf bestehenden GitHub-Releases. Die Forscher nennen das einen Angriff durch Austausch von Release-Dateien.
Klaba nannte in einem zweiten Beitrag die Ursache. Die Option für unveränderliche Releases war auf GitHub nicht aktiv. Wer die nötigen Rechte hatte, konnte bestehende Releases direkt ändern. Die CI/CD-Prüfungen sahen davon nichts. Dazu zählen Unit-Tests, Funktionstests und die Suche nach bekannten Schwachstellen. OVHcloud hat die Option nun eingeschaltet und den Vorfall als abgeschlossen erklärt.
| Kennzahl | Wert | Bedeutung |
|---|---|---|
| Betroffene Versionen | v0.11.0 bis v0.15.0 | Fünf Releases wurden ausgetauscht |
| Sauberer Vorgänger | v0.10.0 | Diese Fassung blieb unverändert |
| Bereinigte Fassung | v0.16.0 | Sie ersetzt die manipulierten Dateien |
| Zeitfenster | 19. Oktober, 14.47 bis 16.21 Uhr | Danach wurde die Fassung gesperrt |
Wer betroffen ist und was jetzt zu tun ist
Nach Angaben der Forscher traf es Nutzer auf macOS, Linux (x86_64 und arm64) und Windows (x86_64). Entscheidend war der Installationsweg. Betroffen waren:
- Installationen mit dem Skript install.sh
- Installationen per Brew über den Tap von OVH
- Tarballs, die in dem Zeitfenster von GitHub kamen
Sicher blieben alle, die gegen den Go-Modul-Proxy geprüft oder aus dem Quellcode gebaut haben. Auch das Docker-Image war nicht betroffen.
Daher gilt für alle anderen: Prüft die installierte Version. Löscht oder aktualisiert sie auf v0.16.0. Wechselt danach jedes Geheimnis, das auf dem Rechner lag. Das umfasst Tokens, Schlüssel und Passwörter. Die Quelle gibt diesen Rat selbst.
Hintergrund zum Angreifer
OpenSourceMalware ordnet den Angriff der Gruppe GlassWorm zu. Sie zielt seit mindestens Anfang 2025 auf Entwickler. Dort liegen Zugänge zu Quellcode, Cloud, CI/CD und Paketquellen. Im Mai 2026 legten CrowdStrike, Google und die Shadowserver Foundation das Botnetz der Gruppe gleichzeitig lahm.
Das gekaperte Konto war laut den Forschern etwa sieben Monate kompromittiert. Im März 2026 wurde der Verlauf mehrerer privater Repositories umgeschrieben. Dort lag ein versteckter Lader, der seine nächste Stufe über eine Transaktion auf der Solana-Blockchain holt. Die genutzte Wallet gilt als bekannter GlassWorm-Hinweis. Die Verbindung zwischen dem März-Fall und dem Angriff im Oktober ist laut den Analysten ihre eigene Schlussfolgerung.
Einordnung: Was das für Admins und Entwickler heisst
Wer das OVHcloud-CLI in Schweizer Teams nutzt, prüft jetzt die installierte Version. Handeln müssen alle, die zwischen dem 19. Oktober und der Sperrung Version v0.11.0 bis v0.15.0 per Skript, Brew oder Tarball geladen haben. Das Wechseln der Geheimnisse kostet Zeit, schützt aber vor Missbrauch der abgeflossenen Daten. Zudem lohnt der Blick auf die eigenen Repositories. Die Option für unveränderliche Releases verhindert, dass bestehende Dateien nachträglich ausgetauscht werden. Die Quelle nennt sie als Ursache für die Lücke.
Fazit
Du weisst nun, welche Versionen betroffen sind und welche Installationswege es traf. Prüfe als Nächstes die Version auf allen Rechnern. Tausche bei Treffern jedes Geheimnis aus und lade v0.16.0. Schalte auf deinen eigenen GitHub-Releases die unveränderlichen Releases ein.
Quellen: Help Net Security. Foto: cookieone / Pixabay. Stand: 21. Oktober 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.