Wenn du dein eigenes GitLab im Homelab oder auf einem kleinen Server betreibst, ist das hier kein Thema für nächste Woche. Eine einzige Anfrage genügt, und ein Fremder liest Dateien von deinem Server. Ohne Passwort. Ohne Konto. Ohne Spuren im Login-Log.
EINE ANFRAGE — UND DIE TÜR STEHT OFFEN
Die Lücke trägt die Kennung CVE-2026-85706 und die Bewertung 10,0 von 10. Höher geht es nicht. Sie steckt in der Commits-Schnittstelle der GitLab-API, also in dem Endpunkt, über den Programme Commits in ein Projekt schreiben: /api/v4/projects/{id}/repository/commits/.
Zwei Fehler treffen dort aufeinander. Erstens prüft GitLab nicht sauber, ob ein übergebener Dateipfad das Projektverzeichnis überhaupt verlassen darf — Fachleute nennen das Path Traversal. Zweitens fehlt an dieser Stelle die Anmeldepflicht komplett. Beides zusammen heißt: Wer die Adresse deines Servers kennt, schickt eine einzige POST-Anfrage und bekommt zurück, was er angefragt hat.
Die einzige Bedingung ist erschreckend niedrig: Auf deiner Instanz muss mindestens ein öffentliches Projekt liegen. Ein einziges Demo-Repository, das du vor zwei Jahren auf „public“ gestellt hast, reicht als Eintrittskarte.
WAS DA WIRKLICH ABFLIESST
„Dateien lesen“ klingt harmlos. Ist es nicht. Auf einem GitLab-Server liegen genau die Sachen, die ein Angreifer sucht: die Konfigurationsdatei mit den Datenbank-Zugangsdaten, die geheimen Schlüssel, mit denen GitLab Sitzungen signiert, hinterlegte Tokens für Container-Registries und CI-Runner, und natürlich der Quellcode selbst.
Wer den Signaturschlüssel hat, kann sich gültige Sitzungen basteln. Wer die Runner-Tokens hat, hängt sich in deine Build-Pipeline. Aus „nur lesen“ wird auf diesem Weg sehr schnell „alles“.
GEFAHR: DIE CISA HAT DIE LÜCKE SCHON EINGETRAGEN
GitLab hat die Korrekturen am 10. September 2026 veröffentlicht. Einen Tag später, am 11. September, hat die US-Behörde CISA die Lücke in ihren Katalog der bekannt ausgenutzten Schwachstellen (KEV) aufgenommen. Genau das ist der Punkt, an dem eine Meldung aufhört, theoretisch zu sein: In den KEV-Katalog kommt nur, was nachweislich angegriffen wird.
US-Bundesbehörden haben deshalb eine Frist bis zum 14. September. Für dich gilt keine Frist — aber dieselbe Uhr. Sicherheitsfirmen melden seit der Veröffentlichung, dass im Netz nach verwundbaren Instanzen gesucht wird.
BETROFFEN? DAS SIND DIE VERSIONEN
Verwundbar sind GitLab Community Edition und Enterprise Edition in diesen Bereichen:
- 18.7 bis vor 19.1.8
- 19.2 bis vor 19.2.6
- 19.3 bis vor 19.3.2
Repariert sind 19.1.8, 19.2.6 und 19.3.2. Wer GitLab.com nutzt, muss nichts tun — die gehosteten Instanzen hat GitLab selbst gepatcht. Das Problem ist ausschließlich eines der selbst betriebenen Server.
SO RETTEST DU DEINEN SERVER IN 10 MINUTEN
Schritt 1 — Version feststellen. Melde dich an und ruf /help auf, dort steht die Versionsnummer ganz oben. Auf der Kommandozeile geht es auch: gitlab-rake gitlab:env:info.
Schritt 2 — Update einspielen. Bei einer Omnibus-Installation genügt das normale Paket-Update, also apt update && apt install gitlab-ce beziehungsweise gitlab-ee. Wer GitLab im Container fährt, zieht das passende Image und startet neu. Bleib dabei innerhalb deiner Versionslinie — ein Sprung von 19.1 auf 19.3 ist ein großes Update mit eigenen Migrationsschritten, der Sicherheitsfix steckt auch in 19.1.8.
Schritt 3 — Sofortmaßnahme, wenn du jetzt nicht updaten kannst. Nimm den Server vom offenen Internet. Eine Firewall-Regel oder ein VPN davor kostet zwei Minuten und schließt die Tür für alle, die nicht ohnehin in deinem Netz sind. Das ersetzt das Update nicht, es kauft dir nur Zeit.
Schritt 4 — Nachsehen, ob schon jemand da war. Sieh in /var/log/gitlab/gitlab-rails/production_json.log nach Anfragen auf den Commits-Endpunkt, die von unbekannten Adressen kommen und keinen angemeldeten Nutzer tragen. Auffällig sind Pfadangaben mit .. darin.
Schritt 5 — Aufräumen, falls doch. Wenn du Treffer findest, reicht das Update nicht mehr. Dann müssen die Geheimnisse neu: Datenbank-Passwort, GitLab-Secrets, alle Runner-Tokens, alle persönlichen Zugriffstokens.
EXTRA-TIPP: EIN ÖFFENTLICHES PROJEKT WENIGER
Geh bei der Gelegenheit deine Sichtbarkeiten durch. Unter Admin > Einstellungen > Allgemein > Sichtbarkeit kannst du „public“ als Voreinstellung ganz abschalten. Viele Homelab-Instanzen haben ein öffentliches Projekt nur deshalb, weil es beim Anlegen so voreingestellt war.
FAZIT: HEUTE, NICHT MORGEN
Eine 10,0er-Bewertung, ein Fix seit drei Tagen, bestätigte Angriffe und als einzige Voraussetzung ein öffentliches Projekt — diese Kombination gibt es selten. Das Update ist klein, der Schaden wäre es nicht.
Häufige Fragen
Welche GitLab-Versionen sind betroffen?
Wie merke ich, ob meine Instanz verwundbar ist?
/help auf, dort steht die Version. Alternativ liefert gitlab-rake gitlab:env:info dieselbe Angabe. Liegt deine Version in einem der oben genannten Bereiche und hast du mindestens ein öffentliches Projekt, bist du angreifbar.