Ing. Calogero Bono
Am 12. Oktober 2026 hat GitLab die Versionen 19.4.2, 19.3.5 und 19.2.8 für Community Edition und Enterprise Edition veröffentlicht. Darin steckt die Korrektur für CVE-2026-97229, eine Lücke mit CVSS-Wert 10.0, die zur Ausführung beliebigen Codes auf dem Server führen kann. Am Donnerstag hat die US-Behörde CISA die aktive Ausnutzung bestätigt und die Lücke in den KEV-Katalog aufgenommen. Wenn du eine eigene GitLab-Instanz betreibst, zählt jetzt vor allem das sofortige Update.
Ein paar Begriffe, bevor wir in die Fakten einsteigen. CVE ist die Kennung für eine öffentlich bekannte Schwachstelle. CVSS ist die Schweregradbewertung von 0 bis 10. CI/CD bezeichnet die automatischen Pipelines, die Code kompilieren, testen und veröffentlichen. KEV ist der Katalog der CISA mit Lücken, die bereits in echten Angriffen ausgenutzt werden. RCE steht für Remote Code Execution, also das Ausführen von Befehlen auf dem Server eines anderen.
Was ist CVE-2026-97229?
Laut der offiziellen Seite von GitLab handelt es sich um ein Integer-Overflow-Problem im Compiler für reguläre Ausdrücke, der in den CI/CD-Konfigurationen verwendet wird. Unter bestimmten Bedingungen konnte ein nicht angemeldeter Nutzer mit einem gezielt gebauten regulären Ausdruck beliebigen Code auf dem Server ausführen, wegen unzureichender Validierung.
Der CVSS-Vektor lautet Netzwerk, niedrige Komplexität, keine Rechte und keine Benutzerinteraktion. Deshalb erreicht der Wert 10.0. Gemeldet wurde die Lücke von joaxcar über das Bug-Bounty-Programm auf HackerOne.
Wer nutzt die Lücke aus?
Wie BleepingComputer berichtet, hat CISA die Lücke in den KEV-Katalog aufgenommen und die Bundesbehörden aufgefordert, ihre Server bis Sonntag abzusichern. Laut The Hacker News liegt die Frist für zivile Behörden beim 1. November 2026.
Auslöser des Eintrags ist ein Vorfall, den Alpine Linux bekannt gemacht hat. Ein unbekannter Akteur hat am 20. und 21. Oktober 2026 erfolglos versucht, die Lücke auf deren Instanz auszunutzen. Er schickte eigens gebaute CI-Konfigurationen und brachte die Worker-Prozesse achtmal zum Absturz. In vier dieser Fälle scheiterte der Exploit im nächsten Schritt. Der Angreifer lud außerdem das GitLab-Container-Image von Alpine herunter. Neue Versuche am 25. und 26. Oktober wurden blockiert.
Die Alpine-Betreuer erklärten – «Der Angriff kam einem Erfolg nahe». Sie fanden keine Belege für einen erfolgreichen Angriff, können ihn aber nicht ausschließen, und deshalb haben sie die Instanz von Grund auf neu aufgebaut. Ihrer Aussage nach wurden das aports-Repository, die Pakete und die Releases vom 21. Oktober nicht manipuliert.
Welche Versionen sind betroffen?
Für CVE-2026-97229 nennt GitLab alle Versionen ab 19.2 vor 19.2.8, ab 19.3 vor 19.3.5 und ab 19.4 vor 19.4.2. GitLab.com nutzt bereits die korrigierte Version. Die GitLab-Dedicated-Mandanten wurden vor der Veröffentlichung mit einem internen Release aktualisiert.
GitLab weist außerdem darauf hin, dass Version 19.3.4 einen Fehler auf den Merge-Request-Seiten hatte, wenn die Ona-Integration aktiv war. Dieser ist in 19.3.5 behoben. Das Unternehmen hat zudem sechs Erkennungsregeln für Bedrohungen veröffentlicht, damit Betreiber selbst gehosteter Instanzen Angriffsversuche finden können.
Die anderen Lücken im selben Patch
Die Veröffentlichung enthält nicht nur den schwersten Fall. Unter den weiteren Korrekturen, mit den von GitLab angegebenen Werten, sind unter anderem –
- CVE-2026-92883, Cross-Site-Scripting in der Syntaxhervorhebung, CVSS 8.7.
- CVE-2026-16301, ein Nutzer mit der Rolle Developer konnte Pipelines auf geschützten Branches starten, CVSS 8.5.
- CVE-2026-14814, Cache-Poisoning beim Raw-File-Cache, mit möglicher Offenlegung geschützter Variablen, CVSS 8.2.
- CVE-2026-81839, Pipelines liefen nach dem Verschieben eines Projekts mit den Rechten der neuen Gruppe (nur EE), CVSS 7.7.
- CVE-2026-96893, Injection in die Anweisungen der KI-Agenten von GitLab Duo (nur EE), CVSS 7.3.
Dazu kommen fünf Lücken mit mittlerem Schweregrad, darunter das Auslesen vertraulicher Notizen über GraphQL und die Offenlegung von Tokens in den Logs von GitLab Pages. Das vollständige Bild findest du auf der offiziellen Seite.
Grenzen, die du kennen solltest
Wir wissen nicht, wie viele Instanzen kompromittiert wurden. Shadowserver, von BleepingComputer zitiert, zählt knapp 2.800 öffentlich erreichbare Community-Edition-Instanzen, gibt aber nicht an, wie viele davon bereits aktualisiert sind. Diese Zahl ist deshalb nicht gleichbedeutend mit der Zahl verwundbarer Systeme.
Aus den Quellen geht nicht hervor, wer der Angreifer ist oder ob es neben Alpine weitere Fälle gibt. Technische Details zum Exploit wurden nicht veröffentlicht. GitLab macht Meldungen 90 Tage nach dem Patch-Release öffentlich, weitere Details könnten also noch folgen.
Was sich für alle ändert, die digital arbeiten
Wenn du für dein Studio oder dein Unternehmen ein selbst gehostetes GitLab betreibst, hat das Update Priorität. Eine Lücke ohne Authentifizierung auf einem Server, der Code, Geheimnisse und Pipelines enthält, ist auch für deine Kunden ein konkretes Risiko. Wer sein Repository auf GitLab.com hostet, ist auf Plattformseite bereits geschützt.
Die Lehre aus dem Fall Alpine ist praktisch. Wenn du eine Kompromittierung nicht ausschließen kannst, baue die Instanz neu auf und rotiere die Geheimnisse. Automatisierte Installationen helfen dabei, wie wir im Leitfaden zu Ansible für Konfiguration und Deployment erklären. Bei Servern braucht es außerdem Disziplin bei Updates, ein Thema, das wir im Fall Fragnesia und PHP2Shell behandelt haben. Ein weiteres aktuelles Beispiel für Scans nach dem Patch ist Oracle E-Business Suite. Wenn dir die Zeit fehlt, dich um alles selbst zu kümmern, gibt es Hosting und verwaltete Server mit Sicherheitsupdates.
Unsere Einschätzung
Der Fall zeigt, wie kurz der Abstand zwischen Patch und Angriff sein kann. Die Korrektur stammt vom 12. Oktober, die Versuche bei Alpine vom 20., also acht Tage später. Wer erst im nächsten monatlichen Zyklus aktualisiert, kommt zu spät.
Eine kritische Anmerkung bleibt. GitLab wird als Anbieter genannt, der in mehr als der Hälfte der Fortune-100-Unternehmen vertreten ist, und BleepingComputer listet im selben Zeitraum eine Reihe von Lücken mit Höchstwert auf, darunter zwei weitere mit maximalem Schweregrad. Für einen Dienst, der Code und Geheimnisse eines Unternehmens verwahrt, ist diese Häufigkeit ein schwerwiegendes Argument. Es reicht nicht zu sagen, GitLab korrigiert schnell, auch wenn es das tut. Wer alles im eigenen Haus behalten will, muss eine laufende Überwachung einplanen oder sie jemandem übergeben, der das hauptberuflich macht.
Häufige Fragen
Muss ich GitLab sofort aktualisieren?
Ja, wenn deine Instanz selbst gehostet ist und eine der genannten Versionen nutzt. GitLab empfiehlt die sofortige Aktualisierung auf 19.4.2, 19.3.5 oder 19.2.8. Die aktive Ausnutzung ist durch die CISA bestätigt.
Ist GitLab.com gefährdet?
Laut GitLab nicht. GitLab.com nutzt bereits die korrigierte Version, und die Dedicated-Mandanten wurden vor dem öffentlichen Release aktualisiert.
Braucht man ein Konto, um die Lücke auszunutzen?
Nein. Der CVSS-Vektor sieht keine Rechte und keine Benutzerinteraktion vor. Der Angriff läuft über eine gezielt gebaute CI/CD-Konfiguration.
Wie erkenne ich, ob ich angegriffen wurde?
Die Quellen nennen keinen sicheren Weg. GitLab hat sechs Erkennungsregeln für selbst gehostete Instanzen veröffentlicht. Alpine bemerkte wiederholte Abstürze der Worker nach ungewöhnlichen CI-Konfigurationen.
Reicht ein Update aus?
Das hängt davon ab. War die Instanz offen erreichbar und in den letzten Tagen nicht gepatcht, kannst du eine Kompromittierung nicht ausschließen. Alpine hat sich dafür entschieden, sie von Grund auf neu aufzubauen.
Worauf du in den kommenden Wochen achten solltest, zwischen Patch und Kontrolle
In den nächsten Tagen ist entscheidend, ob weitere Fälle neben Alpine auftauchen und ob technische Details veröffentlicht werden. Drei Empfehlungen.
- Aktualisiere auf die neueste verfügbare Version deines Zweigs und prüfe die Versionsnummer nach der Installation.
- Kontrolliere die Logs der Worker auf wiederholte Abstürze und ungewöhnliche CI-Konfigurationen und nutze dafür die Erkennungsregeln von GitLab.
- War die Instanz offen erreichbar und nicht aktualisiert, rotiere Tokens und geschützte Variablen und prüfe einen Neuaufbau.
