CVE-2026-110264: Kritische GitLab RCE-Schwachstelle betrifft 12 Jahre von Veröffentlichungen

GitLab hat dringende Sicherheitsupdates veröffentlicht, die CVE-2026-110264 behandeln, eine Schwachstelle mit maximaler Schwere, die es einem nicht authentifizierten Angreifer ermöglichen könnte, beliebigen Code auf gefährdeten selbstverwalteten GitLab-Servern auszuführen. Der Fehler hat einen CVSS-Wert von 10,0 und betrifft sowohl die GitLab Community Edition (CE) als auch die Enterprise Edition (EE).

Die Schwachstelle ist besonders bemerkenswert, da der betroffene Code bis GitLab 7.0, veröffentlicht 2014, zurückreicht. Dies lässt ungefähr 12 Jahre GitLab-Veröffentlichungen innerhalb des gefährdeten Bereichs, obwohl es derzeit keine Hinweise darauf gibt, dass Angreifer die Schwäche in dieser Zeit aktiv ausgenutzt haben. GitLab hat das Problem offengelegt und gepatchte Versionen am 21. Oktober 2026 veröffentlicht.

Die Schwachstelle stammt aus einem Integer-Overflow, der ausgelöst wird, während GitLab einen speziell gestalteten regulären Ausdruck kompiliert. Unter bestimmten Bedingungen könnte ein nicht authentifizierter Angreifer diese Bedingung nutzen, um beliebigen Code auf dem zugrunde liegenden GitLab-Server auszuführen. GitLab hat den vollständigen Exploit-Pfad und spezifische Voraussetzungen absichtlich zurückgehalten, während Administratoren Patches implementieren.

Für Organisationen, die eine selbstverwaltete GitLab-Infrastruktur betreiben, ist das potenzielle Risiko schwerwiegend. GitLab-Repositories enthalten häufig Quellcode, CI/CD-Konfiguration, Deployment-Geheimnisse, Zugriffstoken, Infrastrukturbeschreibungen und Verbindungen zu Produktionsumgebungen. Eine Kompromittierung auf Server-Ebene könnte daher Möglichkeiten für Credential-Diebstahl, Repository-Manipulation, Lieferkettenangriffe, Persistenz oder seitliche Bewegungen schaffen.

Sicherheitsteams, die nach Erkennungsgelegenheiten für CVE-2026-110264 suchen, können die AI-Native Detection Intelligence Platform von SOC Prime nutzen, um die Sichtbarkeit von Ausnutzung und damit verbundenem Verhalten nach der Kompromittierung über SIEM-, EDR- und Data-Lake-Umgebungen zu verbessern.

Klicken Sie Erkennungen erkunden um auf relevante Erkennungsinhalte und Jagdlogik zuzugreifen. Um Ausnutzungsversuche von CVE-2026-110264 zu erkennen, sollten Verteidiger GitLab-Anwendungs-Telemetrie mit Prozessausführung, abnormalem Serververhalten und GitLabs neu veröffentlichten Bedrohungserkennungslogik korrelieren.

Sicherheitspraktiker können auch Prime Architect nutzen, um aufkommende Schwachstelleninformationen in Sigma-Regeln und Jagd-Abfragen zu transformieren, Erkennungslogik zu validieren, relevante Angriffsflüsse zu generieren und Erkennungsinhalte über unterstützte Sicherheitsplattformen hinweg zu übersetzen.

Kontakt Verkauf

CVE-2026-110264 Analyse

GitLab beschreibt die Schwachstelle als einen Integer-Overflow in seinem Compiler für reguläre Ausdrücke. Unter bestimmten Bedingungen kann das Kompilieren eines speziell gestalteten regulären Ausdrucks zu einer Ausführung von beliebigem Code auf dem GitLab-Server ohne Authentifizierung führen.

GitLab hat der Schwachstelle den maximalen CVSS v3.1-Wert von 10,0 zugewiesen, mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Dies spiegelt eine netzwerkzugängliche Schwachstelle mit geringer Angriffskomplexität, ohne erforderliche Privilegien und Benutzerinteraktion wider, mit potenziell hohen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Der Sicherheitsforscher joaxcar entdeckte und meldete die Schwachstelle über das HackerOne-Bug-Bounty-Programm von GitLab. Die Release Notes von GitLab verweisen auch auf Patches zur Behandlung von regulären Ausdrücken in Ruby, während Berichte darauf hinweisen, dass der betroffene zugrundeliegende Motor Onigmo, die reguläre Ausdrucks-Implementierung von Ruby, ist, die in GitLab-Paketen gebündelt ist.

