GitLab CVE-2026-85706: CVSS-10-Lücke wird aktiv ausgenutzt

CVE-2026-85706 ist eine Path-Traversal-Schwachstelle der höchsten Schwere in selbst verwalteten GitLab Community Edition (CE) und Enterprise Edition (EE). Die Lücke hat einen CVSS-3.1-Score von 10,0. Unter bestimmten Bedingungen können nicht angemeldete Angreifer beliebige Dateien lesen, auf die der GitLab-Dienst auf dem Server zugreifen kann. Es handelt sich nicht nur um ein theoretisches Risiko: Die US-Behörde CISA führt die CVE als aktiv ausgenutzt, und Sicherheitsforscher meldeten kurz nach Veröffentlichung der Patches erste Sondierungsversuche gegen öffentlich erreichbare Instanzen. 32122

Sofortmaßnahme: Update einspielen

Betreiber einer betroffenen selbst verwalteten GitLab-Instanz sollten unverzüglich auf eine korrigierte Version aktualisieren:

• 19.1.8 oder neuer
• 19.2.6 oder neuer
• 19.3.2 oder neuer

Betroffen sind GitLab CE/EE in den Versionsbereichen 18.7 bis vor 19.1.8, 19.2 bis vor 19.2.6 sowie 19.3 bis vor 19.3.2. GitLab veröffentlichte die Korrekturen am 10. September 2026. 37

CISA nahm CVE-2026-85706 am 11. September in den Katalog Known Exploited Vulnerabilities (KEV) auf. Für erfasste zivile US-Bundesbehörden galt der 14. September als Umsetzungsfrist. Diese Vorgabe gilt nicht automatisch für private Unternehmen oder Organisationen in Deutschland, unterstreicht aber die Dringlichkeit bei jeder aus dem Internet erreichbaren selbst verwalteten Installation. 3

Was die Schwachstelle ermöglicht

Der Fehler liegt in der Repository-Commits-API von GitLab. Als Ursache nennt die veröffentlichte Beschreibung eine unzureichende Beschränkung nutzergesteuerter Pfade zusammen mit fehlender Durchsetzung der Authentifizierung. Dadurch kann ein nicht angemeldeter Anfragender unter bestimmten Bedingungen Dateien außerhalb des vorgesehenen Repository-Pfads lesen. 3

Im Kern ist dies eine Datenabfluss-Schwachstelle. Die vorliegenden Berichte belegen nicht, dass CVE-2026-85706 allein eine Remote-Code-Ausführung ermöglicht. Das Lesen beliebiger Dateien kann jedoch je nach Konfiguration Material für einen Folgeschaden liefern – etwa Anwendungseinstellungen, Tokens, SSH-Schlüssel, Datenbankzugangsdaten oder andere Geheimnisse, die der GitLab-Prozess lesen darf. 925

Warum die aktive Ausnutzung entscheidend ist

WatchTowr berichtete über Angriffsversuche in freier Wildbahn, die am 11. September über das eigene Honeypot-Netz erfasst wurden. Auch der KEV-Eintrag der CISA ist ein starkes Warnsignal: Der Katalog soll Schwachstellen mit Nachweisen für reale Ausnutzung sichtbar machen. 222

Öffentliche Berichte bestätigen Scans und Ausnutzungsaktivität, nennen aber weder einen eindeutig verantwortlichen Akteur noch eine belastbare Opferzahl oder eine universell bestätigte Angriffskette nach dem Dateizugriff. Dass kein Sicherheitsvorfall bekannt ist, bedeutet daher nicht, dass eine exponierte Instanz nicht abgefragt wurde.

Öffentliche betroffene Instanzen als möglichen Geheimnisabfluss behandeln

Ein Patch beendet das verwundbare Verhalten, macht aber bereits ausgelesene Daten nicht unzugänglich. Bei einem betroffenen, öffentlich erreichbaren Server sollten Teams zunächst Beweise sichern und prüfen, worauf das GitLab-Dienstkonto zugreifen konnte, bevor sie umfassende Bereinigungen beginnen.

Vorrangig zu prüfen und bei möglicher Exposition zu rotieren sind unter anderem:

