GitLab-Sicherheitslücke: BSI warnt vor CVE-2026-85706

Eine Schwachstelle mit dem höchstmöglichen Schweregrad CVSS 10.0, erste beobachtete Angriffsversuche und eine ausdrückliche Warnung des BSI: Die am 16. September 2026 gemeldete GitLab-Sicherheitslücke CVE-2026-85706 gehört zu den Fällen, bei denen zwischen Meldung und Massenausnutzung erfahrungsgemäß nur wenige Tage liegen. Betroffen sind selbst gehostete GitLab-Instanzen, wie sie in vielen mittelständischen Unternehmen, Softwarehäusern und IT-Abteilungen laufen, oft seit Jahren und nicht immer auf aktuellem Stand.

Dieser Beitrag fasst zusammen, was über die Schwachstellen bekannt ist, wer handeln muss und wie ein sauberer Update- und Prüfprozess jetzt aussieht. Und er zeigt, warum der Fall ein Lehrstück für das Schwachstellenmanagement im Mittelstand ist.

Die Schwachstellen im Überblick

Das BSI warnt vor zwei kritischen Lücken in GitLab Community Edition (CE) und Enterprise Edition (EE) (DSIN, 16.09.2026):

• CVE-2026-85706 (CVSS 10.0): Die Hauptlücke beruht auf unzureichender Pfadvalidierung und fehlenden Authentifizierungsprüfungen in der Commits-API des Repository-Dienstes. Angreifer können dadurch ohne Anmeldung auf Dateien zugreifen, die eigentlich geschützt sein müssten.
• CVE-2026-87719 (CVSS 9.9): Eine zweite, fast ebenso kritische Schwachstelle, die mit denselben Updates geschlossen wird.

Besonders brisant: Sicherheitsforscher von watchTowr haben bereits erste Ausnutzungsversuche beobachtet. Die Lücke ist also nicht nur theoretisch kritisch, sondern wird aktiv getestet und angegriffen.

Warum unautorisierter Dateizugriff so gefährlich ist

„Dateizugriff ohne Login" klingt zunächst harmloser als „Codeausführung". In der Praxis ist ein Git-Repository aber oft eine Schatzkammer: Quellcode, Konfigurationsdateien, API-Schlüssel, Zugangsdaten in CI/CD-Variablen, interne Dokumentation. Wer diese Daten abgreift, hat häufig alles, was für den nächsten, viel tieferen Angriff nötig ist, vom Zugriff auf Cloud-Umgebungen bis zur Manipulation der Software-Lieferkette. Für Unternehmen, die Software für Kunden entwickeln, steht zusätzlich das Vertrauen der Auftraggeber auf dem Spiel.

Wer ist betroffen?

Verwundbar sind laut BSI selbst gehostete GitLab-Instanzen (CE und EE) in folgenden Versionsständen:

• 18.7 bis 19.1.7
• 19.2.0 bis 19.2.5
• 19.3.0 bis 19.3.1

Abhilfe schaffen die Versionen 19.1.8, 19.2.6 und 19.3.2. Nutzer der Cloud-Variante gitlab.com müssen selbst nicht patchen, dort spielt der Anbieter die Updates ein. Wer allerdings nicht sicher weiß, ob im Unternehmen irgendwo eine selbst gehostete Instanz läuft, etwa aus einem früheren Projekt, sollte genau das jetzt klären. Vergessene Entwicklungsserver mit Internetanbindung gehören zu den häufigsten Funden bei Sicherheitsüberprüfungen. Penetrationstest: exponierte Systeme finden, bevor es Angreifer tun

Sofortmaßnahmen: der Fahrplan für die nächsten 48 Stunden

Das BSI empfiehlt ein gestuftes Vorgehen, das wir aus der Praxis ausdrücklich unterstreichen:

1. Sofort aktualisieren. Spielen Sie die fixe Version (19.1.8, 19.2.6 oder 19.3.2) unverzüglich ein. GitLab-Updates sind gut automatisiert; ein kurzes Wartungsfenster ist das kleinere Übel gegenüber einem Datenabfluss.
2. Erreichbarkeit reduzieren. Wenn ein zeitnahes Update nicht möglich ist, nehmen Sie die Instanz vorübergehend vom Netz oder beschränken Sie den Zugriff per VPN oder IP-Filter. Eine öffentlich erreichbare, verwundbare Entwicklungsplattform ist ein unkalkulierbares Risiko.
3. Auf Kompromittierung prüfen. Kontrollieren Sie nach dem Update die Zugriffslogs auf ungewöhnliche API-Aufrufe, insbesondere auf die Commits-API, sowie unbekannte IP-Adressen und auffällige Downloads. Da erste Angriffe schon vor der BSI-Warnung liefen, ist ein Patch allein keine Entwarnung.
4. Geheimnisse rotieren. Wenn Ihre Repositories Zugangsdaten, Tokens oder Schlüssel enthalten und ein unbefugter Zugriff nicht ausgeschlossen werden kann, sollten diese vorsorglich erneuert werden. Erfahrungsgemäß liegen in fast jedem gewachsenen Repository mehr Secrets, als das Team vermutet.

