CVE-2026-19478: Unauthentifizierte Angriffe auf öffentliche GitLab-Projekte

In GitLab Community Edition und Enterprise Edition wurde die kritische Schwachstelle CVE-2026-19478 mit einer Bewertung von CVSS 9.4 entdeckt, die es einem nicht authentifizierten Angreifer ermöglicht, öffentlich zugängliche GitLab-Projekte zu modifizieren und zu löschen, ohne dass Anmeldedaten oder eine Interaktion des Nutzers erforderlich sind. Patches wurden bereits veröffentlicht, und Organisationen mit selbst gehosteten, aus dem Internet erreichbaren GitLab-Instanzen sollten umgehend aktualisieren. Das Unternehmen watchTowr berichtet von Anzeichen einer Ausnutzung der Schwachstelle, auch wenn diese Angaben bislang nicht von unabhängigen Quellen bestätigt wurden.

Technische Details der Schwachstelle

CVE-2026-19478 wird als code injection-Schwachstelle klassifiziert. Berichten zufolge ist eine Ausnutzung über eine GraphQL-Direktive möglich – einen Mechanismus, den GitLab zur Verarbeitung von API-Anfragen verwendet. Die zentrale Gefahr besteht darin, dass für den Angriff weder eine Authentifizierung noch eine spezifische Konfiguration der Zielinstanz erforderlich ist.

Betroffene Versionen von GitLab CE und EE:

• 18.2 — bis 18.11.11
• 19.0 — bis 19.0.8
• 19.1 — bis 19.1.6
• 19.2 — bis 19.2.4

Fehlerbehebungen sind in den Versionen 18.11.11, 19.0.8, 19.1.6 und 19.2.4 verfügbar.

Nach Angaben der Forschenden von watchTowr gehen die Auswirkungen einer Ausnutzung über die bloße Modifikation öffentlicher Projekte hinaus. Laut ihrer Veröffentlichung kann ein Angreifer mutmaßlich:

• Komplette Repositories löschen
• Merge-Records (merge records) fälschen und so die Illusion angewendeter Fixes erzeugen, die in Wirklichkeit nie erfolgt sind
• Projekt-Maintainer sperren

Es ist wichtig zu beachten, dass diese erweiterten Szenarien der Auswirkung ausschließlich auf den Angaben einer einzelnen Forschungsquelle beruhen und bislang weder durch ein offizielles GitLab-Bulletin noch durch andere unabhängige Organisationen bestätigt wurden.

Status der Ausnutzung

Das Unternehmen watchTowr erklärte, dass es die Schwachstelle innerhalb weniger Minuten nach der öffentlichen Offenlegung reproduzieren konnte und Anzeichen einer Ausnutzung in seinem Honeypot-Netzwerk beobachtet hat. Zum Zeitpunkt der Veröffentlichung ist die Schwachstelle jedoch nicht im CISA KEV-Katalog aufgeführt, und Behauptungen über eine aktive Ausnutzung wurden weder vom Hersteller noch von anderen anerkannten Quellen bestätigt. Der Status der Ausnutzung ist daher als unbestätigt zu betrachten – das verringert nicht die Kritikalität der Schwachstelle selbst, beeinflusst aber die Bewertung der unmittelbaren Bedrohung.

Der watchTowr-Forscher Jake Nott brachte die Geschwindigkeit vom Disclosure bis zur Ausnutzung mit dem Einsatz von Werkzeugen der künstlichen Intelligenz durch Angreifer in Verbindung, was seiner Ansicht nach das Zeitfenster für die Reaktion verkleinert. Unabhängig davon, ob sich die Rolle von KI in diesem konkreten Fall bestätigen lässt, ist der Trend zu kürzeren Zeiträumen zwischen Offenlegung und ersten Angriffen eine objektive Realität der letzten Jahre.

Bewertung der Auswirkungen

Am stärksten gefährdet sind Organisationen, die selbst gehostete GitLab-Instanzen mit Internetzugang und öffentlichen Repositories einsetzen. Angesichts der weiten Verbreitung von GitLab für die Speicherung von Quellcode, die Verwaltung von CI/CD-Pipelines und die Koordination der Entwicklung kann eine Kompromittierung von Repositories zu Folgendem führen:

• Einschleusen von Schadcode in die Software-Lieferkette
• Irreversibler Datenverlust durch das Löschen von Repositories
• Erschütterung des Vertrauens in die Änderungshistorie durch gefälschte Merge-Records
• Störung von Arbeitsabläufen durch das Sperren von Maintainern

Das Szenario mit gefälschten Merge-Records ist besonders gefährlich: Ein Angreifer kann theoretisch den Eindruck erwecken, dass eine Schwachstelle im Projekt bereits behoben wurde, während der Schadcode tatsächlich bestehen bleibt.

Empfehlungen zur Reaktion

Oberste Priorität hat ein umgehendes Update auf eine der fehlerbereinigten Versionen: 18.11.11, 19.0.8, 19.1.6 oder 19.2.4.

Ist ein sofortiges Update nicht möglich, werden folgende temporäre Maßnahmen empfohlen:

1. Den nicht authentifizierten Zugriff auf den Endpoint /api/graphql auf Ebene des Webservers oder Reverse-Proxys einschränken
2. Den öffentlichen Zugriff auf Repositories bis zur Einspielung des Patches vollständig deaktivieren
3. Die Webserver-Protokolle auf Anfragen prüfen, die die Zeichenfolge @gl_introduced enthalten – dies kann nach Angaben der Forschenden auf Versuche der Ausnutzung oder Aufklärung hindeuten

Organisationen, die verdächtige Anfragen an die GraphQL API feststellen, sollten eine Integritätsprüfung der betroffenen Repositories durchführen: die Commit-Historie, Merge-Records und den Status der Maintainer-Konten überprüfen.

Angesichts der CVSS-Bewertung von 9.4 und der Tatsache, dass für die Ausnutzung keine Authentifizierung erforderlich ist, sollte das Update selbst gehosteter GitLab-Instanzen auf die Versionen 18.11.11, 19.0.8, 19.1.6 oder 19.2.4 außerhalb des regulären Patch-Zyklus erfolgen – in den kommenden Stunden, nicht Tagen. Organisationen, die nicht sofort aktualisieren können, sollten zumindest den nicht authentifizierten Zugriff auf /api/graphql blockieren und die Protokolle auf Indikatoren für Aufklärung prüfen.