Über 11.000 GitLab-Instanzen ungepatcht: zwei CVSS-10-Lücken im Oktober und was Betreiber prüfen

Die Shadowserver Foundation zählt nach Berichten von BleepingComputer und Techzine mehr als 11.300 GitLab-Instanzen, die für CVE-2026-110264 verwundbar sind, bei rund 39.000 GitLab-Instanzen, die sie täglich sieht. Golem meldete am 3. November unter der Überschrift „Dringend patchen: 11.000 Gitlab-Instanzen durch laufende Angriffe gefährdet“. Dahinter stehen zwei Lücken mit CVSS 10.0, die GitLab am 12. und am 21. Oktober geschlossen hat. Gemessen haben wir selbst nichts. Wir haben die GitLab-Advisories, den Ruby-Hinweis, den CISA-Katalog und den Bericht von Alpine Linux gelesen. Die Golem-Meldung konnten wir nur bis zum Teaser lesen, der Rest liegt hinter der Cookie-Abfrage.

Ein CVSS-Wert von 10.0 heißt: Der Hersteller bewertet eine Lücke als über das Netz erreichbar, ohne Rechte, ohne Zutun eines Nutzers, mit vollem Schaden für Vertraulichkeit, Integrität und Verfügbarkeit und mit Wirkung über die Anwendung hinaus. Die Zahl beschreibt die Schwere unter diesen Annahmen. Sie sagt nicht, wie leicht ein Angriff auf einer bestimmten Installation gelingt.

Die Lücken mit Versionen

Die ersten beiden Zeilen sind die Lücken vom Oktober. Die dritte steht zum Vergleich da: Auch im September hatte GitLab schon eine Lücke mit CVSS 10.0.

Alle drei Werte stammen von GitLab selbst. Bei den beiden Oktober-Lücken lautet der Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: Angriff über das Netz, geringe Komplexität, keine Rechte, keine Nutzerinteraktion. Bei CVE-2026-97229 beschreibt Rapid7 Bedingungen hinter dem „ohne Anmeldung“: Der Angreifer muss eine CI-Konfiguration in ein Repository legen können, wofür nach Rapid7 ein normales Konto genügt, wenn Konten öffentliche Projekte anlegen dürfen, und bei offener Selbstregistrierung auch das nicht. Die Kette steht in unserem Beitrag vom 16. Oktober zu npm und GitLab. Zu CVE-2026-110264 haben wir keine unabhängige Analyse der Angriffsbedingungen gefunden. Ruby schreibt, die Fehler erreiche man nur, wenn eine Anwendung einen regulären Ausdruck aus Zeichen übersetzt, die ein Angreifer kontrolliert.

CVE-2026-85706 ist ein Pfad-Traversal in der Commits-API und steht seit dem 11. September im CISA-Katalog. Mit den beiden Regex-Lücken hat sie nichts zu tun.

Warum Update nicht gleich Update ist

Die Versionen vom 12. Oktober beheben nur CVE-2026-97229. Für die zweite Lücke liegt 19.4.2 unter dem Fix 19.4.3, wer damals aktualisiert hat, ist wieder im betroffenen Bereich.

Dazu kommt eine Besonderheit des Fixes. Nach GitLab ist er ein Patch an Ruby, den GitLab nur in seine offiziellen Linux-Pakete und Container-Images einbaut. Wer GitLab aus dem Quellcode oder in einem eigenen Image mit eigenem Ruby betreibt, braucht zusätzlich Ruby 3.3.13, 3.4.12 oder 4.0.9. Ruby hat diese Versionen am 23. Oktober veröffentlicht und nennt vier GitLab-CVEs, die darin behoben sind: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 und CVE-2026-110264.

Wie das in der Praxis ausging, hat Alpine Linux am 28. Oktober beschrieben. Ein neu registriertes Konto schickte am 20. und 21. Oktober präparierte CI-Konfigurationen an die Instanz, die noch auf 19.3.4 lief. Die Worker stürzten achtmal ab, in vier Fällen kam der Angreifer einen Schritt weiter. Das Update auf 19.3.6 am 22. Oktober half nicht, weil das Image ein Standard-Ruby ohne GitLabs Patch enthielt. Alpine fand keinen Beleg für ausgeführten Code, konnte ihn aber nicht ausschließen, und baute die Instanz neu auf.

Wer die 11.000 gezählt hat