CVE-2026-110264 betrifft GitLab CE und EE in einem ungewöhnlich breiten Bereich:

• GitLab 7.0 bis Versionen vor 18.11.13
• GitLab 19.0 vor 19.0.10
• GitLab 19.1 vor 19.1.9
• GitLab 19.2 vor 19.2.9
• GitLab 19.3 vor 19.3.6
• GitLab 19.4 vor 19.4.3
• GitLab 19.5 vor 19.5.1

GitLab hat die Fehlerbehebung auf 18.11.13, 19.0.10, 19.1.9 und 19.2.9 zusätzlich zu seinen normalerweise unterstützten Patch-Zweigen aus Sicherheitsgründen und aufgrund der ungewöhnlich breiten Exposition zurückportiert.

Das lange verwundbare Fenster bedeutet nicht, dass der Fehler seit 2014 aktiv ausgenutzt wurde. Vielmehr existierte die verwundbare Funktionalität der regulären Ausdrücke in Veröffentlichungen, die bis GitLab 7.0 zurückgehen. Weder GitLab noch die zwei beigelegten Berichte haben bisher eine Ausnutzung in realen Angriffen bis zum 22. Oktober 2026 bestätigt.

Diese Schwachstelle sollte nicht mit CVE-2026-97229 verwechselt werden, einer anderen kritischen Schwachstelle zur Remotecodeausführung in GitLab, die im Zusammenhang mit der Verarbeitung regulärer Ausdrücke steht und Anfang Oktober gepatcht wurde. Dieses Problem betraf einen engeren Bereich neuerer Veröffentlichungen. Die Installation der Korrekturen vom 12. Oktober schützt Systeme nicht automatisch vor dieser neu offengelegten Schwachstelle.

Administratoren, die GitLab kürzlich aktualisiert haben, müssen daher ihre tatsächlich installierte Version überprüfen, anstatt anzunehmen, dass ein früherer Sicherheitsrelease im Oktober ausreichenden Schutz bietet.

Die derzeit verfügbaren Details zu CVE-2026-110264 legen nicht offen, welches genau vom Angreifer kontrollierte Eingabefeld, Endpunkt, Feature oder Bedingungen erforderlich sind, um den verwundbaren Compiler für reguläre Ausdrücke zu erreichen. GitLab macht allgemeine Sicherheitsfragen normalerweise 90 Tage nach der Veröffentlichung mit einer Lösung öffentlich, um die sofortige Verfügbarkeit von ausnutzbaren technischen Informationen zu reduzieren, während Kunden Patches implementieren.

In den bereitgestellten Berichten oder der GitLab-Advisory wurde kein öffentlicher PoC für CVE-2026-110264 veröffentlicht. Die Cybersecurity News stellt speziell fest, dass GitLab noch keinen öffentlichen Exploit veröffentlicht hat, während das Unternehmen die Offenlegung des vollständigen Angriffswegs im Rahmen hält.

Gleichzeitig sollte das Fehlen eines öffentlichen Proof of Concept nicht als geringes Risiko interpretiert werden. Eine remote erreichbare, nicht authentifizierte Schwachstelle mit einer CVSS-Wertung von 10,0 stellt ein attraktives Ziel dar, insbesondere da selbstverwaltete GitLab-Server häufig dem Internet ausgesetzt sind.

Derzeit gibt es keine kampagnenspezifischen IOCs zu CVE-2026-110264 wie bösartige IP-Adressen, Domains, Payload-Hashes oder bestätigte Exploit-Anforderungsmuster, da weder GitLab noch die zitierten Sicherheitsforscher eine aktive Ausnutzung gemeldet haben.

GitLab hat jedoch zwei Bedrohungserkennungen veröffentlicht, die auf mögliche Ausnutzungsversuche bei selbstverwalteten Installationen abzielen:

• Onigmo native worker crash
• Org-Modus-Darstellungsfehler-Burst

Diese Erkennungen sind darauf ausgelegt, verdächtiges Verhalten im Zusammenhang mit Versuchen, die Schwachstelle auszulösen, zu identifizieren. Ihre bloße Anwesenheit bestätigt nicht von selbst eine erfolgreiche Kompromittierung und sollte mit weiterreichender Anwendungs- und Endpunkt-Telemetrie korreliert werden.

Sicherheitsteams sollten unerwartete Abstürze von GitLab-Anwendungen, Anstiege von Darstellungsfehlern, anomale Prozesse ausgehend von GitLab oder Ruby-Komponenten, unerwartete Shell-Ausführung, neu geschaffene Persistenzmechanismen und ausgehende Verbindungen von GitLab-Servern untersuchen, die von normalen Betriebsmustern abweichen.

