GitLab schloss am 17. August eine Lücke, über die Unbekannte öffentliche Projekte ohne Anmeldung ändern oder löschen können. Drei Tage später fingen die Honeypots des Sicherheitsunternehmens watchTowr die ersten echten Angriffe darauf. Den Weg zum funktionierenden Exploit wies der Patch selbst.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Der Eintrag CVE-2026-19478 trägt den CVSS-Wert 9,4 und trifft ausschließlich selbst betriebene GitLab-Installationen.[1] Zur Freigabe nannte der Hersteller keine bekannte Ausnutzung. Diese Angabe hielt drei Tage.
Das Wichtigste in Kürze
- watchTowr reproduzierte die Lücke nach eigener Angabe binnen Minuten, allein aus dem Sicherheitshinweis und dem veröffentlichten Patch.
- Der CVSS-Vektor stuft die Vertraulichkeit niedrig ein, Integrität und Verfügbarkeit dagegen hoch. Angreifer verändern und löschen, statt zu lesen.
- Vier ältere GitLab-Lücken stehen im Ausnutzungskatalog der US-Behörde CISA. CVE-2026-19478 fehlt dort am 21. August 2026 noch.
- Abhilfe schaffen die Ausgaben 19.2.4, 19.1.6, 19.0.8 und 18.11.11. Ohne Update hilft nur, den unangemeldeten Zugriff auf /api/graphql zu sperren.
Was fingen die Honeypots von watchTowr ein?
Das Sicherheitsunternehmen watchTowr meldet Ausnutzungsversuche im eigenen weltweiten Honeypot-Netz, rund drei Tage nach der Freigabe der Patches. GitLab gab die Korrekturen am 17. August 2026 frei und beschrieb den Fehler als Lücke, über die unangemeldete Nutzer öffentliche Projekte und Nutzerdaten per GraphQL-Direktive ändern oder löschen können.[1]
Der Schaden reicht über die Zerstörung hinaus. Nach Darstellung von watchTowr lassen sich Repositories löschen und Maintainer sperren. Schwerer wiegt die dritte Möglichkeit: Ein gefälschter Merge-Eintrag lässt eine bösartige Änderung so aussehen, als hätten Kollegen sie geprüft und freigegeben.
Den Zeitdruck erklärt Jake Knott, Principal Security Researcher bei watchTowr, so: „So sieht die neue Wirklichkeit bei Reproduktion und Ausnutzung von Schwachstellen aus. KI-gestützte Angreifer pressen die Zeit zwischen Offenlegung und erstem Angriff zusammen.“ Wie GitLab die Lücke beschrieb, steht in unserem Bericht über die Patch-Freigabe vom 17. August.
Warum reichte der Patch als Vorlage?
GitLab liegt quelloffen vor. Der Sicherheitshinweis benennt die verwundbare Stelle, und der zugehörige Commit zeigt die Korrektur im Klartext. Aus beidem zusammen entsteht eine Bauanleitung.
Die Angriffsart lässt sich am CVSS-Vektor ablesen. GitLab notiert AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H.[1] Die Vertraulichkeit steht dort auf niedrig, Integrität und Verfügbarkeit dagegen auf hoch. Angegriffen wird also der Bestand des Codes, nicht dessen Geheimhaltung.
Die kurze Frist ist kein Einzelfall. Bei der SharePoint-Lücke CVE-2026-55040 lag ein Tag zwischen Beispielcode und erstem Angriff. Beim LiteSpeed-Plugin für cPanel begann die Ausnutzung ebenfalls kurz nach der Offenlegung. GitLab selbst traf der Effekt im Juli, als der entscheidende Patch als Routine-Update durchging.
Ein Sicherheitshinweis zu quelloffener Software ist immer auch eine Wegbeschreibung. Betreiber planen ihr Wartungsfenster deshalb besser nach der Frage, wie schnell sich ein Patch nachbauen lässt, statt allein nach dem Schweregrad.
— Markus Seyfferth, Chefredakteur Dr. Web
Was gilt jetzt für Betreiber im DACH-Raum?
Ein selbst betriebenes GitLab führt personenbezogene Daten, von Namen über Adressen bis zur Commit-Zuordnung. Ein bestätigter Zugriff darauf startet die Frist von 72 Stunden nach Artikel 33 DSGVO, gerechnet ab Kenntnis der Verletzung.[3]
Die US-Behörde CISA führt in ihrem Katalog ausgenutzter Schwachstellen vier GitLab-Einträge, darunter CVE-2021-22205 mit belegtem Einsatz in Erpressungskampagnen. CVE-2026-19478 stand am 21. August 2026 noch nicht darin.[2] Die 14-Tage-Frist greift damit vorerst nicht. Beim Defender-Fehler ShieldBreak zeigte sich zuletzt, dass diese Frist auch ohne Patch weiterläuft.
Der Versionsstand gehört zuerst geprüft, danach folgt der Sprung auf 19.2.4, 19.1.6, 19.0.8 oder 18.11.11. Liegt das Wartungsfenster weiter entfernt, sperren Sie den unangemeldeten Zugriff auf /api/graphql oder schalten den öffentlichen Repository-Zugang ab. Für die Rückschau durchsuchen Sie die Webserver-Logs nach Anfragen mit dem Muster @gl_introduced. Warum diese Abwägung in die Geschäftsleitung gehört, zeigt unser Beitrag über Cybersecurity als Chefsache.
Quellen
[1] GitLab: „GitLab Patch Release: 19.2.4, 19.1.6, 19.0.8, 18.11.11“
[2] CISA: „Known Exploited Vulnerabilities Catalog“
[3] EUR-Lex: „Verordnung (EU) 2016/679, Artikel 33“
Mehr Newshunger?
- Cisco findet mit KI-Modellen fünf Lücken der Höchststufe im eigenen Code
- Siemens-S7-Steuerungen: US-Behörden warnen vor KI-generierten Angriffen
- Cloudflare Workers: Ein Spectre-Angriff las das JWT eines fremden Kunden
- Schädliches Rust-Paket arrayref: Der Schadcode startet beim Kompilieren
- Coding-Aufgabe im Bewerbungsgespräch: Sieben Zeilen laden den Schadcode nach
- GLM-5.3 und die Schwachstellen-Suche: Zhipu vergibt den Vollzugriff nur nach Prüfung