Beide Zahlen sind Aussagen der zählenden Stellen, wir haben nichts nachgemessen. Dass sie sich nicht widersprechen, liegt am Gegenstand: Censys zählt alle Hosts mit GitLab-Software, Shadowserver die täglich gesehenen Instanzen und darunter die verwundbaren. Die Quote von fast 30 Prozent steht bei Techzine, Golem nennt im Teaser „fast jede dritte“. Ableitung, nicht gemessen: Eine Zählung von außen kann kaum sehen, ob das Ruby in einer Installation gepatcht ist. Eine Instanz mit passender GitLab-Version und ungepatchtem Ruby, wie bei Alpine, wäre dann falsch eingeordnet.

Was zur Ausnutzung belegt ist

CVE-2026-97229 führt die CISA seit dem 29. Oktober im Katalog ausgenutzter Lücken, mit Frist bis zum 1. November. Zu Ransomware-Nutzung steht dort „Unknown“. CVE-2026-110264 fehlt im Katalog, den wir am 9. November abgerufen haben (Stand der Datei: 6. November). Censys kannte am 22. Oktober keine Ausnutzung, BleepingComputer schrieb am 2. November, sie sei nicht bestätigt. Unsere Lesart: „Laufende Angriffe“ in der Golem-Überschrift meint CVE-2026-97229, die 11.300 gehören zu CVE-2026-110264. Das ist eine Schlussfolgerung aus Teaser und Quellen, den Golem-Text haben wir nicht gelesen.

Unser Stand

Wir betreiben Gitea für unsere Repositories, kein GitLab. In unserem Host-Inventar gibt es keinen Eintrag für GitLab und keinen für GitLab Runner. Der einzige Treffer in der Dokumentation ist ein Link auf das Upstream-Projekt gitlab.com/kyber in einem RFC. Das ist ein Inventarbefund und keine Messung im Netz: Wir haben die Hosts nicht nach GitLab-Containern abgesucht. Die Advisories nennen CE und EE als betroffen, einen Runner führen sie nicht auf.

Was Betreiber jetzt prüfen

1. Version feststellen und auf die Fix-Version der eigenen Linie bringen: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13. Bei Instanzen, die aus dem Internet erreichbar sind, diese Woche, nicht im nächsten regulären Wartungsfenster.
2. Bei eigenem Ruby oder eigenem Image prüfen, ob Ruby 3.3.13, 3.4.12 oder 4.0.9 drin ist. Für sein Image alpinelinux/gitlab schreibt Alpine: Jede 19.3.6, die vor dem 27. Oktober gezogen wurde, und alle älteren Tags sind verwundbar.
3. Logs ab dem 12. Oktober auf abgestürzte Worker durchsehen. GitLab veröffentlicht dafür Erkennungsregeln, etwa „Onigmo native worker crash“ und „Org mode render error burst“.
4. Bei Hinweisen auf ausgeführten Code die Instanz als kompromittiert behandeln und rotieren, was Alpine auflistet: gitlab-secrets.json, CI/CD-Variablen, Runner-Token und Zugriffstoken.
5. Die Angriffsfläche verkleinern: Selbstregistrierung und anonymen Zugriff auf öffentliche Projekte abschalten, die Instanz hinter VPN oder IP-Filter stellen, wo sie nicht öffentlich sein muss.

Weitere Beiträge zu Lieferketten und Patchständen sammelt der Hub Security und Datenschutz. Wer wissen will, welche Git-Dienste, Container und Versionen im eigenen Netz laufen, findet das Angebot unter Leistungen.

Weiterführende Quellen

• GitLab, Patch Release 19.4.2 vom 12. Oktober: docs.gitlab.com
• GitLab, Patch Release 19.5.1 vom 21. Oktober: docs.gitlab.com
• GitLab, Patch Release 19.3.2 vom 10. September: docs.gitlab.com
• Ruby, Regexp-Fixes für GitLab-CVEs: ruby-lang.org
• CISA, Katalog ausgenutzter Lücken: cisa.gov
• Alpine Linux, Vorfallbericht vom 28. Oktober: alpinelinux.org
• Golem vom 3. November: golem.de
• BleepingComputer vom 2. November: bleepingcomputer.com
• Techzine vom 2. November: techzine.eu
• Censys-Advisory zu CVE-2026-110264: censys.com
• Rapid7 zu CVE-2026-97229: rapid7.com