Am 21. Oktober 2026 hat GitLab einen außerplanmäßigen kritischen Patch-Release veröffentlicht. Er schließt zwölf Sicherheitslücken, die gefährlichste heißt CVE-2026-110264. Wir nennen sie „RegExplode“. Ein Fehler im Regex-Compiler von GitLab ermöglicht es Angreifern ohne Benutzerkonto, unter bestimmten Bedingungen beliebigen Code auf dem GitLab-Server auszuführen. GitLab bewertet die Lücke mit dem Höchstwert CVSS 10.0.
Wenn Ihr Unternehmen GitLab selbst betreibt, sollten Sie das Update nicht auf das nächste Wartungsfenster verschieben.
Was ist passiert?
GitLab nutzt reguläre Ausdrücke (Regex) an vielen Stellen, zum Beispiel beim Darstellen von Inhalten und beim Auswerten von Konfigurationen. Im zuständigen Regex-Compiler steckt ein Integer Overflow: Bei einem gezielt präparierten Ausdruck läuft ein Zahlenwert über und der Speicher gerät durcheinander. Laut GitLab kann ein nicht angemeldeter Angreifer darüber Code auf dem Server ausführen. Gemeldet wurde der Fehler über das Bug-Bounty-Programm von GitLab auf HackerOne.
Behoben wird das Problem unter anderem durch Patches an der Regex-Engine von Ruby, auf der GitLab aufbaut. Einen Workaround ohne Update nennt GitLab nicht.
Bemerkenswert ist die Vorgeschichte: Erst am 12. Oktober 2026 hat GitLab eine andere Regex-Lücke mit CVSS 10.0 geschlossen (CVE-2026-97229, CI/CD-Konfigurationen). Für diese ältere Lücke gibt es laut Rapid7 bereits einen öffentlichen Proof of Concept. Zwei Höchstwert-Lücken in zehn Tagen zeigen, dass Sicherheitsforscher diesen Teil von GitLab gerade genau untersuchen, Angreifer vermutlich auch.
Im selben Release stecken weitere relevante Fixes, darunter:
- CVE-2026-15723 (CVSS 8.2): Kontoübernahme, wenn SAML- und LDAP-Auto-Linking gleichzeitig aktiv sind.
- CVE-2026-112212 (CVSS 7.5): Cache Poisoning der OAuth/OIDC-Discovery, mit dem sich Anmeldeflüsse auf fremde Server umleiten lassen.
Wer ist betroffen?
Betroffen sind selbst betriebene Installationen von GitLab Community Edition (CE) und Enterprise Edition (EE), egal ob auf eigener Hardware, als VM oder im Container. GitLab.com und GitLab Dedicated hat GitLab bereits selbst gepatcht.
| Release-Linie | Gefixt ab |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
| älter als 18.11 | kein Fix, Upgrade nötig |
Stand 22. Oktober war laut GitLab und Fachpresse keine aktive Ausnutzung bekannt, auch kein öffentlicher Exploit. Die Shadowserver Foundation zählt aber rund 2.700 GitLab-CE-Instanzen, die direkt aus dem Internet erreichbar sind. Das zeigt, wie viele Systeme ein Ziel sein könnten.
Für Unternehmen ist ein GitLab-Server ein besonders lohnendes Ziel: Dort liegen Quellcode, CI/CD-Pipelines, Zugangsdaten für Server und Cloud sowie oft Deployment-Schlüssel für die Produktion. Wer GitLab übernimmt, hat häufig auch den Weg in den Rest der Infrastruktur.
Was Sie jetzt tun sollten
- Version prüfen: Als Administrator unter Hilfe → Hilfe (
/help) oder mitsudo gitlab-rake gitlab:env:infoauf dem Server. - Backup anlegen: Vor dem Update ein aktuelles Backup erstellen (
sudo gitlab-backup create) und zusätzlich/etc/gitlab/gitlab.rbund/etc/gitlab/gitlab-secrets.jsonsichern. - Sofort aktualisieren auf die passende Version aus der Tabelle, beim Omnibus-Paket über den Paketmanager Ihrer Distribution, bei Docker über das neue Image-Tag. Hinweis: 19.4.3 und 19.3.6 enthalten Datenbank-Migrationen. Einzelne Server sind während des Updates kurz nicht erreichbar, Installationen mit mehreren Knoten lassen sich ohne Ausfallzeit aktualisieren.
- Ältere Versionen (vor 18.11): Hier gibt es keinen Patch. Planen Sie das Upgrade entlang des offiziellen Upgrade-Pfads von GitLab, Versionen lassen sich nicht beliebig überspringen.
- Angriffsfläche verkleinern: GitLab nach Möglichkeit nur über VPN oder Zero-Trust-Zugang erreichbar machen und die offene Selbstregistrierung deaktivieren, wenn Sie sie nicht brauchen.
- Logs prüfen: GitLab hat Erkennungsregeln veröffentlicht, unter anderem für Abstürze des „Onigmo native worker“ und gehäufte „Org mode render errors“. Fallen Ihnen solche Muster aus den letzten Tagen auf, behandeln Sie das System als möglicherweise kompromittiert und tauschen Sie Tokens, Runner-Registrierungen und in CI/CD hinterlegte Zugangsdaten aus.
Wie Sadeem hilft
Wir betreiben GitLab, CI/CD-Pipelines und die Server dahinter für mittelständische Unternehmen, auf Wunsch vollständig in Deutschland bzw. der EU. Wir prüfen Ihre Installation, spielen Updates kontrolliert mit Backup und Rückfallplan ein und sichern den Zugang so ab, dass interne Werkzeuge nicht offen im Internet stehen. Mit Managed Hosting müssen Sie bei der nächsten kritischen Lücke nicht selbst aktiv werden.
Sie sind unsicher, ob Ihr GitLab betroffen ist? Sprechen Sie uns im kostenlosen Erstgespräch an.