• GitLab-Anwendungs- und Konfigurationsgeheimnisse
• Zugangsdaten für Datenbanken, Redis, Objektspeicher, Container-Registry, SMTP, Verzeichnisdienste und Identitätsanbieter, sofern sie in der Konfiguration hinterlegt sind
• CI/CD-Variablen, Deploy- und Access-Tokens, Runner-Tokens, Deploy-Keys sowie für Jobs oder Integrationen eingebundene Zugangsdaten
• Cloud-Schlüssel, Paket-Registry-Zugangsdaten, Signaturschlüssel sowie SSH- oder TLS-Privatschlüssel, auf die Host oder GitLab-Prozess zugreifen konnten

Die Rotation muss geplant erfolgen. Änderungen an Anwendungsgeheimnissen oder verschlüsselungsrelevanten Einstellungen können Sitzungen ungültig machen und verschlüsselte Einstellungen oder Integrationen beeinträchtigen. Deshalb zuerst relevante Logs und Konfigurationen sichern, Wiederherstellungswege festlegen und anschließend die kritischsten Zugangsdaten in kontrollierter Reihenfolge rotieren.

Erkennung: Diese Spuren sind wichtig

Ein erster relevanter Indikator sind HTTP-POST-Anfragen an die Repository-Commits-API:

/api/v4/projects/<id>/repository/commits/

Besonders untersucht werden sollten Anfragen mit dem Parameter file.path. Reverse-Proxy-, Load-Balancer-, WAF- und GitLab-Rails-Logs können Hinweise liefern: ungewöhnliche nicht authentifizierte Requests, kodierte Traversal-Muster, unerwartete Projekt-IDs, wiederholte Fehler, Enumeration oder auffällige Antwortgrößen. 212426

Zusätzlich sollten Teams Aktivitäten nach dem vermuteten Expositionszeitraum korrelieren, etwa neu angelegte oder verwendete Tokens, Runner-Registrierungen, geänderte CI/CD-Variablen oder Pipeline-Definitionen, auffällige Importe, GraphQL-Aktivität und unerwartete ausgehende Verbindungen. Die rund um das Release veröffentlichte Handlungsempfehlung nennt außerdem Commits, GraphQL-Subscriptions, Projektimporte und CI/CD-Pipelines als Prüffelder. 23

Ein unauffälliger Log-Suchlauf ist kein Entwarnungssignal. Die Aufbewahrungsdauer kann zu kurz sein, die Anwendung kann nicht alle relevanten Request-Details protokollieren, und mitunter sind nur Proxy- oder WAF-Protokolle noch verfügbar.

Übergangsmaßnahmen, falls das Update verzögert ist

Das Update ist die notwendige Abhilfe. Wenn ein Notfall-Update nicht sofort möglich ist, sollte der Zugriff auf Web- und API-Dienst von GitLab vorübergehend auf VPN oder explizit zugelassene Netze beschränkt werden. Eine eng gefasste Regel im Reverse Proxy oder WAF für die betroffene Repository-Commits-API kann das Risiko kurzfristig senken, kann jedoch legitime Automatisierung stören und ersetzt kein Patchen.

Die praktische Reihenfolge für jeden betroffenen Server:

1. Instanzen erfassen und priorisieren, insbesondere öffentlich erreichbare Systeme.
2. Aktualisieren auf 19.1.8, 19.2.6, 19.3.2 oder neuer.
3. Tatsächlich laufende Version verifizieren.
4. Logs sichern und auf Ausnutzungshinweise prüfen.
5. Potenziell offengelegte Geheimnisse rotieren, abgestimmt auf Zugriffsrechte und geschäftliche Auswirkungen.

Weitere Lücken im selben Release

In der Sicherheitsberichterstattung zu diesem Release wurden außerdem zwei Enterprise-Edition-Probleme genannt:

• CVE-2026-87719: eine authentifizierte Deserialisierungs-Schwachstelle mit CVSS 9,9, die in einigen Berichten mit der Offenlegung von Advanced-Search-Konfigurationen und Zugangsdaten in Verbindung gebracht wird. 6
• CVE-2026-88765: ein authentifiziertes Risiko zur Remote-Code-Ausführung beim Import eines präparierten Git-Projekt-Exports; der berichtete CVSS-Score liegt bei 8,5. 625

Diese Schwachstellen haben andere Voraussetzungen und Auswirkungen als CVE-2026-85706. Bei öffentlich erreichbaren selbst verwalteten GitLab-Installationen sollte die nicht authentifizierte, aktiv ausgenutzte Dateileselücke dennoch die erste Priorität für Eindämmung und Incident Response haben.