GitLab hat Patches für die kritische Lücke CVE-2026-110264 veröffentlicht, die auf der CVSS-Skala 10 von 10 Punkten erreicht. Angreifer könnten ohne Anmeldung Code auf dem Server ausführen. Die Korrekturen stecken in sieben Versionen von 18.11.13 bis 19.5.1. Gitlab.com und die Dedicated-Umgebungen sind laut Hersteller bereits geschützt.
Inhalt 8 Abschnitte
Ein einziger Fehler mit der Höchstwertung 10 von 10 gefährdet selbst betriebene GitLab-Server. Wer eine eigene Instanz betreibt, sollte noch heute auf eine korrigierte Version wechseln.
Das Wichtigste in Kürze
- Höchste Gefahrenstufe: Die Lücke CVE-2026-110264 erreicht auf der CVSS-Skala 10 von 10 Punkten.
- Angriff ohne Login: Unter bestimmten Bedingungen führen Angreifer aus der Ferne Code auf dem Server aus, ohne sich anzumelden.
- Sieben Patch-Versionen: Die Korrekturen stecken in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13.
- Cloud ist geschützt: Gitlab.com und die Dedicated-Umgebungen sind laut Hersteller bereits abgesichert.
Was die GitLab-Sicherheitslücke bewirkt
GitLab hat Patches für eine neue kritische Schwachstelle veröffentlicht. Sie betrifft die Community-Edition (CE) und die Enterprise-Edition (EE) der DevSecOps-Plattform. Ein Angreifer könnte beliebigen Programmcode auf dem Server laufen lassen. Eine Anmeldung braucht er dafür nicht.
Die Ursache liegt im Compiler für reguläre Ausdrücke. Er verarbeitet numerische Werte fehlerhaft. Mit einem speziell gebauten Ausdruck lässt sich das unter bestimmten Bedingungen ausnutzen. Welche Bedingungen das sind, nennt die Quelle nicht.
Ein Forscher mit dem Pseudonym "joaxcar" hat die Lücke gemeldet, und zwar über das Bug-Bounty-Programm von GitLab. Mehr zu den Korrekturen findest du in den Patch-Hinweisen von GitLab.
Welche Versionen die Korrektur enthalten
GitLab behebt den Fehler in mehreren Versionslinien gleichzeitig. Setz die Instanz auf die Version, die zu deiner Linie passt.
| Versionslinie | Korrigierte Version | Was das bedeutet |
|---|---|---|
19.5 |
19.5.1 |
Neueste Linie, direkt auf 19.5.1 heben |
19.4 |
19.4.3 |
Patch innerhalb der Linie genügt |
19.3 |
19.3.6 |
Patch innerhalb der Linie genügt |
19.2 |
19.2.9 |
Patch innerhalb der Linie genügt |
19.1 |
19.1.9 |
Patch innerhalb der Linie genügt |
19.0 |
19.0.10 |
Patch innerhalb der Linie genügt |
18.11 |
18.11.13 |
Ältere Linie, ebenfalls gepatcht |
Wer jetzt handeln muss
Der Hersteller rät Administratoren selbst gehosteter Instanzen, die Patches sofort einzuspielen. Die Netzwoche berichtet am 26. Oktober 2026 darüber. Das Datum der Erstveröffentlichung und der letzten Aktualisierung der GitLab-Meldung nennt die Quelle nicht. Als Artikeldatum gilt daher der 26. Oktober 2026, der Tag des Netzwoche-Berichts.
Dabei gilt eine einfache Reihenfolge:
- Version der eigenen Instanz prüfen.
- Passende korrigierte Version aus der Tabelle wählen.
- Update einspielen und die Versionsnummer danach kontrollieren.
Nutzer von Gitlab.com müssen nichts tun. Auch die Dedicated-Umgebungen laufen laut GitLab bereits mit korrigierten internen Versionen.
Die Lücke steht nicht allein
Zudem ist es nicht die erste kritische Meldung der letzten Wochen. Zehn Tage vor dieser Warnung hat GitLab eine weitere Lücke mit Codeausführung aus der Ferne bekannt gegeben (CVE-2026-97229). Auch sie erhielt 10 von 10 Punkten. Darüber berichtet BleepingComputer.
Im September behob GitLab ausserdem eine Schwachstelle mit höchstem Schweregrad (CVE-2026-85706). Sie liess Zugriffe auf sensible Informationen ohne Authentifizierung zu. Die US-Behörde CISA hat sie in ihren Katalog aktiv ausgenutzter Lücken aufgenommen.
Daher lohnt sich ein fester Update-Rhythmus. Wer nur gelegentlich patcht, lässt Fenster offen.
Die Netzwoche stellt den Fall in einen grösseren Zusammenhang. Wenige Tage zuvor wurden zwei kritische PHP-Lücken bekannt, deren Tragweite mithilfe von KI erkannt wurde. Beim Angriff auf TeamUpdraft vermutet das Unternehmen hinter WordPress ebenfalls KI auf Seiten der Angreifer. Für GitLab ist kein KI-Einsatz nachgewiesen.
Einordnung: Was das für Admins in der Schweiz heisst
Betreibst du GitLab selbst, zum Beispiel auf einem eigenen Server oder in einer privaten Cloud, trägst du das Risiko allein. Die Meldung vom 26. Oktober 2026 verlangt sofortiges Handeln, eine Frist nennt der Hersteller nicht. Ein Angriff braucht keinen Login, deshalb hilft auch ein starkes Passwort nicht. Der Aufwand beschränkt sich auf ein Update innerhalb deiner Versionslinie, das Zeit statt Geld kostet. Teams, die Gitlab.com nutzen, sind laut Hersteller bereits geschützt. Ob die Lücke schon aktiv ausgenutzt wird, sagt die Quelle nicht.
Fazit
Du weisst jetzt, welche Versionen die Lücke schliessen und wer betroffen ist. Prüfe als Nächstes die Version deiner Instanz und spiele die passende Korrektur ein. Wer keinen eigenen Server betreibt, braucht nichts zu unternehmen. Für den Newsletter zu Cybersecurity gibt es die Anmeldung bei Swisscybersecurity.net.
Quellen: Netzwoche. Foto: StartupStockPhotos / Pixabay. Stand: 26. Oktober 2026.
Geschrieben von der Redaktion · Freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.