CVE-2026-110264 Abschwächung

GitLab empfiehlt dringend, dass alle Organisationen, die betroffene selbstverwaltete Installationen betreiben, sofort upgraden. Die behobenen Versionen sind:

GitLab.com wurde bereits aktualisiert. GitLab Dedicated-Tenants, die interne Versionen 19.3.5-internal0, 19.4.2-internal0 oder höher nutzen, enthalten bereits die erforderlichen Fixes und müssen in Bezug auf diese Schwachstelle nicht aktiv werden.

Selbstverwaltete Kunden sollten die Behebung nicht verzögern, während sie auf weitere Details zur Ausnutzung warten. GitLab hat keinen alternativen Workaround veröffentlicht, der einen gleichwertigen Schutz bietet, weshalb die Installation der behobenen Version der zuverlässige Weg zur Behebung ist.

Vor dem Upgrade sollten Administratoren GitLabs Upgrade-Dokumentation überprüfen und Datenbankmigrationen berücksichtigen. GitLab warnt, dass bei Single-Node-Deployments möglicherweise Ausfallzeiten auftreten, während Migrationen abgeschlossen werden, wohingegen ordnungsgemäß konfigurierte Multi-Node-Umgebungen dem Null-Downtime-Upgrade-Prozess des Anbieters folgen können. Versionen 19.3.6 und 19.4.3 enthalten reguläre Migrationen, und 19.4.3 beinhaltet auch eine nachbereitende Migration.

Nach dem Patchen sollten Sicherheitsteams eine retrospektive Analyse durchführen, anstatt das Update selbst als Beweis dafür zu behandeln, dass ein Server nie ins Visier genommen wurde. Überprüfen Sie GitLab-Anwendungsprotokolle auf die zwei von GitLab veröffentlichten Ausnutzungsindikatoren und untersuchen Sie verdächtige Aktivitäten, die dem Upgrade vorausgingen.

Verteidiger sollten auch die Betriebssystem-Telemetrie untersuchen für:

• Unerwartete Kindprozesse, die von GitLab, Ruby oder zugehörigen Arbeitern ausgehen
• Shell- oder Skriptinterpreter-Ausführung unter GitLab-Dienstkonten
• Neue SSH-Schlüssel oder Administratorkonten
• Unerwartete Modifikationen an Repositories oder CI/CD-Pipelines
• Neu erstellte geplante Jobs oder Persistenzmechanismen
• Änderungen an Läufern, Deployment-Tokens, persönlichen Zugriffstoken und Projektzugriffstoken
• Ungewöhnliche ausgehende Verbindungen vom GitLab-Server
• Unberechtigter Zugriff auf in CI/CD-Variablen gespeicherte Geheimnisse
• Unerwartete Paket-, Release- oder Repository-Änderungen

Wenn ein Kompromiss vermutet wird, sollten Organisationen den Server isolieren, Protokolle und forensische Artefakte erhalten, potenziell exponierte Anmeldedaten und Token drehen und die Integrität der Repositories und CI/CD-Workflows validieren, bevor die Instanz wieder in Betrieb genommen wird.

Da GitLab-Installationen häufig als vertrauenswürdige Infrastruktur innerhalb von Softwareentwicklungs-Pipelines agieren, sollten Einsatzkräfte auch feststellen, ob ein Angreifer Quellcode, Artefakte, Containerbilder, Vorlagen für Infrastruktur als Code oder Deployment-Workflows modifiziert haben könnte. Ein kompromittierter GitLab-Server kann selbst nach der ursprünglichen Behebung ein Risiko für die Lieferkette nach unten generieren.

Die AI-Native Detection Intelligence Platform von SOC Prime kann Organisationen helfen, ihre Erkennungsfähigkeiten gegen aufkommende Schwachstellenausnutzungen zu stärken, indem sie kontinuierlich aktualisierte, verhaltensbasierte Erkennungsinhalte bereitstellt, die auf MITRE ATT&CK® abgebildet sind.

Haftungsausschluss: Erkennungsinhalte sind möglicherweise nicht für jedes CVE verfügbar. Überprüfen Sie die SOC Prime Platform auf aktuelle Abdeckung. Wenn derzeit keine relevanten Erkennungen verfügbar sind, schauen Sie später nach, da kontinuierlich neue Bedrohungsinformationen und Erkennungsinhalte hinzugefügt werden.