GitLab CVE-2026-110264: Codeausführung ohne Login, CVSS 10

GitLab hat am 21. Oktober 2026 außerplanmäßig die Versionen 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13 für Community Edition (CE) und Enterprise Edition (EE) veröffentlicht. Kern des Patch-Release ist CVE-2026-110264 mit dem Höchstwert CVSS 10.0: Unter bestimmten Bedingungen kann ein nicht angemeldeter Angreifer beliebigen Code auf dem GitLab-Server ausführen. Betroffen sind laut Hersteller alle Versionen ab 7.0 bis vor die genannten Patch-Stände.

Handeln müssen nur Betreiber selbst gehosteter Instanzen (Self-Managed, also Omnibus, Docker, Helm oder Quellinstallation). GitLab.com läuft bereits gepatcht, GitLab Dedicated ist ab 19.3.5-internal0 beziehungsweise 19.4.2-internal0 abgesichert. Für Self-Managed gilt: heute patchen, nicht auf das nächste Wartungsfenster warten. Hinweise auf eine Ausnutzung gibt es bislang nicht.

Was ist passiert?

Laut Advisory entsteht beim Kompilieren eines speziell präparierten regulären Ausdrucks ein Integer Overflow. Die Bug-Fix-Listen aller sieben Versionen enthalten dazu Patches für die Regex-Komponente von Ruby. The Hacker News ordnet die Schwachstelle der Ruby-Regex-Engine Onigmo zu, die GitLab in seinen Paketen mitliefert und selbst patcht. Das erklärt, warum die Lücke bis Version 7.0 aus dem Jahr 2014 zurückreicht.

Welche Bedingungen für einen Angriff erfüllt sein müssen, nennt GitLab nicht. Einen Workaround enthält das Advisory ebenfalls nicht. Gemeldet hat die Lücke der Forscher joaxcar über das HackerOne-Programm. Neben CVE-2026-110264 behebt das Release elf weitere Schwachstellen, darunter CVE-2026-15723 (CVSS 8.2, Kontoübernahme bei gleichzeitig aktivem SAML- und LDAP-Auto-Linking) und CVE-2026-112212 (CVSS 7.5, Cache Poisoning bei OAuth/OIDC-Discovery).

Wer ist betroffen?

Betroffen sind alle Self-Managed-Instanzen von CE und EE ab 7.0 vor 18.11.13, 19.0 vor 19.0.10, 19.1 vor 19.1.9, 19.2 vor 19.2.9, 19.3 vor 19.3.6, 19.4 vor 19.4.3 und 19.5 vor 19.5.1. Wer erst am 12. Oktober aktualisiert hat, ist damit erneut verwundbar, denn die damaligen Stände wie 19.4.2 liegen unterhalb der neuen Fix-Versionen. The Hacker News weist ausdrücklich darauf hin.

Ungewöhnlich: GitLab hat den Fix zusätzlich auf 18.11.13, 19.0.10, 19.1.9 und 19.2.9 zurückportiert. Laut The Hacker News liegen diese Zweige außerhalb der normalen Support-Policy. Nicht betroffen sind Nutzer von GitLab.com und Dedicated-Tenants auf den genannten internen Ständen.

Wie kritisch ist das?

Technisch handelt es sich um eine Remote Code Execution ohne Anmeldung über das Netzwerk (Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Ein GitLab-Server hält Quellcode, CI/CD-Variablen, Deploy-Schlüssel und Runner-Tokens, eine Übernahme reicht also weit über GitLab hinaus. Offen ist, welche Voraussetzungen ein Angriff braucht. Laut The Hacker News meldet GitLab keine Ausnutzung, und die Lücke stand am 22. Oktober nicht im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA. Eine Entwarnung ist das nicht, aber auch kein Beleg für laufende Angriffe.

Was sollten Admins jetzt tun?

• Version jeder Instanz prüfen (Admin-Bereich oder /help, bei Omnibus gitlab-rake gitlab:env:info) und mit den Fix-Ständen abgleichen, auch Instanzen mit dem Update vom 12. Oktober.
• Auf 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13 aktualisieren. Bei Docker das Image auf den passenden Tag heben und den Container neu erstellen.
• Downtime einplanen: 19.4.3 und 19.3.6 enthalten Datenbankmigrationen, Single-Node-Instanzen sind während des Updates nicht erreichbar. Multi-Node-Setups können das Zero-Downtime-Verfahren nutzen.
• Instanzen, die öffentlich erreichbar sind, zuerst patchen. Wo das heute nicht möglich ist, den Zugriff vorübergehend auf VPN oder bekannte Netze beschränken.
• Logs mit den Detection-Regeln „Onigmo native worker crash“ und „Org mode render error burst“ prüfen. Laut The Hacker News liegen sie als Sigma-Regeln im TLDR-Framework vor, Hinweise zur Erkennung bündelt GitLab in der Dokumentation zur Erkennung von Sicherheitsvorfällen.
• Vor dem Update ein Backup erstellen und dessen Wiederherstellbarkeit kennen.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen, die GitLab selbst betreiben, ist das ein klarer Fall für einen Notfallpatch. Die Kombination aus Höchstwertung, fehlender Anmeldung und Versionen bis 2014 macht praktisch jede nicht aktualisierte Instanz zum Kandidaten. Nach Angaben von The Hacker News ist es bereits die vierte Codeausführungslücke im Regex-Umfeld von GitLab innerhalb eines Monats. Wer GitLab einsetzt, sollte Updates deshalb nicht mehr manuell nachziehen, sondern einen festen, kurzen Patch-Prozess etablieren. Frühere Fälle wie die Befehlsausführung im AI Gateway zeigen dasselbe Muster.

Passende Anleitungen auf S-EDV

• GitLab CE mit Docker betreiben: Installation, Backup und Update-Weg per Image-Tag.
• Wazuh als SIEM mit Docker: GitLab-Logs zentral sammeln und auf Auffälligkeiten prüfen.

Quellen

• GitLab: Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (21.10.2026)
• The Hacker News: Kritische GitLab-Lücke mit CVSS 10.0 (22.10.2026)
• GitLab Docs: Security incident detection