GitLab Schwachstellen: BSI warnt, Patches verfügbar

Der Warn- und Informationsdienst (WID) des BSI meldet unter der Kennung WID-SEC-2026-3858 mehrere GitLab Schwachstellen. Betroffen sind GitLab-Installationen, vor allem selbst betriebene Server. Die gemeldete Wirkungsspanne ist breit: beliebige Codeausführung, Offenlegung von Informationen, Datenmanipulation, Cross-Site-Scripting und das Umgehen von Sicherheitsvorkehrungen. Konkrete CVE-Nummern, betroffene Versionen oder CVSS-Werte nennt der abrufbare WID-Eintrag nicht – im Abruf war nur der Seitentitel extrahierbar. Für Admins heißt das: Der Hinweis ist ernst zu nehmen, taugt aber nicht als alleinige Grundlage für einen Patch-Plan.

Wer die Lage sauber bewerten will, muss deshalb zwei Stränge getrennt betrachten: die generische WID-Meldung und die deutlich konkreteren Angaben aus einem GitLab-Patchzyklus, der rund einen Monat zuvor veröffentlicht wurde.

GitLab Schwachstellen: Was der WID-Hinweis belegt – und was nicht

Der Eintrag listet ausschließlich Auswirkungsklassen, keine technischen Details. Das ist für ein WID-Advisory nicht ungewöhnlich, erschwert die Priorisierung aber erheblich.

Klar ist: Die Spanne reicht von vollständiger Kompromittierung durch beliebige Codeausführung bis zu stiller Dateneinsicht, die lange unbemerkt bleiben kann. Dazwischen liegen Datenmanipulation und XSS – Angriffe, die sich auch gegen die Nutzer einer vermeintlich korrekt gepatchten Instanz richten können.

Nicht belegt ist dagegen, welche GitLab-Editionen betroffen sind, ob ausschließlich die Community Edition oder auch die Enterprise Edition, und ob es sich um eine einzelne Lücke oder ein Bündel unabhängiger Schwachstellen handelt. Der WID-Text lässt das offen. Ungeklärt bleibt auch, ob die Meldung einen neuen Patch-Stand beschreibt oder einen bereits bekannten Sachverhalt erneut aufgreift.

CVE-2026-85706 und CVE-2026-87719: der kritische September-Zyklus

Deutlich konkreter wird es einen Monat früher. Nach Angaben in einer Cyber-Sicherheitswarnung des BSI vom 14. September 2026 (Version 1.0) umfasst der GitLab-Advisory-Stand vom 10. September 2026 insgesamt 18 Sicherheitslücken in GitLab CE/EE, verteilt über mehrere Schweregrade.

Zwei Kennungen stechen heraus: CVE-2026-85706 mit einem CVSS-Score von 10,0 und CVE-2026-87719 mit 9,9. Beide Werte finden sich in einer Einordnung zu den CVSS-Werten und Sofortmaßnahmen sowie in einer CVE-Datenbankabfrage zu GitLab, die CVE-2026-87719 als „9.9 Critical" führt. Ein Score von 10,0 bedeutet in der Praxis meist: keine Authentifizierung nötig, keine Nutzerinteraktion erforderlich und vollständiger Verlust von Vertraulichkeit, Integrität und Verfügbarkeit. Für eine selbst gehostete Instanz ist das der Worst Case.

An dieser Stelle ist ausdrückliche Vorsicht angebracht: Ob CVE-2026-85706 und CVE-2026-87719 überhaupt Teil von WID-SEC-2026-3858 sind, ist aus dem vorliegenden Material nicht belegt. Diese Verbindung darf nicht als Tatsache gelesen werden – in keine Richtung. Die Kennungen bleiben trotzdem relevant, weil an ihnen sichtbar wird, wie schnell aus einer GitLab-Lücke ein real ausgenutztes Angriffsziel wird.

Ursache und Ausnutzung: Pfadbegrenzung plus fehlende Authentifizierungsprüfung

Als technische Ursache der kritischen Lücke nennt eine Meldung mit betroffenen Versionsständen und Handlungsempfehlungen das Zusammenspiel aus Pfadbegrenzung (Path Traversal) und einer fehlenden Authentifizierungsprüfung in der Repository-Commits-API. Genau diese Kombination erklärt, warum der Fehler so hoch bewertet wird: Ein Angreifer muss sich nicht anmelden, kann aber über manipulierte Pfadangaben an Objekte gelangen, die eigentlich nicht für ihn bestimmt sind.

Dass die Lücke kein theoretisches Szenario ist, zeigt der Zeitverlauf. Laut den verfügbaren Meldungen wurden erste Ausnutzungsversuche bereits kurz nach der Veröffentlichung der Advisories beobachtet. Bei stark verbreiteter Open-Source-Software liegt zwischen Patch-Veröffentlichung und ersten Exploit-Versuchen oft nur ein schmales Fenster – GitLab gehört hier zu den exponiertesten Zielen überhaupt, weil dort Quellcode, CI/CD-Pipelines, Container-Registry und teils Secrets zusammenlaufen. Eine kompromittierte Instanz ist deshalb selten ein isolierter Vorfall, sondern ein Zugang zu allem, was die Pipeline berührt.

Wie viele Instanzen in Deutschland betroffen oder kompromittiert wurden, lässt sich aus den Quellen nicht ableiten. Zahlen dazu nennt keine der Meldungen, konkrete Angreifergruppen werden nicht benannt.

Patch-Status: Fixes verfügbar, Versionsnummern offen

Für den September-Zyklus hat GitLab Fix-Versionen veröffentlicht, der Status ist also Patch verfügbar. Die Dringlichkeit bleibt hoch, weil Ausnutzung beobachtet wurde. Konkrete Versionsnummern lagen im vorliegenden Recherche-Material jedoch nicht vor und sind vor einem Update direkt an der offiziellen GitLab-Advisory beziehungsweise den Release-Notes zu verifizieren. Die Angabe „Cleanup-Version" aus zweiter Hand ersetzt diesen Abgleich nicht.

Auch die CVE-Datenbankabfrage listet neben CVE-2026-87719 weitere GitLab-Einträge mit Fix-Versionen – solche Stände sind Momentaufnahmen und keine Herstellerangabe. Workarounds oder Mitigations werden im vorliegenden Material nicht dokumentiert. Wer nicht sofort aktualisieren kann, hat damit keine belegte Zwischenlösung; das erhöht den Druck, das Update kurzfristig einzuplanen.

Handlungsempfehlung: Update und Logs prüfen

Betreiber einer GitLab-Instanz sollten den Versionsstand umgehend prüfen und gegen die aktuelle Advisory- und Release-Notes-Lage abgleichen, bevor sie patchen. Wer die eigene Versionslinie kennt, kann einschätzen, ob der Fix bereits enthalten ist oder nicht.

Parallel empfiehlt sich ein Blick in die Logs, insbesondere bei aus dem Internet erreichbaren Instanzen: ungewöhnliche Zugriffe auf Repository- und Commit-Endpunkte, auffällige Pfadparameter oder Zugriffe ohne korrespondierende Authentifizierung sind Warnsignale. Der WID-Eintrag WID-SEC-2026-3858 sollte weiter beobachtet werden, bis er inhaltlich befüllt ist – erst dann lässt sich sagen, ob er den September-Satz bestätigt oder einen neuen Patch-Stand beschreibt. Bis dahin gilt: Die belastbaren Fakten stammen aus dem September-Zyklus, nicht aus der Oktober-Meldung.

Quellen