GitLab Sicherheitslücke CVE-2026-85706: Scans einen Tag nach dem Patch

Die GitLab Sicherheitslücke CVE-2026-85706 hat den höchstmöglichen CVSS-Wert von 10.0 – und Angreifer suchen bereits danach. GitLab hat die Lücke am 10. September 2026 mit den Versionen 19.3.2, 19.2.6 und 19.1.8 geschlossen. Einen Tag später meldete die Angriffsflächen-Firma WatchTowr erste Sondierungen im Netz. Die US-Behörde CISA nahm den Fehler am 11. September in ihren Katalog aktiv ausgenutzter Schwachstellen auf und setzte US-Bundesbehörden eine Frist bis zum 14. September.

Was die GitLab Sicherheitslücke CVE-2026-85706 technisch bedeutet

Laut GitLab handelt es sich um einen Path-Traversal-Fehler in der Repository-Commits-API. Grund sind eine fehlerhafte Pfadbegrenzung und eine fehlende Authentifizierungsprüfung. Dadurch können unauthentifizierte Angreifer unter bestimmten Bedingungen beliebige Dateien vom Server lesen. Betroffen sind Community Edition und Enterprise Edition: alle Versionen ab 18.7 vor 19.1.8, 19.2 vor 19.2.6 sowie 19.3 vor 19.3.2. GitLab.com läuft bereits gepatcht, GitLab-Dedicated-Kunden müssen nichts tun. Gemeldet wurde die Lücke von einem Forscher mit dem Handle „s3ntago” über das HackerOne-Bug-Bounty-Programm.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Im selben Patch steckt eine zweite kritische Lücke: CVE-2026-87719 (CVSS 9.9), eine unsichere Deserialisierung im GraphQL-Subscription-Serializer. Sie betrifft GitLab EE und erlaubt authentifizierten Nutzern mit Duo-Chat-Zugriff, Konfigurationen der Advanced Search und sensible Zugangsdaten auszulesen. Insgesamt listet das Release 18 Schwachstellen, darunter eine EE-RCE über präparierte Projekt-Importe (CVE-2026-88765, CVSS 8.5).

Warum Angreifer so schnell da sind

Das Muster ist nicht neu. Jake Knott, Head of Threat Intelligence bei WatchTowr, verweist auf die vorherige kritische GitLab-Lücke, eine GraphQL-Code-Injection (CVE-2026-19478), die ebenfalls fast unmittelbar nach der Offenlegung angegriffen wurde. Wie schnell Angreifer bei dieser Software zuschlagen, haben wir schon im Juli beschrieben, damals bei einem RCE-Exploit gegen ungepatchte Self-Managed-Server.

Der Reiz liegt auf der Hand. Eine GitLab-Instanz ist kein gewöhnlicher Webserver, sondern das Nervenzentrum der Softwareentwicklung: Quellcode, CI/CD-Secrets, Deploy-Token, Runner-Konfigurationen. Knott bringt es auf den Punkt: Wer dort Zugriff bekommt, erreicht auch alles, was in der Build-Pipeline nachgelagert ist.

Was das für dich bedeutet

Aus CISO-Sicht ist der Schadensfall hier nicht der gelesene Quellcode, sondern das, was daneben liegt. In 25 Jahren IT habe ich kaum eine Build-Umgebung gesehen, in der nicht irgendwo ein Servicekonto, ein Registry-Token oder ein Deployment-Schlüssel im Klartext lag. Ein reiner Lesezugriff auf Dateien klingt harmlos – bis jemand die Konfigurationsdatei mit den Datenbank-Zugangsdaten erwischt. Genau deshalb ist CVSS 10.0 hier kein übertriebener Alarmwert.

Die zweite, unbequeme Wahrheit: Patchen allein reicht nicht mehr. Zwischen Veröffentlichung und erstem Scan lag ein einziger Tag. Bemerkenswert ist deshalb, dass CISA in ihrem Katalog-Eintrag nicht nur das Einspielen des Updates verlangt, sondern ausdrücklich auch eine forensische Triage. Wer erst am Montag aktualisiert, sollte davon ausgehen, dass die eigene Instanz übers Wochenende zumindest angetastet wurde. Rückblickend prüfen ist damit Pflichtteil des Patchvorgangs, nicht die Kür.

Konkrete Handlungsempfehlung

• Sofort aktualisieren auf 19.3.2, 19.2.6 oder 19.1.8. Achtung: Das Release enthält Datenbank-Migrationen. Auf Single-Node-Instanzen entsteht dabei laut GitLab eine Ausfallzeit; Multi-Node-Umgebungen können das Zero-Downtime-Verfahren nutzen.
• Logs durchsuchen, und zwar bevor du patchst. WatchTowr empfiehlt die Suche nach HTTP-POST-Anfragen auf URIs der Form /api/v4/projects/{id}/repository/commits/, die einen Parameter file.path enthalten. Such dabei ohne Rücksicht auf Groß- und Kleinschreibung.
• Secrets rotieren, wenn die Instanz aus dem Internet erreichbar war: CI/CD-Variablen, Deploy-Token, Runner-Registrierungstoken, angebundene Registry-Zugänge. Das ist meine eigene Empfehlung und keine Vorgabe des Herstellers – sie kostet wenig und nimmt einem möglichen Dateidiebstahl die Wirkung.
• Erreichbarkeit reduzieren. Eine self-managed GitLab-Instanz muss selten offen im Netz stehen. VPN oder IP-Allowlist vor der Weboberfläche nehmen genau dieser Angriffsklasse die Grundlage.

Und die unbequeme Grundsatzfrage gleich hinterher: Weißt du, welche Zugangsdaten in deinen Repos und CI-Variablen liegen? Wenn die Antwort länger als zehn Sekunden dauert, ist das der eigentliche Befund dieser Woche.

Quellen

• GitLab: Critical Patch Release 19.3.2, 19.2.6, 19.1.8 (10.09.2026)
• NVD: CVE-2026-85706
• CISA: Known Exploited Vulnerabilities Catalog (Eintrag vom 11.09.2026)
• SecurityWeek: GitLab Vulnerability Exploited One Day After Disclosure (11.09.2026)
• BleepingComputer: GitLab urges users to patch max severity path traversal flaw (11.09.2026)