← Zur Übersicht aller Beiträge
GitLab schließt kritische RCE: Selbst betriebene Instanzen sofort aktualisieren
GitLab behebt mit sieben Patchständen eine kritische Schwachstelle, über die Angreifer ohne Anmeldung Code auf selbst betriebenen Servern ausführen können. CERT-EU rät zusätzlich zur Prüfung auf Kompromittierung.
GitLab schließt kritische RCE: Selbst betriebene Instanzen sofort aktualisieren
GitLab behebt mit sieben Patchständen eine kritische Schwachstelle, über die Angreifer ohne Anmeldung Code auf selbst betriebenen Servern ausführen können. CERT-EU rät zusätzlich zur Prüfung auf Kompromittierung.
GitLab hat Sicherheitsupdates gegen eine mit dem Höchstwert CVSS 10,0 bewertete Schwachstelle veröffentlicht. CVE-2026-110264 kann unter bestimmten Bedingungen dazu führen, dass ein nicht angemeldeter Angreifer durch einen präparierten regulären Ausdruck beliebigen Code auf einem GitLab-Server ausführt. Betroffen sind selbst betriebene Community- und Enterprise-Installationen über zahlreiche Versionsreihen hinweg.
Der Hersteller nennt 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 und 19.5.1 als korrigierte Patchstände. GitLab.com läuft nach Herstellerangaben bereits mit der Korrektur. Auch GitLab-Dedicated-Umgebungen ab den genannten internen Ständen seien abgesichert. Für selbst verwaltete Installationen empfiehlt GitLab dagegen ein sofortiges Upgrade.
Welche Versionen betroffen sind
Nach der Herstellerwarnung reicht der betroffene Bereich von GitLab CE/EE 7.0 bis vor 18.11.13. Hinzu kommen die Zweige 19.0 bis vor 19.0.10, 19.1 bis vor 19.1.9, 19.2 bis vor 19.2.9, 19.3 bis vor 19.3.6, 19.4 bis vor 19.4.3 sowie 19.5 bis vor 19.5.1.
Die Ursache liegt in einem Ganzzahlüberlauf beim Übersetzen eines speziell gestalteten regulären Ausdrucks. GitLab beschreibt eine mögliche Codeausführung ohne Anmeldung; CERT-EU bestätigt Einstufung, Versionsbereiche und Patchstände. Eine pauschale Behauptung, die neue Lücke werde bereits aktiv ausgenutzt, lässt sich daraus nicht ableiten. Die Behörde empfiehlt aber ausdrücklich, exponierte Systeme zu priorisieren und auf Anzeichen einer Kompromittierung zu prüfen.
Update allein schließt die Rückschau nicht ab
GitLab hat zwei Erkennungsregeln für mögliche Ausnutzungsversuche veröffentlicht: Sie beziehen sich auf Abstürze eines Onigmo-Workers und ungewöhnliche Häufungen von Fehlern beim Rendern von Org-Mode-Inhalten. Solche Signale sind Anhaltspunkte, kein alleiniger Beweis für einen erfolgreichen Angriff.
Für Betreiber ergibt sich deshalb ein zweistufiges Vorgehen. Zuerst muss der tatsächlich laufende Patchstand jeder selbst betriebenen Instanz festgestellt und auf eine korrigierte Version angehoben werden. Anschließend gehören Herstellerdetektionen, Anwendungs- und Systemprotokolle sowie unerwartete Prozesse oder Dateien in die Prüfung. Bei Internet-Erreichbarkeit und ungeklärtem Patchzeitpunkt hat diese Rückschau besondere Priorität.
Das Update kann Betriebsunterbrechungen verursachen: GitLab weist darauf hin, dass die enthaltenen Datenbankmigrationen bei Einzelknoten-Installationen Ausfallzeit bedeuten können. Mehrknoten-Umgebungen lassen sich mit dem vorgesehenen Zero-Downtime-Verfahren aktualisieren. Der Wartungsplan sollte diesen Unterschied berücksichtigen, ohne die Sicherheitskorrektur aufzuschieben.
Eigene GitLab-Instanzen und Dienstleister getrennt behandeln
Nicht jedes Unternehmen betreibt GitLab selbst. Für GitLab.com nennt der Hersteller bereits den korrigierten Stand; bei selbst gehosteten oder durch einen Dienstleister verwalteten Instanzen ist dagegen ein konkreter Versionsnachweis nötig. Eine allgemeine Aussage wie „GitLab ist aktuell“ reicht nicht, wenn mehrere Umgebungen, Testsysteme oder ältere interne Instanzen existieren.
Die Meldung ist von PHP2Shell und Node2Shell unabhängig. Dort betreffen die Schwachstellen PHP- beziehungsweise Node.js-Laufzeiten. CVE-2026-110264 betrifft GitLab selbst und damit insbesondere Entwicklungs-, Quellcode- und CI/CD-Infrastruktur. Das materielle Delta sind ein eigener Angriffsweg, eigene Patchstände und eine gesonderte Kompromittierungsprüfung.
Konzept und redaktionelle Auswahl basieren auf Vorgaben von Christian Hohlfeld; Recherche und Formulierung wurden durch KI unterstützt. Eine individuelle menschliche Freigabe steht noch aus.
GitLab hat Sicherheitsupdates gegen eine mit dem Höchstwert CVSS 10,0 bewertete Schwachstelle veröffentlicht. CVE-2026-110264 kann unter bestimmten Bedingungen dazu führen, dass ein nicht angemeldeter Angreifer durch einen präparierten regulären Ausdruck beliebigen Code auf einem GitLab-Server ausführt. Betroffen sind selbst betriebene Community- und Enterprise-Installationen über zahlreiche Versionsreihen hinweg.
Der Hersteller nennt 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 und 19.5.1 als korrigierte Patchstände. GitLab.com läuft nach Herstellerangaben bereits mit der Korrektur. Auch GitLab-Dedicated-Umgebungen ab den genannten internen Ständen seien abgesichert. Für selbst verwaltete Installationen empfiehlt GitLab dagegen ein sofortiges Upgrade.
Welche Versionen betroffen sind
Nach der Herstellerwarnung reicht der betroffene Bereich von GitLab CE/EE 7.0 bis vor 18.11.13. Hinzu kommen die Zweige 19.0 bis vor 19.0.10, 19.1 bis vor 19.1.9, 19.2 bis vor 19.2.9, 19.3 bis vor 19.3.6, 19.4 bis vor 19.4.3 sowie 19.5 bis vor 19.5.1.
Die Ursache liegt in einem Ganzzahlüberlauf beim Übersetzen eines speziell gestalteten regulären Ausdrucks. GitLab beschreibt eine mögliche Codeausführung ohne Anmeldung; CERT-EU bestätigt Einstufung, Versionsbereiche und Patchstände. Eine pauschale Behauptung, die neue Lücke werde bereits aktiv ausgenutzt, lässt sich daraus nicht ableiten. Die Behörde empfiehlt aber ausdrücklich, exponierte Systeme zu priorisieren und auf Anzeichen einer Kompromittierung zu prüfen.
Update allein schließt die Rückschau nicht ab
GitLab hat zwei Erkennungsregeln für mögliche Ausnutzungsversuche veröffentlicht: Sie beziehen sich auf Abstürze eines Onigmo-Workers und ungewöhnliche Häufungen von Fehlern beim Rendern von Org-Mode-Inhalten. Solche Signale sind Anhaltspunkte, kein alleiniger Beweis für einen erfolgreichen Angriff.
Für Betreiber ergibt sich deshalb ein zweistufiges Vorgehen. Zuerst muss der tatsächlich laufende Patchstand jeder selbst betriebenen Instanz festgestellt und auf eine korrigierte Version angehoben werden. Anschließend gehören Herstellerdetektionen, Anwendungs- und Systemprotokolle sowie unerwartete Prozesse oder Dateien in die Prüfung. Bei Internet-Erreichbarkeit und ungeklärtem Patchzeitpunkt hat diese Rückschau besondere Priorität.
Das Update kann Betriebsunterbrechungen verursachen: GitLab weist darauf hin, dass die enthaltenen Datenbankmigrationen bei Einzelknoten-Installationen Ausfallzeit bedeuten können. Mehrknoten-Umgebungen lassen sich mit dem vorgesehenen Zero-Downtime-Verfahren aktualisieren. Der Wartungsplan sollte diesen Unterschied berücksichtigen, ohne die Sicherheitskorrektur aufzuschieben.
Eigene GitLab-Instanzen und Dienstleister getrennt behandeln
Nicht jedes Unternehmen betreibt GitLab selbst. Für GitLab.com nennt der Hersteller bereits den korrigierten Stand; bei selbst gehosteten oder durch einen Dienstleister verwalteten Instanzen ist dagegen ein konkreter Versionsnachweis nötig. Eine allgemeine Aussage wie „GitLab ist aktuell“ reicht nicht, wenn mehrere Umgebungen, Testsysteme oder ältere interne Instanzen existieren.
Die Meldung ist von PHP2Shell und Node2Shell unabhängig. Dort betreffen die Schwachstellen PHP- beziehungsweise Node.js-Laufzeiten. CVE-2026-110264 betrifft GitLab selbst und damit insbesondere Entwicklungs-, Quellcode- und CI/CD-Infrastruktur. Das materielle Delta sind ein eigener Angriffsweg, eigene Patchstände und eine gesonderte Kompromittierungsprüfung.
Quellen
Transparenz: Konzept, Auswahlkriterien und inhaltliche Vorgaben stammen von Christian Hohlfeld. Recherche und Formulierung wurden nach diesen Vorgaben mit KI-Werkzeugen unterstützt. Redaktionell geprüft und freigegeben von Christian Heinrich Hohlfeld am .