Wenn sich bei der Prüfung ein konkreter Verdacht ergibt, gilt: Systeme nicht überstürzt bereinigen, sondern Spuren sichern und strukturiert vorgehen. Incident Response: im Ernstfall richtig reagieren

Das Lehrstück: Schwachstellenmanagement ist Chefsache

Der GitLab-Fall zeigt ein Muster, das wir in dieser Deutlichkeit fast jede Woche sehen: Eine kritische Lücke wird veröffentlicht, Angreifer scannen binnen Stunden das gesamte Internet, und getroffen werden vor allem Organisationen, deren Update-Prozess auf Zuruf funktioniert. Drei Fragen sollte sich jede Geschäftsführung deshalb stellen.

Wissen wir, was wir betreiben? Ein aktuelles Inventar aller aus dem Internet erreichbaren Systeme ist die Grundlage jeder Verteidigung. Was nicht auf der Liste steht, wird nicht gepatcht.

Wie schnell reagieren wir auf kritische Warnungen? Zwischen BSI-Warnung und Ausnutzung liegen oft nur Tage. Wer keine definierten Reaktionszeiten und Zuständigkeiten hat, verliert genau diese Tage mit Abstimmung. Ein externer Informationssicherheitsbeauftragter kann solche Prozesse etablieren, ohne dass dafür intern eine Stelle geschaffen werden muss. Externer ISB: Sicherheitsprozesse mit klaren Zuständigkeiten

Merken wir es, wenn es passiert? Kein Patch-Prozess der Welt ist immer schneller als der Angreifer. Deshalb braucht es eine zweite Verteidigungslinie: kontinuierliche Überwachung, die ungewöhnliche Zugriffe und Datenabflüsse erkennt, auch nachts und am Wochenende. 24/7-Monitoring mit Managed Detection & Response

Für NIS2-regulierte Unternehmen sind diese drei Punkte keine Kür, sondern Bestandteil der gesetzlich geforderten Risikomanagementmaßnahmen. Der Umgang mit einer BSI-Warnung wie dieser ist ein guter Testlauf dafür, ob die eigenen Prozesse im Audit bestehen würden.

Fazit

CVE-2026-85706 kombiniert maximalen Schweregrad mit einfacher Ausnutzbarkeit und laufenden Angriffsversuchen. Wer eine selbst gehostete GitLab-Instanz betreibt, sollte heute patchen, den Zugriff prüfen und im Zweifel Secrets rotieren. Und wer beim Lesen gemerkt hat, dass unklar ist, welche Systeme im eigenen Haus überhaupt exponiert sind oder wie schnell auf BSI-Warnungen reagiert wird, für den ist genau das der richtige Anlass, diese Lücken zu schließen. Wir unterstützen dabei gerne, pragmatisch und auf Mittelstandsformat zugeschnitten.

Häufige Fragen

Betrifft die Lücke auch gitlab.com?

Nutzer der Cloud-Version gitlab.com müssen nicht selbst handeln, der Anbieter patcht zentral. Die BSI-Warnung richtet sich an Betreiber selbst gehosteter GitLab-Instanzen (Community und Enterprise Edition) in den Versionen 18.7 bis 19.3.1.

Wir können nicht sofort updaten. Was ist das Minimum?

Nehmen Sie die Instanz vom öffentlichen Netz oder beschränken Sie den Zugriff auf VPN und bekannte IP-Adressen, bis das Update auf 19.1.8, 19.2.6 oder 19.3.2 eingespielt ist. Das BSI empfiehlt ausdrücklich, betroffene Systeme offline zu nehmen, wenn zeitnahes Patchen nicht möglich ist.

Woran erkennen wir, ob wir bereits angegriffen wurden?

Prüfen Sie die Logs auf ungewöhnliche Zugriffe auf die Commits-API, Anfragen ohne zugehörige Anmeldung, unbekannte IP-Adressen und untypische Datenmengen. Da watchTowr bereits Ausnutzungsversuche beobachtet hat, gehört diese Prüfung zwingend zum Update dazu. Im Zweifel unterstützt eine externe Kompromittierungsanalyse.

Müssen wir den Vorfall melden?

Das hängt vom Einzelfall ab. Wurden personenbezogene Daten kompromittiert, greift die DSGVO mit der 72-Stunden-Meldung an die Datenschutzaufsicht. NIS2-regulierte Unternehmen müssen erhebliche Sicherheitsvorfälle zusätzlich innerhalb von 24 Stunden an das BSI erstmelden. Eine bloße verwundbare Version ohne Anzeichen eines Zugriffs ist dagegen in der Regel nicht meldepflichtig.

Quellen

• DSIN / Deutschland sicher im Netz: BSI warnt vor laufenden Angriffen auf kritische GitLab-Sicherheitslücke (16.09.2026): https://www.sicher-im-netz.de/bsi-warnt-vor-laufenden-angriffen-auf-kritische-gitlab-sicherheitsluecke/
• BSI: Cyber-Sicherheitswarnungen (Übersicht): https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Technische-Sicherheitshinweise-und-Warnungen/Cyber-Sicherheitswarnungen/cyber-sicherheitswarnungen_node.html