LONDON (IT BOLTWISE) – OVHcloud berichtet, dass Angreifer fünf bestehende Release-Archive seiner CLI per kompromittiertem GitHub-Zugang austauschten. In einem Zeitfenster von bis zu 94 Minuten fanden Installationen oder Updates auf macOS, Linux und Windows die manipulierten Dateien über einen Download-Pfad ohne Hash-Prüfung. Betroffen sind vor allem Nutzer, die das offizielle Install-Skript nutzten oder die Archive aus den entsprechenden Release-Seiten bezogen. OVHcloud veröffentlichte anschließend eine unveränderliche v0.16.0-Version und rät, alle gespeicherten Secrets zu rotieren.
Ein scheinbar kleiner Engpass in der Software-Bereitstellung reichte offenbar aus, um eine klassische Supply-Chain-Gefahr sichtbar zu machen: Am 19. Oktober sollen Angreifer über ein gekapertes GitHub-Konto die Download-Archive von fünf bestehenden Releases der OVHcloud-CLI ersetzt haben. Laut Unternehmensangaben ging das Ereignis auf GitHub für bis zu 94 Minuten online – von 12:47 bis 14:21 UTC – und erreichte nur diejenigen, die in genau diesem Zeitfenster installiert oder aktualisiert haben. Der Kernpunkt liegt weniger in der Manipulation selbst, sondern im Zusammenspiel aus Release-Handling und fehlender Hash-Absicherung im typischen Installationspfad.
Technisch betrachtet wurden keine neuen Tags oder ein veränderter Source-Stand benötigt, sondern ein Austausch von bereits veröffentlichten Artefakten. OVHcloud schreibt, dass die ursprünglichen Release-Tags, der Release-Source-Code und auch die Build-Pipeline selbst unangetastet geblieben seien; der Schaden sei vielmehr durch ein „plain go build“ eines späteren Commits entstanden, der dann direkt auf die vorhandenen Release-Dateien geladen wurde. Besonders kritisch: Für macOS und Linux auf x86_64 sowie arm64 und für Windows x86_64 wurden die Archive und zudem die checksums.txt so nachgezogen, dass die veröffentlichten Hashwerte zum kompromittierten Stand passten. Dadurch konnten Nutzer, die ihre Integrität nur anhand der veröffentlichten Checksums erwarteten, zunächst keine Auffälligkeit erkennen.
Das Zeitfenster begrenzt zwar den Kreis der betroffenen Systeme, macht aber deutlich, wie schnell sich ein solcher Austausch in der Praxis verbreiten kann. Auf v0.15.0 ersetzten die Angreifer sechs Dateien: je ein Archiv für macOS x86_64 und arm64, für Linux x86_64 und arm64, das Windows-x86_64-Archiv sowie die checksums.txt-Datei. Gleichzeitig verschwanden die gleichen sechs Dateien auch in dem Bereich von v0.11.0 bis v0.14.0, während die Linux-i386-, Windows-i386-, Windows-arm64- und WebAssembly-Varianten auf den Releases offenbar unangetastet blieben. OVHcloud führt v0.11.0 bis v0.15.0 als kompromittiert an, v0.10.0 gilt als sauber; wer vor 12:47 UTC installiert und nicht im betroffenen Zeitraum aktualisiert hatte, gilt als weitgehend aus dem Risiko heraus.
Für die Frage „Bin ich betroffen?“ ist entscheidend, welchen Update- oder Installationsweg man gewählt hat. OVHcloud nennt mehrere Pfade, die in der betroffenen Zeit zu einem „swapped file“ geführt haben sollen, darunter das offizielle Install-Skript („curl -fsSL …/install.sh | sh“), das laut Beschreibung stets das neueste Release-Archiv herunterlädt und dabei nie einen Hash prüft. Gleiches gilt laut den Angaben für direkte Downloads von den GitHub-Release-Seiten, ebenso für CI- oder Build-Schritte, die das Release-Archiv über den Download-URL holen, ohne den Hash zu pinnen. Wer dagegen mit einem Homebrew-Setup arbeitete, hatte in dieser Phase offenbar eine technische Bremse: Die entsprechenden casks hätten den SHA-256-Stand geprüft, wodurch inkonsistente Downloads scheitern müssten. Auch „go install“ und ein Build aus dem Source-Stand sollten laut Darstellung weniger anfällig gewesen sein, weil das Tag v0.15.0 weiterhin auf den September-Commit zeigt, der für die saubere Version steht.
Für Incident-Responder liefert die Dokumentation zudem ein konkretes forensisches Raster, das ohne Ausführen des mutmaßlichen Binärmaterials auskommt. In einem Fall, der den Austausch aufgedeckt haben soll, wurde die Build-Information des v0.15.0-Linux-arm64-Binaries mit „go version -m“ ausgelesen. Entscheidend seien drei Signale: Erstens weist die Modulzeile auf eine pseudo-Version hin, die zu einem Build aus einem ungetaggten Commit passt (Go kennzeichnet Builds aus solchen Zuständen typischerweise mit einer „+dirty“- bzw. pseudo-version-typischen Zeichenfolge); zweitens soll das eingebettete Commit-Matching nicht mit dem Commit übereinstimmen, auf den der Release-Tag zeigt; drittens soll eine „-ldflags“-Zeile vorhanden sein, die OVHcloud zufolge in sauberen Releases nicht auftaucht, weil die Release-Pipeline Version-Flags anders einbettet. Wichtig ist dabei auch die Einordnung zu „+dirty“: Ein Kriterium allein sei nicht ausreichend, weil auch legitime Builds strukturbedingt solche Marker tragen können – in den beschriebenen Tests auf dem sauberen v0.16.0-Binary wurden jedoch typische Merkmale wie „v0.16.0+dirty“ und „vcs.modified=true“ mit einer erwartbaren Versionserzeugung beobachtet.
Was die Reaktion und die Prävention betrifft, setzt OVHcloud nach eigenen Angaben gleich mehrere Stellschrauben: Die kompromittierten Archive wurden gelöscht, und am Abend folgte v0.16.0 als immutable release, bei dem GitHub die Dateien laut Darstellung nicht mehr austauschbar hält. Zusätzlich steht in den Empfehlungen an betroffene Kunden an erster Stelle die Rotierung aller Secrets, die auf dem System hätten ausgelesen werden können – OVHcloud nennt hierfür unter anderem OVH-API-Zugangsdaten aus „~/.ovh.conf“ sowie Umgebungsvariablen, und der Rat zielt explizit nicht nur auf diese eine Konfigurationsquelle. Der Grund ist simpel: Ein Update ersetzt nicht automatisch schon kopierte Daten. Auch OpenSourceMalware empfiehlt die Rotierung möglichst von einer anderen Maschine. Als praktische Absicherung rät OVHcloud außerdem, heruntergeladene Archive gegen den immutability-festen Stand zu verifizieren – etwa über „gh release verify-asset v0.16.0 FILE“, wie es bei GitHub beschrieben ist.
Der zweite Teil der Story erklärt, warum das Problem überhaupt so lange unbemerkt bleiben konnte: Die Release-Workflow-Pipeline soll zwischen dem 16. Oktober und dem Tag-Push für v0.16.0 keine relevanten Läufe durchgeführt haben. Laut Klaba habe das zugrundeliegende immutability-Feature für bestehende Releases nicht aktiviert gewesen; wer mit den passenden Berechtigungen auf GitHub Zugriff auf Release-Anhänge habe, könne demnach bestehende Artefakte ersetzen, ohne dass die CI/CD-Pipeline „dagegenläuft“. Erst ein Kunde mit einem CI-Job, der den SHA-256 der Linux-arm64-Datei pinnt, habe den Austausch bemerkt und die Sache anschließend über ein öffentliches Issue gemeldet; danach seien die Swap-Dateien zügig entfernt und v0.16.0 mit signiertem Tag nachgeschoben worden. Offen bleibt zudem, wie genau die kompromittierte Build-Umgebung und die Kontoübernahme zustande kamen und welche Details über Zielsysteme oder Downloads vorliegen.
Besonders aufmerksam macht zum Schluss die Frage, ob es sich nur um einen isolierten Supply-Chain-Vorfall handelt oder Teil einer breiteren Kampagne. Laut OpenSourceMalware wird die Kontoübernahme mit GlassWorm in Verbindung gebracht, einer Kampagne, die Code per unsichtbarer Unicode-Zeichen „versteckt“ und die nächste Stufe aus einer Solana-Transaktion über ein ForceMemo-Mechanismus nachlädt. Die Forscher ordnen dem Konto force-pushed Änderungen in mehreren persönlichen Repositories zu, bei denen ein Loader-Typ ergänzt worden sein soll. Gleichzeitig betonen sie, es handele sich um eine „Inference“: Ein eindeutiger Bindeglied-Beweis zwischen dem Oktober-Build und GlassWorm habe sich aus gespeicherten Kopien nicht ableiten lassen, weil keine vollständige Instanz des betroffenen Binärmaterials für die Analyse konserviert worden sei. Für Organisationen ist die Lehre dennoch klar: Selbst wenn man „nur“ Artefakte aus Releases bezieht, sollte man Integrität standardmäßig durch gepinnte Hashes oder signierte Verifikation erzwingen – und Release-Mutability konsequent aktivieren, damit ein einzelner kompromittierter GitHub-Zugang nicht direkt in produktive Umgebungen hineinwirkt.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "OVHcloud-CLI kompromittiert: 94 Minuten Malware über Release-Archive verteilt" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "OVHcloud-CLI kompromittiert: 94 Minuten Malware über Release-Archive verteilt" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »OVHcloud-CLI kompromittiert: 94 Minuten Malware über Release-Archive verteilt« bei Google Deutschland suchen, bei Bing oder Google News!