GitLab-Administratoren, die ihre Server am 12. Oktober gepatcht haben, müssen sie erneut aktualisieren. Eine zweite Schwachstelle mit maximalem Schweregrad betrifft Installationen, auf denen diese früheren Korrekturen laufen.
Am 21. Oktober 2026 veröffentlichte GitLab Patches für CVE-2026-110264, eine Schwachstelle zur Remotecodeausführung (RCE), die selbstverwaltete Installationen der Community Edition (CE) und Enterprise Edition (EE) betrifft. Die nach CVSS 3.1 mit 10,0 bewertete Schwachstelle könnte es nicht authentifizierten Angreifern unter bestimmten Bedingungen ermöglichen, beliebigen Code auszuführen.
Anders als CVE-2026-97229, das neun Tage zuvor gepatcht wurde, betrifft die neue GitLab-RCE-Schwachstelle Releases, die bis ins Jahr 2014 zurückreichen. Auch Organisationen, die die Patches vom 12. Oktober installiert haben, müssen erneut aktualisieren.
Neue GitLab-RCE-Lücke betrifft Releases, die bis ins Jahr 2014 zurückreichen
Laut GitLabs Sicherheitshinweis vom 21. Oktober beruht CVE-2026-110264 auf einem Integerüberlauf beim Kompilieren eines speziell erstellten regulären Ausdrucks. Eine erfolgreiche Ausnutzung könnte einen betroffenen Server kompromittieren, ohne dass gültige Zugangsdaten erforderlich sind.
Censys' Analyse vom 22. Oktober identifiziert das Rendern von Org-mode-Dateien (.org) in öffentlichen Projekten als potenziellen Angriffsweg. Eine Ausnutzung könnte Code unter dem gitGitLab-Konto ausführen und dadurch möglicherweise Repositories sowie CI/CD-Zugangsdaten offenlegen.
Die frühere CVE-2026-97229-Schwachstelle betraf die Validierung regulärer Ausdrücke in CI/CD-Konfigurationen. Beide Schwachstellen haben einen CVSS-Wert von 10,0, erfordern jedoch separate Korrekturen. Die Versionen 19.4.2, 19.3.5 und 19.2.8 sind weiterhin von der neueren Schwachstelle betroffen.
Zu den weiteren jüngsten Sicherheitsproblemen von GitLab gehören eine GraphQL-Schwachstelle im August, eine im September in den Katalog der von CISA ausgenutzten Schwachstellen aufgenommene Lücke sowie eine Lücke zur Befehlsausführung im AI Gateway im Oktober. Dabei handelte es sich jeweils um separate Sicherheitslücken.
Am 21. Oktober identifizierte Censys 81.820 aus dem Internet sichtbare GitLab-Hosts. Schätzungsweise mehr als die Hälfte lief mit Release-Zweigen, die über sieben Monate alt waren, wobei die Ergebnisse nicht feststellen, wie viele Installationen verwundbar oder kompromittiert waren. Bis zum 22. Oktober hatte Censys keine bestätigte Ausnutzung von CVE-2026-110264 in freier Wildbahn und keinen verifizierten öffentlichen Proof-of-Concept-Code festgestellt.
Betroffene GitLab-Versionen und Patch-Hinweise
GitLab veröffentlichte sieben korrigierte Releases, darunter vier zusätzliche Backports für ältere CE- und EE-Versionen.
| Betroffene Versionen | Korrigierte Version |
|---|---|
| 19.5.0 | 19.5.1 |
| 19.4 vor 19.4.3 | 19.4.3 |
| 19.3 vor 19.3.6 | 19.3.6 |
| 19.2 vor 19.2.9 | 19.2.9 |
| 19.1 vor 19.1.9 | 19.1.9 |
| 19.0 vor 19.0.10 | 19.0.10 |
| 7.0 bis einschließlich 18.11.12 | 18.11.13 oder ein späteres zutreffendes korrigiertes Release |
Ältere Installationen sollten die Upgrade-Anleitung von GitLab befolgen. Einige Updates erfordern Datenbankmigrationen und können auf Ein-Knoten-Systemen zu Ausfallzeiten führen. GitLab.com und entsprechend gepatchte GitLab-Dedicated-Installationen verfügen bereits über die Korrekturen.
GitLab veröffentlichte außerdem zwei Erkennungsregeln: "Onigmo native worker crash" und "Org mode render error burst." Der Sicherheitshinweis von CERT-EU vom 22. Oktober empfiehlt, internetseitig erreichbare Systeme zu priorisieren und mögliche Kompromittierungen zu untersuchen.
Sicherheitsteams sollten:
- Betroffene Installationen ermitteln: Die GitLab-Versionen in Produktions-, Entwicklungs- und Testsystemen erfassen.
- Sicherheitsupdates installieren: Korrigierte Releases einspielen, die Versionen überprüfen und vor dem Upgrade die Backups kontrollieren.
- Unnötige Angriffsflächen reduzieren: Den öffentlichen Zugriff, soweit möglich, beschränken und sensible Netzwerkverbindungen begrenzen.
- Verdächtige Aktivitäten untersuchen: Rendering-Fehler, unerwartete Prozesse,
gitAktivitäten des Kontos und Änderungen an SSH-Schlüsseln prüfen. - Mögliche Kompromittierung bewerten: Zugangsdaten, Repositories und Pipelines überprüfen. Offengelegte Geheimnisse bei Bedarf rotieren.
- Pläne für die Reaktion auf Vorfälle testen: Isolierung, Beweissicherung, Rotation von Zugangsdaten und Wiederherstellungsverfahren validieren.
Überwachung und Zugriffsbeschränkungen können die Gefährdung reduzieren, beseitigen die Schwachstelle jedoch nicht. Administratoren müssen ein zutreffendes korrigiertes Release installieren, selbst wenn sie bereits Anfang Oktober aktualisiert haben.
Mehr dazu: Die Kompromittierung der Coder-Registry durch bösartige Terraform-Module zeigt, wie Angriffe auf die Entwicklungsinfrastruktur Cloud-Zugangsdaten und CI/CD-Geheimnisse offenlegen können.