XSS in SourceHut-Build-Logs ermöglichte die Übernahme von Konten

Ein Sicherheitsforscher hat eine Lücke offengelegt, über die ein präpariertes Build-Log SourceHut-Konten übernehmen konnte. Der Fehler steckte in ansi2html, einer Python-Bibliothek, die farbige Terminalausgabe in HTML umwandelt, und wird als CVE-2026-92973 geführt. Jedes Projekt, das nicht vertrauenswürdige Logs mit ansi2html in den Versionen 1.7.0 bis 1.9.3 darstellt, ist genauso betroffen.

SourceHut ist eine gehostete Software-Forge, ein Dienst für Git-Repositorys, Mailinglisten und Continuous Integration. Sein CI-Dienst builds.sr.ht führt Jobs aus und zeigt deren Logs im Browser. Der Forscher, der als Arusekk veröffentlicht, beschrieb den Angriff am 23. September 2026.

Wie ein Build-Log zum Angriff wurde

Der Angriff nutzte Cross-Site-Scripting, kurz XSS. Dabei bringt man eine Website dazu, JavaScript eines Angreifers im Browser eines Besuchers auszuführen, mit dessen angemeldeter Sitzung.

Terminals verstehen Escape-Sequenzen, versteckte Codes in der Textausgabe. Die meisten setzen Farben. Eine Art, OSC 8, macht aus einem Textstück einen anklickbaren Hyperlink. ansi2html übersetzt diese Codes in HTML, damit ein Log auf einer Webseite gleich aussieht.

Laut dem Bericht maskierte ansi2html das Linkziel in OSC-8-Sequenzen nicht korrekt. Ein Job konnte eine Sequenz ausgeben, deren "Link" aus dem HTML-Attribut ausbrach und neue hinzufügte, darunter einen Event-Handler, der Code ausführt. Wer die Log-Seite dieses Jobs öffnete, führte ihn aus.

Was ein Angreifer tun konnte

Das eingeschleuste Skript konnte das CSRF-Token der Seite lesen, schreibt der Forscher. Ein CSRF-Token ist das Geheimnis, mit dem eine Website bestätigt, dass eine Anfrage wirklich aus der eigenen Sitzung des Nutzers stammt. Damit konnte das Skript Build-Jobs im Namen des Opfers einreichen und an dessen Deploy-Keys gelangen, die Zugangsdaten, mit denen Jobs Code pushen oder Releases ausliefern.

Betroffene Software	Verwundbare Versionen
ansi2html	1.7.0 bis ausschließlich 1.9.4
builds.sr.ht	0.40.0 bis ausschließlich 0.105.1

Der Bericht nennt keine dokumentierte Ausnutzung in freier Wildbahn.

Der Zeitplan der Offenlegung

SourceHut reagierte schnell. Die Korrektur in der Upstream-Bibliothek dauerte einen Monat länger, und die öffentliche Offenlegung wartete, bis beide verfügbar waren.

Datum (2026)	Ereignis
1. August	Fehler gemeldet
4. August	Abhilfe auf builds.sr.ht ausgerollt
2. September	ansi2html 1.9.4 mit der Korrektur veröffentlicht
17. September	CVE-2026-92973 vergeben
23. September	Öffentlicher Bericht veröffentlicht

Die Release Notes zu ansi2html 1.9.4 auf GitHub führen die Korrektur als "osc8: ensure proper escaping", Pull Request 263. Arusekk schrieb den Patch, und Maintainer hartwork genehmigte ihn.

Warum ein Audit der Abhängigkeit nicht reichte

Der Forscher macht einen Punkt, der über diesen Fehler hinausgeht. Die Lücke steckt in Code, der sich von Release zu Release ändert, also kann eine einmalige Prüfung sie nicht erfassen. "Note how even carefully auditing ansi2html would not save SourceHut, unless redone on every bump", heißt es im Bericht.

Eine Abhängigkeit, die bei Ihrer Prüfung sicher war, kann später eine neue Funktion bekommen. Ein gewöhnliches Versions-Update bringt diese Funktion dann samt jedem Fehler darin direkt in Ihr Produkt.

SourceHut war dieses Jahr wegen seiner Beitragsregeln in den Nachrichten, darunter sein Verbot von LLM-gestütztem Code und Tickets. Diese Offenlegung erinnert daran, dass auch der eigene Code des Dienstes eine Lieferkette hat wie der aller anderen.

Was das für Entwickler bedeutet

Aktualisieren Sie ansi2html überall, wo Sie es nutzen, auf 1.9.4 oder neuer. Durchsuchen Sie Ihre Lockfiles und Container-Images, nicht nur Ihre direkten Abhängigkeiten, denn die Bibliothek kommt oft als Abhängigkeit eines Test- oder CI-Werkzeugs mit. pip show ansi2html in jeder Umgebung zeigt Ihnen die Version, die Sie tatsächlich ausliefern.

Behandeln Sie Build-Ausgabe als feindliche Eingabe. Ein CI-Log enthält, was auch immer der Code eines Pull Requests ausgeben wollte. Wenn Ihr eigenes Dashboard Logs als HTML darstellt, prüfen Sie, dass jeder Attributwert maskiert wird. Ergänzen Sie eine Content Security Policy, die Inline-Event-Handler blockiert, damit eine vergessene Maskierung nicht zur Codeausführung wird.

Prüfen Sie, was eine gestohlene Sitzung erreichen könnte. Hier gab ein einziger Seitenaufruf die Macht preis, Jobs zu starten und Deploy-Keys zu lesen. Beschränken Sie Deploy-Keys auf einzelne Repositorys und rotieren Sie alle, die Sie nicht zuordnen können.

Lesen Sie schließlich Changelogs erneut, wenn eine Render- oder Parser-Bibliothek eine Funktion hinzufügt. Neue Unterstützung für Escape-Sequenzen, neues Markup oder neue Link-Behandlung sind genau die Änderungen, die einen zweiten Blick verdienen.