GitLab hat am 23. September elf Sicherheitslücken auf einmal geschlossen. Wer den Dienst gemietet hat, musste nichts tun. Wer ihn selbst betreibt, schon. Bei der Lücke zwei Wochen davor lagen zwischen Patch und erstem Angriff keine 24 Stunden. Und genau da wird es unbequem, auch für Betriebe, die mit GitLab nichts zu tun haben.
Am 23. September hat GitLab die Versionen 19.4.1, 19.3.3 und 19.2.7 veröffentlicht und damit elf Sicherheitslücken geschlossen. Die Empfehlung im eigenen Text ist ungewöhnlich deutlich: Alle betroffenen Installationen sollten sofort aktualisiert werden. Für die gemietete Fassung und für GitLab Dedicated war nichts zu tun, die waren bereits versorgt. Die Arbeit lag bei allen, die das Ding selbst betreiben.
Die beiden schwersten Lücken liegen im Teil, der reguläre Ausdrücke in der CI/CD-Konfiguration verarbeitet, also in dem Stück, das automatische Abläufe steuert. Unter bestimmten Bedingungen konnte ein angemeldeter Nutzer damit eigenen Programmcode auf dem Server ausführen. Beide sind mit einem Schweregrad von 9,9 von 10 bewertet. Dazu kommt eine Lücke im Ansehen von Änderungen, über die sich fremder Code im Browser anderer Nutzer ausführen ließ, Schweregrad 8,7. Der Rest sind Rechte- und Zugriffsfehler in der unteren Hälfte der Skala.
Bemerkenswerter ist die Vorgeschichte. Zwei Wochen früher, am 10. September, hatte GitLab eine Lücke mit dem Höchstwert 10,0 geschlossen. Sie steckte in der Schnittstelle für Änderungen an Dateien, brauchte keine Anmeldung und erlaubte das Lesen beliebiger Dateien vom Server. Zu diesen Dateien gehören die, aus denen sich Sitzungen fälschen und gespeicherte Zugangsdaten entschlüsseln lassen.
Diese Lücke wurde von der US-Behörde CISA in den Katalog der aktiv ausgenutzten Schwachstellen aufgenommen. GitLab hat drei Erkennungsregeln nachgeliefert, mit denen Betreiber prüfen können, ob es sie erwischt hat. Sicherheitsforscher berichteten, dass die ersten Angriffsversuche bereits am Tag nach der Veröffentlichung liefen.
Das ist der eigentliche Punkt dieser Geschichte, und er hat mit GitLab wenig zu tun: Ein veröffentlichter Patch ist gleichzeitig eine Bauanleitung. Wer aktualisiert, ist raus. Wer eine Woche wartet, weil gerade viel los ist, steht in dieser Woche mit offener Tür da, und zwar mit einer Tür, deren Standort öffentlich bekannt ist.
Eigene Server haben gute Gründe: Daten bleiben im Haus, keine monatliche Miete, keine Abhängigkeit von den Launen eines Anbieters. Der Preis dafür ist nicht der Server, sondern die Pflege. Wer selbst betreibt, kauft sich eine Aufgabe, die nie fertig wird. Das ist völlig in Ordnung, solange es jemand weiß und jemand macht. Schlimm wird es, wenn beides niemand tut.
Jetzt der Teil, der auch für einen Handwerksbetrieb, eine Kanzlei oder einen Laden gilt. Kaum jemand davon betreibt GitLab. Aber fast jeder betreibt irgendetwas: eine Warenwirtschaft auf einem Rechner im Lager, eine Zeiterfassung, einen Netzwerkspeicher, eine Kameraanlage, ein Kassensystem, eine Website mit einem Dutzend Erweiterungen, vielleicht inzwischen einen kleinen Dienst, den ein KI-Werkzeug anspricht.
Die drei Fragen lauten: Erstens, was läuft bei uns überhaupt und in welcher Version? Zweitens, wer ist dafür zuständig, mit Namen, nicht mit „die EDV"? Drittens, wie lange dauert es bei uns von einer Sicherheitsmeldung bis zur eingespielten Aktualisierung?
Wenn die Antwort auf die dritte Frage „weiß nicht" lautet, hast du dein Ergebnis.
Die Gegenmaßnahmen sind unspektakulär und kosten einen Vormittag. Eine Liste mit allem, was läuft, samt Version und Zuständigem. Die Sicherheitsmeldungen der Hersteller abonnieren, das ist bei jedem ernsthaften Anbieter eine Mailadresse und ein Klick. Ein festes Wartungsfenster, zum Beispiel jeden Dienstagmorgen, damit Aktualisierungen nicht vom Tagesgeschäft aufgefressen werden. Fernzugänge einschränken, damit nicht jeder Dienst aus dem ganzen Internet erreichbar ist. Und vor jeder Aktualisierung eine Sicherung, die schon einmal zurückgespielt wurde. Eine Sicherung, die nie getestet wurde, ist eine Hoffnung.
Der neue Teil daran: KI-Werkzeuge bringen gerade zusätzliche Dienste ins Haus. Jeder kleine Server, den jemand aufsetzt, damit ein Agent auf etwas zugreifen kann, ist ab diesem Tag ein Ding, das gepflegt werden muss. Wer das beim Aufsetzen nicht mitdenkt, sammelt still vor sich hin Baustellen.
Die ehrliche Empfehlung für die meisten kleinen Betriebe lautet: Wenn niemand im Haus die Pflege wirklich übernimmt, ist die gemietete Fassung die sicherere. Bei GitLab hat genau das den Unterschied gemacht, die gemieteten Kunden waren bereits versorgt, bevor sie von der Lücke erfahren haben. Selbst betreiben ist die bessere Wahl für die, die es können und wollen. Für alle anderen ist es die teurere Illusion von Kontrolle.
Geh durch den Betrieb und schreib auf, was ein eigenes Anmeldefenster hat: Kasse, Warenwirtschaft, Zeiterfassung, Netzwerkspeicher, Kamera, Router, Website, Ticketsystem, alles. Hinter jede Zeile drei Angaben: Wer betreut das, wann wurde es zuletzt aktualisiert, ist es von außen erreichbar. Was du nicht beantworten kannst, markierst du. Diese markierten Zeilen sind deine Baustellen, und du hast sie gefunden, ohne einen einzigen Fachbegriff zu benutzen.
Mich beschäftigt an dieser Meldung nicht die Zahl elf, sondern der Abstand zwischen Veröffentlichung und erstem Angriff. Der Wettlauf ist nicht mehr Wochen lang, sondern Stunden. Wer seine Aktualisierungen nach Terminkalender einplant, hat den Takt der Gegenseite nicht verstanden.
Und es zieht sich durch alles, worüber wir gerade schreiben: Ob Agent, Postfach oder eigener Server, die Technik ist selten das Problem. Das Problem ist, dass niemand benannt ist, der hinschaut. Ein Name auf einer Liste ist die billigste Sicherheitsmaßnahme, die es gibt.
Quellen: GitLab, Critical Patch Release 19.4.1, 19.3.3, 19.2.7 vom 23.09.2026 (elf Lücken, darunter CVE-2026-89078 und CVE-2026-93577 mit CVSS 9,9 im Regex-Parser der CI/CD-Konfiguration sowie CVE-2026-84739 mit 8,7; GitLab.com gepatcht, Dedicated ohne Handlungsbedarf, selbst betriebene Installationen sollen sofort aktualisieren) und GitLab, Critical Patch Release 19.3.2, 19.2.6, 19.1.8 vom 10.09.2026 (CVE-2026-85706 mit CVSS 10,0, Pfaddurchgriff ohne Authentifizierung in der Commits-Schnittstelle, Aufnahme in den KEV-Katalog der CISA, drei Erkennungsregeln, Nachreichung für ältere Fassungen am 23.09.). Anlass war ein Bericht von Golem. Die Angabe, dass erste Angriffsversuche bereits am Folgetag liefen, stammt aus Berichten von Sicherheitsforschern und ist von uns nicht unabhängig geprüft. Stand: 26.09.2026.
Welches Modell für welche Aufgabe, welche Tools wirklich zählen und wie du richtig promptest — komplett lesbar, kein Download.
Jetzt gratis lesen →Wir gehen mit dir durch, welche Systeme in deinem Betrieb eine Pflege brauchen, wer dafür zuständig ist und was davon besser gemietet statt selbst betrieben wäre. Am Ende steht eine Liste, die auch dein Nachfolger versteht.