GitLab hat eine kritische Schwachstelle in Community Edition und Enterprise Edition geschlossen, die inzwischen aktiv ausgenutzt wird. CVE-2026-19478 ist mit einem CVSS-Wert von 9.4 bewertet und beruht auf einer Code-Injection. Ein Angreifer kann ohne Authentifizierung öffentlich zugängliche Projekte verändern oder löschen und deren Daten umschreiben – laut Beschreibung ohne Zugangsdaten, ohne Zutun eines Nutzers und ohne dass eine ungewöhnliche Konfiguration nötig wäre.

In einer Warnmeldung dieser Woche erklärte GitLab, der Fehler lasse sich über eine GraphQL-Direktive ausnutzen. Die Korrekturen sind in den Versionen 19.2.4, 19.1.6, 19.0.8 und 18.11.11 von CE und EE enthalten.

watchTowr teilte The Hacker News mit, man habe die Schwachstelle innerhalb von Minuten nach ihrer Offenlegung reproduzieren können – und anschließend Ausnutzung im eigenen Honeypot-Netzwerk beobachtet. Jake Knott, Principal Security Researcher bei watchTowr, ordnet das als neue Normalität ein: KI-gestützte Angreifer verkürzten die Zeitspanne zwischen Offenlegung und Ausnutzung drastisch, und „bis zum nächsten Patch-Zyklus zu warten" sei häufig zu spät.

Für die Erkennung nennt Knott einen konkreten Anhaltspunkt: Organisationen, die noch nicht gepatcht haben, sollten ihre Webserver-Protokolle nach Anfragen durchsuchen, die die Zeichenfolge „@gl_introduced" enthalten, und dabei auf Spuren von Scans oder Ausnutzungsversuchen achten.

Die Auswirkungen reichen nach Darstellung von watchTowr über das Verändern oder Löschen öffentlicher Projekte hinaus. Ein Angreifer könne ganze Repositories löschen, Merge-Einträge fälschen, sodass ein Fix als eingepflegt erscheint, obwohl er es nicht ist, und Projekt-Maintainer sperren. Damit steht nicht nur die Verfügbarkeit von Code zur Debatte, sondern auch die Glaubwürdigkeit der Versionshistorie.

Besonders exponiert sind selbst gehostete GitLab-Instanzen, die aus dem Internet erreichbar sind. Sie sollten vorrangig auf eine gepatchte Ausgabe aktualisiert werden. Ist ein sofortiges Update nicht möglich, empfiehlt sich als Übergangsmaßnahme, den unauthentifizierten Zugriff auf „/api/graphql" einzuschränken oder den öffentlichen Repository-Zugang vollständig zu entfernen.