26 bestätigte Schwachstellen in einer Codebasis, deren Wurzeln bis 2001 zurückreichen. Das ist die Bilanz eines Audits, das das Sicherheitsunternehmen Hacktron auf GNU Savannah durchgeführt hat. Für sich genommen eine Zahl unter vielen. Unbequem wird sie erst, wenn man weiß, was auf diesem Server liegt: die Repositories von Bash, Coreutils und Hunderten weiteren GNU-Projekten, dazu die Konten und SSH-Schlüssel der Menschen, die dort schreiben dürfen.
Wer auf einem Linux-Rechner ein Kommando wie ls, cp oder rm aufruft, benutzt Code, der über solche Forge-Server seinen Weg in die Distributionen findet. Die xz-Backdoor hat 2024 gezeigt, was ein einziger kompromittierter Punkt in dieser Kette anrichten kann. GNU Savannah ist die glimpfliche Variante derselben Geschichte: Diesmal standen die, die die Lücke fanden, auf der Seite der Verteidigung.
Um zu verstehen, was schiefging, hilft ein Bild. Ein Pförtner liest die Namen auf dem Anmeldeformular laut vor – und unterscheidet dabei nicht, ob dort ein Name steht oder eine Anweisung. So arbeitet eine Shell. Wer ihr einen Text gibt, gibt ihr keinen Inhalt, sondern einen Befehl. In Savane liegt zwischen beidem nur ein Eingabefeld.
Was GNU Savannah für die freie Software bedeutet
GNU Savannah ist die Hosting-Plattform der Free Software Foundation und eine der ältesten noch aktiven Adressen der Freie-Software-Welt. Dort liegen die Repositories von Bash und Coreutils, also der Werkzeuge, ohne die kein Linux-System startet, dazu Hunderte kleinere GNU-Projekte. Wer dort pushen darf, entscheidet über Code, der später in Debian, Fedora, Ubuntu und zahllosen anderen Distributionen landet.
Betrieben wird das von einer Handvoll Freiwilliger und FSF-Mitarbeitern, mit einem Budget, das man freundlich als knapp bezeichnen kann. Ein großes Haus mit vielen Türen, in dem der Hausmeister nebenbei noch drei andere Häuser versorgt. Jede Tür hat ein eigenes Schloss, aber am Ende hängen alle Schlüssel an einem Ring, und der liegt in einer Schublade im Erdgeschoss.
Hinter Savannah steckt Savane, eine in PHP geschriebene Anwendung, die selbst freie Software ist und deren Code bis auf SourceForge im Jahr 2001 zurückgeht. Das Team von Hacktron nahm sich diesen Code vor, weil man ihn lesen und prüfen kann, ohne jemanden um Erlaubnis zu bitten. Was dabei herauskam, nennen die Forscher den wirkungsvollsten Fehler, den sie bisher gefunden haben.
Shell Injection über die E-Mail-Adresse: der Fehler im GPG-Test
Die Lücke beginnt beim E-Mail-Feld der Registrierung. Savane prüft Adressen mit einem Validator in frontend/php/include/account.php, Zeile 275. Dieser Validator akzeptiert Dot-Atom-Adressen und damit auch Zeichen wie Backticks, Dollarzeichen, geschweifte Klammern, Schrägstriche und Pipe. Ein großer Teil davon ist im lokalen Teil einer Adresse laut RFC tatsächlich zulässig – die Prüfung war formal korrekt und trotzdem gefährlich.
Die Forscher registrierten sich mit einer Adresse der Form a`touch${IFS}/tmp/savane-rce-proof`@attacker.example. Entscheidend ist nicht die Validierung, sondern was später mit der Adresse passiert. Jeder angemeldete Nutzer kann für sein Konto einen GPG-Schlüssel hinterlegen und über den Knopf „Test GPG keys“ prüfen lassen; einer dieser Tests listet die Fingerabdrücke zur hinterlegten Adresse auf.
In frontend/php/include/gpg.php wird die Adresse unverändert an eine Optionszeile gehängt, diese Zeile in einen Befehlsstring geschrieben und der String an proc_open() übergeben. Bei einem String übergibt PHP die Ausführung an /bin/sh, und die Shell kennt keinen Unterschied zwischen einem Argument und einer Anweisung. Sie sieht die Backticks, führt den Inhalt dazwischen aus und startet gpg erst danach. Das ${IFS} steht dort, weil der Validator Leerzeichen ablehnt und die Shell es durch eines ersetzt.
Der Ablauf ist banal: mit der präparierten Adresse registrieren oder die Adresse eines bestehenden Kontos ändern, die Seite /my/admin/change.php?item=gpgkey öffnen, irgendeinen GPG-Schlüssel einfügen und den Test auslösen. Der eingebettete Befehl läuft auf dem Server mit den Rechten des Web-Server-Benutzers. Betroffen war Savane 3.17-c369 vom 7. März 2026, auf savannah.gnu.org wie auf savannah.nongnu.org. Zwischen dem Release und dem Bericht lagen rund zwei Monate.
Vom Webzugang zum Superuser und zur Aussicht auf das Bash-Repository
Aus der Shell Injection war eine Remote Code Execution geworden, und die Forscher wollten wissen, wie weit sie trägt. Sie tauschten den harmlosen touch-Befehl gegen eine Reverse Shell und landeten als Web-Server-Benutzer auf dem Backend. Von dort mussten sie nichts knacken: Die Konfiguration von Savane enthält die Zugangsdaten zur Datenbank im Klartext, weil sie dort liegen muss. Über diese Verbindung setzten sie das Superuser-Flag auf ihr eigenes Konto und luden die Seite neu.
Superuser sehen in der Seitenleiste ein Feld „Become this user“, mit dem sie sich ohne Passwort in jedes beliebige Konto verwandeln können. Die Forscher trugen dort den Namen chet ein. Chet Ramey ist der Maintainer von Bash, und die Seite, die sich öffnete, war seine Seite für autorisierte SSH-Schlüssel. Genau diese Einträge entscheiden bei Savannah darüber, wer in ein Repository pushen darf.
Die Forscher bestätigten, dass das Formular Änderungen annimmt, und hörten dann auf. Sie haben keinen Schlüssel hinterlegt und das Repository nicht angefasst. Für die Bewertung ist dieser Verzicht wichtig, an der Aussage ändert er nichts: Ein Angreifer an dieser Stelle hätte einen Commit im Namen von Chet Ramey in das Upstream-Repository von Bash schieben können. Unbefugter Zugriff auf das Bash-Repository war damit kein theoretisches Szenario, sondern ein Formularfeld. Dasselbe hätte Coreutils oder jedes andere Projekt auf Savannah getroffen.
Root über einen Kernel-Fehler und der Zugang zum GNU-Backup-Server
Der Webzugriff war unprivilegiert, der Weg nach oben trotzdem offen. Savannah läuft auf Trisquel GNU/Linux 11 mit einem linux-libre-Kernel aus dem 5.15-LTS-Zweig von Ubuntu 22.04. Dieser Kernel war im Mai 2026 noch von GameOver(lay) betroffen, zwei OverlayFS-Fehlern aus dem Jahr 2023, bekannt als CVE-2023-2640 und CVE-2023-32629.
Canonical hatte die Zweige 5.19 und 6.2 damals zeitnah gepatcht, den 5.15er erst mit USN-8255-1 am 7. Mai 2026 – vier Tage vor dem Bericht der Forscher. Der öffentliche Exploit funktionierte beim ersten Versuch und verschaffte Root auf dem Savannah-Backend. Als Root fanden die Forscher einen Schlüssel, mit dem sie sich als Benutzer gnubackup auf einem GNU-Backup-Host anmelden konnten.
Damit hatten sie Root auf der Forge, Zugriff auf deren Sicherungen und die Möglichkeit, sich als jeder Maintainer auszugeben. Sie brachen die Erkundung ab und schrieben den Bericht. Ein Backup-Server ist kein Nebenschauplatz: Dort liegen Kopien von genau dem, was der Hauptserver schützen soll.
26 Befunde: was der vollständige Audit von Savane zutage brachte
Nach dem ersten Bericht ließen die Forscher ihr Werkzeug weiterlaufen und schickten dem FSF die restlichen Ergebnisse. 33 Meldungen kamen zusammen, sieben erwiesen sich als Fehlalarm und wurden verworfen. Übrig blieben 26 bestätigte Schwachstellen – zwei kritische, sechs hohe, sechzehn mittlere und zwei niedrige, jeweils mit Dateipfad, Zeilennummer und Reproduktionsschritten.
Der zweite kritische Befund war eine Umgehung der Rechteprüfung in der siteweiten Admin-Konfiguration, in siteadmin/triggercreation.php. Dazu kamen mehrere Rechtefehler, die im Alltag einer Forge unangenehm werden: Jedes Gruppenmitglied konnte die Mailinglisten seiner Gruppe löschen, jeder Nutzer konnte die Benachrichtigungsadressen beliebiger Gruppen ändern, Gruppenmitglieder konnten die Admin-Passwörter der Mailinglisten zurücksetzen.
Außerdem: eine private Dateiablage, die einem Parameter aus der Anfrage statt der Sitzung vertraute, und ein Single-Sign-on über Domänengrenzen, das session_uid und session_hash in der URL mitschleppte. Bestätigungs-Hashes für Passwort-Reset und Adressänderung liefen nie ab, und das Feld für den echten Namen filterte beim Speichern nur das Zeichen <. Der FSF entschied sich, die Rechteprobleme nicht einzeln zu flicken, sondern die betroffenen Teile neu zu strukturieren. Das ist mühsamer und ehrlicher.
Was der Fall für Open-Source-Sicherheit bedeutet
Die Meldekette verlief ohne Komplikationen. Am 11. Mai 2026 ging der Bericht an savannah-hackers-private, am Tag darauf bestätigte der Savannah-Administrator Corwin Brust den Eingang und das 30-Tage-Fenster. Am 14. Mai war der gepatchte Kernel installiert und das Forscherkonto entfernt. Im Juni veröffentlichte der FSF eine Stellungnahme, im August den ausführlichen Incident Report samt Patches.
Auffällig ist, wie ungleich die Teile des Angriffs wiegen. Die spektakuläre Lücke war die Shell Injection, der teuerste Teil kam aber aus einem Kernel, den niemand aktualisiert hatte. Die Mehrzahl der Befunde waren gewöhnliche Rechtefehler in Code von 2001. So sieht Open-Source-Sicherheit in der Praxis aus: nicht ein dramatischer Einbruch, sondern viele kleine Stellen, an denen Daten als Anweisung gelesen werden und Zuständigkeiten nicht sauber geprüft sind.
Drei Dinge folgen daraus für alle, die selbst Software betreiben. Erstens gehören Nutzereingaben nie in einen Befehlsstring, sondern als Argumentliste an eine Funktion, die keine Shell dazwischenschaltet. Zweitens ist eine Validierung, die RFC-konform ist, noch keine Sicherheitsgrenze; sie sagt, was formal zulässig ist, nicht was gefährlich ist. Drittens lohnt der Blick auf das, was hinter der Anwendung liegt: Kernel, Backups, Dienstkonten. Die Bash-Sicherheitslücke in diesem Fall war keine Lücke in Bash. Sie war eine Lücke in der Verwaltung eines Hauses, in dem Bash wohnt – und dieses Haus wird von Freiwilligen instand gehalten.
Quelle: hacktron.ai
