GitLab 18.11.3 / 18.10.6 / 18.9.7

ZWEI Lücken in einer Patch-Welle

GitLab hat in der letzten Mai-Woche 2026 zwei nennenswerte Sicherheitslücken bekannt gemacht und gestopft — beide in GitLab Community Edition und Enterprise Edition. Wer Self-Hosted fährt, ist betroffen. Wer GitLab.com nutzt, ist bereits gepatcht.

Die wichtigeren Versionen mit den Fixes: 18.11.3, 18.10.6 und 18.9.7. Wer auf älteren Minor-Linien hängt, sollte sowieso aktualisieren — GitLab pflegt rückwärts nur drei Minor-Versionen.

CVE-2026-8280 — der DoS-Hammer

Ein authentifizierter User kann durch präparierte Inputs (Details bewusst gedeckelt) den GitLab-Server zu exzessivem Speicherverbrauch bewegen. Resultat: Denial-of-Service. Das funktioniert auf allen Versionen vor 18.9.7 / 18.10.6 / 18.11.3, weil eine Input-Validierung schlicht fehlte.

Klingt harmlos? Ist es nicht. Wer mehrere hundert User in einer Self-Hosted GitLab hat — typisches Enterprise-Setup — riskiert, dass ein einzelner Account den ganzen Server in die Knie zieht. In CI-Pipelines, die per gitlab-runner regelmässig Calls machen, kann ein kompromittierter Runner-Token den Server killen.

CVE-2026-8144 — Membership-Leak

Die zweite Lücke: Fehlende Authorization-Checks erlaubten authentifizierten Usern mit Projekt-Zugriff, die Mitgliederliste von privaten Gruppen aufzuzählen. Das ist kein RCE, aber ein Compliance-Albtraum — bei Enterprise-Setups mit verschiedenen Kunden-Gruppen auf einer Instanz reichen private Gruppen-Mitglieder als Sensitiv-Information.

Beide CVEs betreffen GitLab-Versionen 15.1 bis 18.9.6, 18.10 bis 18.10.5 und 18.11 bis 18.11.2. Wer auf älteren Hauptversionen hängt: das Update ist Pflicht.

WIE du sauber patchst

GitLab-Standard-Verfahren:

Backup ziehen: gitlab-backup create oder über Snapshot des Storage-Volumes
Paket-Update: apt update && apt upgrade gitlab-ce (oder gitlab-ee)
Migration prüfen: gitlab-ctl reconfigure startet alle Services neu
Smoke-Test: Login, ein Push, ein Pipeline-Trigger

Bei Docker-Setups: Image-Tag bumpen auf gitlab/gitlab-ce:18.11.3-ce.0 oder die entsprechende Patch-Version deiner Linie. Reboot des Containers, anschliessend Logs prüfen.

WAS Anwender JETZT prüfen sollten

Drei Sofort-Hygiene-Schritte:

Runner-Token rotieren — wenn welche im Umlauf sind, die du nicht 100 Prozent kontrollierst
Audit-Log scannen — auf ungewöhnliche Membership-API-Calls in der letzten Woche
Server-Monitoring — Memory-Spikes ohne offensichtlichen Grund sind ab jetzt ein Alarm-Signal

HINTERGRUND: GitLab-Patch-Kadenz

GitLab macht seit Jahren monatliche Major-Releases plus bei Bedarf Security-Patch-Releases. Die Mai-Welle ist ein klassisches Sammel-Patch — mehrere CVEs, gemeinsam veröffentlicht, gleichzeitig gefixt. Wer GitLab.com nutzt, hat den Patch automatisch. Wer Self-Hosted fährt, muss aktiv anziehen.

Wer GitLab im Vergleich zu Gitea oder Forgejo testet: Patch-Kadenz und CVE-Disziplin sind klare GitLab-Stärken. Forgejo ist sicherheits-bewusst, aber bei Enterprise-Scale-Patches noch nicht ganz auf gleichem Niveau.

Häufige Fragen

Wie schnell muss ich patchen?

Bei einer Self-Hosted Instanz mit Internet-Zugriff und unbekannter User-Population: heute. Bei einer rein internen Instanz mit vertrauten Usern: bis Anfang nächster Woche reicht meistens. Das Risiko liegt nicht im ‚Hack-from-Outside‘-Szenario, sondern in dem Moment, wo ein User-Account kompromittiert ist und der Angreifer Privilegien eskalieren oder den Server in die Knie zwingen will.

Was ist mit der mini Shai-Hulud-Welle vom 19. Mai?

Die ist ein anderes Thema, betrifft npm/PyPI und nicht GitLab. Aber: Wenn deine GitLab-Pipelines npm-Pakete bauen, die mit Mini-Shai-Hulud-kompromittierten Maintainer-Accounts arbeiten, kann der GitLab-Runner indirekt betroffen sein. Trennung: Patch GitLab gegen 8280/8144, separat npm-Verifikation in den Pipelines verschärfen.

Lohnt sich der Sprung von 18.9 auf 18.11 jetzt?

Wenn dein Workflow es zulässt: ja. 18.11 bringt frische Features (Group-Wide Issue Search, schnellere Container-Builds) und ist die längste ’noch unterstützte‘ Linie für die nächsten Monate. Wenn dein Setup kompliziert ist (ein paar Custom-Auth-Adapter, alte CI-Scripts), bleibst du erstmal auf 18.9.7 — auch dort ist die CVE gefixt.

Quellen: GitLab Releases · BitNinja zu CVE-2026-8280 · BitNinja zu CVE-2026-8144

GITLAB-ALARM! Zwei CVE-Wellen reissen JETZT 18.9, 18.10 und 18.11 auf — DEINE Pipeline blutet ohne Patch