Neun Tage nach dem letzten kritischen Update schließt GitLab erneut eine Lücke mit 10,0 von 10 Punkten. Angreifer können darüber ohne Konto Code auf selbst betriebenen Servern ausführen, verwundbar ist jede Version seit 2014. Auch Installationen auf dem Stand vom 12. Oktober brauchen das neue Update.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenSieben Fassungen auf einen Schlag hat GitLab am 21. Oktober veröffentlicht, von 19.5.1 bis zurück zu 18.11.13. Für vier ältere Versionsreihen hat der Hersteller die Korrektur eigens zurückportiert.[1] Anlass ist die Lücke CVE-2026-110264: Beim Kompilieren eines präparierten regulären Ausdrucks läuft ein Zähler über seinen Wertebereich hinaus. Unter bestimmten Bedingungen führen Angreifer so ohne Anmeldung beliebigen Code auf dem Server aus.[1]
Das Wichtigste in Kürze
- CVE-2026-110264 erreicht im Bewertungssystem CVSS den Höchstwert 10,0 und betrifft GitLab CE und EE ab Version 7.0.
- GitLab.com und GitLab Dedicated sind bereits geschützt, handeln müssen Betreiber eigener Server.
- Das Update vom 12. Oktober reicht nicht, nötig sind die Fassungen vom 21. Oktober.
- Welche Bedingungen ein Angriff voraussetzt, nennt GitLab nicht, eine Übergangslösung ebenso wenig.
Warum reicht die Lücke bis 2014 zurück?
Der Fehler steckt in Onigmo, der Bibliothek für reguläre Ausdrücke, die Ruby seit Version 2.0 standardmäßig nutzt.[2] GitLab liefert Ruby in seinen Paketen selbst mit und ergänzt es um eigene Korrekturen. Die Änderungsliste jeder Versionsreihe nennt deshalb einen Ruby-Patch gegen den Überlauf.[1]
Einen Hinweis auf den Angriffsweg geben die beiden Erkennungsregeln, die GitLab für eigene Server veröffentlicht hat. Die eine schlägt an, wenn Onigmo einen Worker-Prozess abstürzen lässt, die andere bei gehäuften Fehlern beim Anzeigen von Dateien im Org-Format, einem Textformat aus dem Editor Emacs. Im selben Update erneuert GitLab auch die Bibliotheken gitlab-markup und rdoc, die solche Formate darstellen.[1] Bestätigt hat der Hersteller den Weg über die Dateianzeige nicht.
Das Ruby-Projekt hat bis Donnerstagmorgen keinen eigenen Sicherheitshinweis zu Onigmo veröffentlicht.[3] Damit bleibt offen, ob auch andere Ruby-Anwendungen angreifbar sind, die reguläre Ausdrücke aus Nutzereingaben kompilieren.
Wie oft hat GitLab hier schon nachgebessert?
CVE-2026-110264 ist die vierte Lücke dieser Art binnen eines Monats, alle vier meldete der Sicherheitsforscher joaxcar über die Plattform HackerOne. Am 23. September schloss GitLab zwei Fehler beim Verarbeiten regulärer Ausdrücke in CI/CD-Konfigurationen, für die Angreifer ein Konto brauchten.[4] Am 12. Oktober folgte CVE-2026-97229 mit 10,0 Punkten, diesmal ohne Anmeldung.[5] Beide Male waren nur Versionen ab 19.2 betroffen, jetzt sind auch die Fassungen vom 12. Oktober wieder verwundbar.
Schon im Juli ließen sich zwei Speicherfehler im in C geschriebenen JSON-Parser Oj ausnutzen, der Patch erschien ohne CVE-Nummer. Im September schloss GitLab eine Lücke in der Commit-API mit ebenfalls 10,0 Punkten. Am selben Tag wie GitLab mussten Betreiber auch PHP selbst aktualisieren, die Lücken namens PHP2Shell steckten in der Sprache, nicht in einer Anwendung.
Eine Lücke im Unterbau der Programmiersprache lässt sich nicht wegkonfigurieren. Dagegen hilft nur das Update.
Markus Seyfferth, Chefredakteur Dr. Web
Was müssen Betreiber in Deutschland jetzt tun?
Auch die Open-Source-Plattform der Verwaltung, openCode, läuft auf einer eigenen GitLab-Installation, betrieben vom ZenDiS im Auftrag des Bundesdigitalministeriums.[6] Für wichtige und besonders wichtige Einrichtungen verlangt das BSI-Gesetz bei der Wartung ihrer IT ausdrücklich ein Schwachstellenmanagement.[7] Ein Server, der nach dem 12. Oktober als erledigt galt, gehört deshalb zurück auf die Liste. Im Katalog der US-Behörde CISA für ausgenutzte Lücken steht CVE-2026-110264 bislang nicht.[8]
Für eigene Server gilt:
- Auf 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13 aktualisieren, ältere Installationen eingeschlossen.
- Ein Wartungsfenster einplanen: Das Update ändert die Datenbank, auf einem einzelnen Server steht GitLab still, bis die Änderungen durchgelaufen sind.[1]
- Die Anwendungsprotokolle mit den beiden Erkennungsregeln auf abgestürzte Worker-Prozesse und gehäufte Fehler bei Org-Dateien prüfen.
Quellen
8 Quellen anzeigenQuellen ausblenden
- GitLabGitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
- Onigmo (GitHub)Onigmo (Oniguruma-mod), README
- RubySecurity, Stand 22. Oktober 2026
- GitLabGitLab Critical Patch Release: 19.4.1, 19.3.3, 19.2.7
- GitLabGitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
- openCodeopenCode.de, Open-Source-Plattform für die öffentliche Verwaltung
- Gesetz über das Bundesamt für Sicherheit in der Informationstechnik§ 30 BSIG, Risikomanagementmaßnahmen, Abs. 2 Nr. 5
- CISAKnown Exploited Vulnerabilities Catalog, Katalogversion 2026.10.21
Mehr Newshunger?
- GitLab-Lücke im AI Gateway: Über präparierte Agenten-Flows führen Angreifer Befehle aus
- GitLab-Lücke per E-Mail: Eine öffentliche Issue-Adresse genügt für Code auf dem Main-Branch
- GitLab-Lücke mit CVSS 10,0: Die Commit-API prüft die Anmeldung nicht
- GitLab-Lücke CVE-2026-19478: Der Patch lieferte die Bauanleitung
- PHP2Shell: Vier neue PHP-Versionen schließen die kritischen Lücken
- BeyondTrust: Spionagegruppe nutzte die Fernwartungslücke seit Ende August
- Cybersecurity Grundlagen: Was KMU 2026 können müssen
