Octave Klaba, Verwaltungsratsvorsitzender und CEO von OVHcloud, machte den Vorfall in Beiträgen auf X öffentlich und forderte alle Nutzer, die die jüngste Version des Werkzeugs heruntergeladen hatten, auf, es „sehr schnell erneut zu aktualisieren" oder zu löschen. „Der Hacker hat das GitHub-Konto eines der Entwickler benutzt und eine Binärdatei hinzugefügt, deren Aufgabe es ist, Geheimnisse von der Festplatte abzugreifen", schrieb Klaba. „Die Qualität der Binärdatei ist schlecht, aber sie kann den ganzen Weg gehen. Wenn Sie betroffen sind, ändern Sie bitte alle Geheimnisse auf Ihrer Festplatte."
Nach der Aufarbeitung von OVHcloud fällt die Auswirkung auf die Lieferkette vergleichsweise gering aus: Die manipulierten Binärdateien standen lediglich eine Stunde und 33 Minuten zum Abruf bereit, wurden in dieser Zeit allerdings rund 250 Mal heruntergeladen.
Den Zugriff auf das Projekt ovhcloud-cli erlangten die Angreifer laut der Aufarbeitung über das kompromittierte GitHub-Konto eines OVHcloud-Entwicklers. Für kurze Zeit ersetzten sie die legitimen Releases durch manipulierte Versionen des Werkzeugs. Ein GitHub-Nutzer lud am Montag eine verseuchte Fassung herunter, bemerkte verdächtige Aktivitäten und meldete den Fall umgehend als GitHub-Issue an OVHcloud. Das Unternehmen untersuchte das Repository und entfernte die Schaddatei innerhalb von etwa 30 Minuten. Das Sicherheitsteam prüfte zudem sämtliche Repositorys des Unternehmens und stellte fest, dass kein weiteres betroffen war.
OVHcloud wies außerdem darauf hin, dass die zentrale CI/CD-Plattform für die Produktion intern auf einer privaten Git-Instanz betrieben wird und nicht bei GitHub liegt — sie war daher vom Angriff nicht betroffen.
Ermöglicht wurde der Lieferkettenangriff nach Angaben des Sicherheitsteams durch eine schlichte Fehlkonfiguration. „Das Hauptproblem war, dass das GitHub-Repository nicht angemessen konfiguriert war, um die Unveränderlichkeit von Releases sicherzustellen", heißt es in der Aufarbeitung — veröffentlichte Dateien konnten also nachträglich ausgetauscht werden. Die Fehlkonfiguration sei sofort korrigiert worden, das Repository sei nicht länger gefährdet; dieselbe Konfiguration sei auf alle Repositorys angewendet worden.
Zunächst war unklar, wie die Angreifer an das Entwicklerkonto gelangt waren. Der Sicherheitsforscher Paul McCarty verknüpfte den Angriff in einem Blogbeitrag auf der Threat-Intelligence-Plattform OpenSourceMalware mit den GlassWorm-Akteuren — über eine Solana-Wallet-Adresse, die bereits in früheren GlassWorm-Kampagnen zum Einsatz kam. McCarty untersuchte zudem das für den Zugriff genutzte Entwicklerkonto und kam zu dem Schluss, dass es seit sieben Monaten kompromittiert ist. „Seine öffentlichen Repositorys zeigen ein per Skript durchgeführtes Umschreiben der Historie am 5. März 2026 sowie einen versteckten preinstall.js-Loader, der zu einer zweiten Stufe entschlüsselt und dabei ein Solana-Memo als Dead Drop nutzt", schrieb er. „Die Wallet ist ein bekannter GlassWorm-Indikator, und die Amend-and-Force-Push-Technik passt zur ForceMemo-Kampagne."
In dieser früheren Kampagne infizierte GlassWorm Dutzende Extension-Pakete auf Open VSX, der quelloffenen Alternative zum Visual Studio Marketplace von Microsoft. Das Sicherheitsteam von OVHcloud fand später heraus, dass der betroffene Entwickler am 20. Oktober 2025 eine verseuchte Erweiterung auf einem privaten MacBook installiert hatte. Forscher des Sicherheitsanbieters Socket hatten im vergangenen Oktober exakt jene Erweiterungsversion markiert, die OVHcloud in seinem Bericht nennt: [email protected].
„Der Loader der Erweiterung verbirgt ausführbaren Code in unsichtbaren Unicode-Zeichen, fragt Solana-Transaktions-Memos ab, um eine entfernte Payload zu lokalisieren, und lädt diesen Code herunter und führt ihn aus", erklärte ein Sprecher des Socket Threat Research Team. „Sie verwendet außerdem dieselben Antwort-Header ivbase64 und secretkey, die wir in unserer Untersuchung zu den GlassWorm-Themes dokumentiert haben. Dieses Verhalten deckt sich mit den GlassWorm-Loadern, die wir analysiert haben."
OVHcloud schloss sich dieser Einordnung an und hielt in der Aufarbeitung fest, dass die Solana-Wallet-Adresse auf GlassWorm verweise. Socket schränkt allerdings ein: Die Adresse stimme zwar mit dem überein, was man in der früheren Open-VSX-Untersuchung beobachtet habe, die von Socket aufbewahrte Erweiterungsdatei enthalte jedoch eine andere Adresse. „Wir haben nicht festgestellt, ob die von OVHcloud genannte Adresse in einer späteren Payload-Stufe auftaucht, und wir haben die CLI-Binärdateien vom Oktober nicht unabhängig analysiert", so der Sprecher.
Unabhängig von der Zuschreibung betont das Socket Threat Research Team, dass ein privates Sicherheitsversäumnis zu unternehmensweiten Risiken führen könne. „Der Fall OVHcloud zeigt, wie eine Erweiterungsinfektion auf einem privaten Rechner dazu führen kann, dass Schadsoftware die Nutzer des Arbeitgebers erreicht", sagte der Sprecher. „Das Unternehmen erklärt, Quellcode und Build-Kette seien unberührt geblieben — dennoch ermöglichten gestohlene Zugangsdaten es Angreifern, die über die offiziellen Releases verteilten Binärdateien auszutauschen."
