GitLab-Schwachstelle könnte RCE ohne Authentifizierung ermöglichen
Die GitLab-Schwachstelle CVE-2026-110264 könnte remote code execution (RCE) ohne Authentifizierung ermöglichen. Das bedeutet, dass ein Angreifer möglicherweise Befehle auf einem self-managed Server ausführen kann, ohne sich zuvor anzumelden. GitLab bewertete die Schwachstelle nach dem Common Vulnerability Scoring System (CVSS) mit 10.0, der Höchstwertung der Skala, und veröffentlichte am 21. Oktober Fixes. Jedes GitLab-Release ab Version 7.0, die 2014 erschien, ist betroffen, sofern es nicht auf eine der neu gepatchten Versionen aktualisiert wurde.
Die Schwachstelle entsteht durch einen integer overflow, einen Fehler, der auftritt, wenn eine Zahl den für sie reservierten Speicherplatz überschreitet, während die in Ruby integrierte Onigmo-Engine eine speziell erstellte regular expression kompiliert. Der Begriff regular expression bezeichnet ein Muster, mit dem Software übereinstimmende Textbestandteile findet oder verarbeitet. GitLab integriert Onigmo in seine eigenen Packages und wendet in seinen Builds Patches auf die Engine an. Da die betroffene Komponente seit Version 7.0 mit GitLab ausgeliefert wird, erstreckt sich das Risiko auf mehr Release-branches als im üblichen Security-Support-Zeitraum des Unternehmens.
GitLab zufolge ist eine Ausnutzung nur unter bestimmten Bedingungen möglich, hat diese Bedingungen jedoch nicht offengelegt. Daher können Administratoren nicht allein anhand ihrer Konfiguration feststellen, ob eine Installation angegriffen werden kann. Der Sicherheitshinweis nennt keinen vorübergehenden Workaround. Die Installation eines korrigierten Release ist somit der einzige sichere Schutz, den GitLab angibt.
Die erforderliche Zielversion hängt vom derzeit installierten branch ab. Systeme mit 19.5 vor 19.5.1 sollten auf 19.5.1 wechseln. Installationen von Version 19.4 vor 19.4.3 benötigen 19.4.3, während Installationen von 19.3 vor 19.3.6 die Version 19.3.6 benötigen. Administratoren mit 19.2 vor 19.2.9 sollten 19.2.9 installieren, Betreiber von 19.1 vor 19.1.9 sollten 19.1.9 installieren und Betreiber von 19.0 vor 19.0.10 sollten 19.0.10 installieren. Alle betroffenen Releases von 7.0 bis einschließlich 18.11 müssen auf 18.11.13 aktualisiert werden.
Vier dieser Fixes liegen außerhalb der normalen Wartungsrichtlinie von GitLab. Das Unternehmen patcht üblicherweise das aktuelle monatliche Release und die beiden unmittelbar vorhergehenden Releases, zu diesem Zeitpunkt also 19.5, 19.4 und 19.3. Aufgrund des Schweregrads von CVE-2026-110264 stellte GitLab die Korrektur zusätzlich für 18.11.13, 19.0.10, 19.1.9 und 19.2.9 bereit.
Administratoren, die die GitLab-Sicherheitsupdates vom 12. Oktober installiert haben, müssen dennoch handeln. Diese früheren Patches deckten nur die Versionen ab 19.2 ab und verwendeten die Releases 19.2.8, 19.3.5 und 19.4.2. Die Fixes vom 21. Oktober liegen jeweils ein Patch-Level über diesen Versionen. Ein am 12. Oktober aktualisierter Server kann daher weiterhin für CVE-2026-110264 anfällig sein.
Nur self-managed GitLab-Installationen müssen von Kunden aktualisiert werden. GitLab.com verwendet bereits eine korrigierte Version. GitLab Dedicated-Umgebungen mit den internen Releases 19.3.5-internal0 und 19.4.2-internal0 oder neueren Versionen enthalten die Korrektur ebenfalls.
GitLab meldete keine Hinweise darauf, dass CVE-2026-110264 bei Angriffen ausgenutzt wurde. Mit Stand vom 22. Oktober war die Schwachstelle außerdem nicht im Katalog der U.S. Cybersecurity and Infrastructure Security Agency für bekanntermaßen ausgenutzte Schwachstellen aufgeführt. GitLab veröffentlichte dennoch zwei Regeln, mit denen sich seine Anwendungslogs auf mögliche Versuche untersuchen lassen. Die Regeln heißen „Onigmo native worker crash“ und „Org mode render error burst“, sind über GitLabs Open-Source-Framework TLDR verfügbar und verwenden Sigma, ein Standardformat zur Beschreibung verdächtiger Log-Aktivitäten.
Dies ist die vierte Code-Execution-Schwachstelle in GitLabs regular expression-Engine, die derselbe Sicherheitsforscher innerhalb eines Monats gemeldet hat, und die erste dieser vier Schwachstellen, die Releases vor 19.2 betrifft. Am 12. Oktober korrigierte GitLab CVE-2026-97229, eine weitere nicht authentifizierte integer overflow-Schwachstelle mit einer Bewertung von 10.0, in den Versionen 19.2.8, 19.3.5 und 19.4.2. Am 23. September behob das Unternehmen CVE-2026-93577 und CVE-2026-89078. Beide erhielten eine Bewertung von 9.9 und setzten voraus, dass der Angreifer über ein angemeldetes Konto verfügte. Diese drei früheren Schwachstellen betrafen keine Versionen vor 19.2.
Das Release vom 21. Oktober behebt insgesamt elf Sicherheitsprobleme: eine kritische Schwachstelle sowie zehn Probleme mit hohem, mittlerem oder niedrigem Schweregrad. Eine der zusätzlichen Schwachstellen mit hohem Schweregrad, CVE-2026-15723, hat eine Bewertung von 8.2 und könnte es einem authentifizierten Benutzer ermöglichen, ein anderes Konto zu übernehmen. Sie betrifft nur Konfigurationen, in denen ein Administrator die automatische Kontoverknüpfung sowohl für Security Assertion Markup Language (SAML) als auch für Lightweight Directory Access Protocol (LDAP) aktiviert hat. Dabei handelt es sich um zwei Technologien zur Verknüpfung von Anmeldeidentitäten.
Ein weiteres Problem mit hohem Schweregrad, CVE-2026-112212, ist eine mit 7.5 bewertete cache-poisoning-Schwachstelle. Sie betrifft die endpoints von GitLab für OAuth und OpenID Connect, die an Anmeldung und Kontoautorisierung beteiligt sind. In Konfigurationen mit einem gemeinsam genutzten cache könnte ein Angreifer bestimmte Anmeldeabläufe auf einen Server unter seiner Kontrolle umleiten.
Eine sorgfältige Upgrade-Planung ist besonders für Administratoren von Single-Node-Systemen wichtig. GitLab zufolge enthalten die Versionen 19.4.3 und 19.3.6 Datenbankänderungen, die während der Installation ausgeführt werden. Dadurch entsteht bei einem Server mit nur einem node eine Ausfallzeit, bis diese Änderungen abgeschlossen sind. Multi-Node-Deployments können das zero-downtime upgrade procedure von GitLab verwenden. Organisationen, die Unterstützung beim Management dieser Art von Infrastrukturrisiko benötigen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen.
Betreiber von self-managed Installationen sollten ihren genauen branch ermitteln, das entsprechende korrigierte Release auswählen und alle erforderlichen Ausfallzeiten einplanen. Dass bislang keine Ausnutzung beobachtet wurde, ändert weder den Bereich der betroffenen Versionen noch die Notwendigkeit, das Update vom 21. Oktober zu installieren.