GitLabs am schlechtesten bewertete Schwachstelle braucht nur ein öffentliches Projekt

Ein einziges öffentliches Projekt ist die einzige Voraussetzung

CVE-2026-85706 verlangt von einem Angreifer fast nichts. Die Schwachstelle liegt in der Commits-API der GitLab-Repositories, wo eine unzureichende Pfadbeschränkung und eine fehlende Authentifizierungsprüfung einem nicht angemeldeten Nutzer erlauben, eine Anfrage mit einem Dateipfad-Parameter zu senden und beliebige Dateien vom Server auszulesen, ganz ohne Anmeldung. Jake Knott von watchTowr brachte die Eintrittshürde auf einen Satz: "Die Ausnutzung erfordert nur eine Voraussetzung: Es muss mindestens ein öffentliches Projekt existieren." Die meisten selbst verwalteten GitLab-Instanzen haben mindestens eines, ganz gleich, ob der Betreiber es als öffentlich zugänglich betrachtet oder nicht.

Die Schwachstelle trägt einen CVSS-Wert von 10.0, dem Höchstwert der Skala, und betrifft GitLab Community und Enterprise Edition in den Versionen 18.7 bis 19.1.7, 19.2 bis 19.2.5 sowie 19.3 bis 19.3.1. Ein derart offen liegender Server verliert nicht nur Quellcode. Die Commits-API liegt nah genug an Konfigurationsdateien, CI/CD-Pipeline-Definitionen und Deployment-Tokens, dass ein erfolgreicher Lesezugriff einem Angreifer die Zugangsdaten liefern kann, um sich tiefer in das vorzuarbeiten, was diese GitLab-Instanz baut und ausliefert.

Ein Patch existierte vor der Frist

Zwischen der Veröffentlichung des Fixes und den ersten Zugriffsversuchen auf die Honeypots von watchTowr vergingen weniger als 24 Stunden. Der eigene Katalogeintrag der CISA folgte nur Stunden später. watchTowr geht davon aus, dass Angreifer die Schwachstelle bereits aus dem Patch selbst zurückentwickelt und nachgebaut hatten, genau das Muster, das eine Veröffentlichung in dem Moment zu einem Wettlauf macht, in dem sie öffentlich wird. Die Frist der CISA bindet nur US-Bundesbehörden, nicht ein Unternehmen in München oder Manchester, doch der Ausnutzungszeitraum, auf den sie reagiert, macht an dieser Grenze nicht halt.

Die dritte, die Servola seit August verfolgt hat

Dies ist nicht GitLabs erste kritische Schwachstelle in diesem Sommer: Es ist die dritte, die innerhalb von etwa vier Wochen aktiv angegriffen wurde. Servola berichtete am 18. August über eine GitLab-Schwachstelle, die zusammen mit kritischen Lücken in Ray und Apple-Software auftrat, dann am 24. August über eine GraphQL-Code-Injection-Schwachstelle in GitLab selbst, CVE-2026-19478, ein Fehler, den TheHackerNews in der eigenen Berichterstattung über diese neue Schwachstelle ausdrücklich als früheren Fall von Ausnutzung kurz nach Bekanntwerden anführt. Drei kritische CVEs gegen eine weitverbreitet selbst gehostete Plattform innerhalb eines Monats sind kein Zufall, den man als Pech abtun sollte. Es ist ein Signal, dass die Angriffsfläche von GitLab und das Tempo, mit dem Forscher wie Angreifer inzwischen einen Patch zurückentwickeln, schneller gewachsen sind, als die meisten selbst verwaltenden Betreiber nachschauen.

Keine der drei Schwachstellen teilt eine gemeinsame Ursache. Was sie gemeinsam haben, ist ein enges Zeitfenster: Jede wurde innerhalb von Tagen nach Erscheinen des jeweiligen Patches angegriffen oder ausgenutzt, nicht erst nach Wochen. Ein Betreiber, der GitLab-Updates nur einmal im Monat prüfte, hätte bei allen dreien das sichere Zeitfenster verpasst.

Was sich für ein Unternehmen mit selbst gehostetem GitLab ändert

Der konkrete Schritt ist klein: Prüfen Sie, ob Ihre Instanz auf 19.1.8, 19.2.6 oder 19.3.2 oder neuer läuft, und durchsuchen Sie dann die Zugriffsprotokolle nach POST-Anfragen an den Commits-Endpunkt des Repositories mit einem Dateipfad-Parameter, dem Indikator, nach dem watchTowr zu suchen empfiehlt. Der größere Schritt ist der, der eine Wiederholung tatsächlich verhindert. NIS2 verlangt von EU-Organisationen bereits den Nachweis, dass ein Patch jedes verwaltete System tatsächlich erreicht hat, nicht nur, dass GitLab einen veröffentlicht hat. Eine selbst gehostete Instanz, bei der niemand zuständig ist, den KEV-Katalog der CISA oder die Sicherheitshinweise von GitLab in Echtzeit zu beobachten, wird kritische Schwachstellen weiterhin aus einem Nachrichtenartikel erfahren statt aus einem Monitoring-Alarm. In Deutschland orientieren sich viele Sicherheitsteams dabei an den Prüfempfehlungen des BSI für genau solche Patch-Nachweise.

Ein Unternehmen, das jede dieser Schwachstellen als isolierte Feuerübung behandelt, wird diese hier gut überstehen und die nächste im selben Tempo verpassen. Ein Unternehmen, das jemandem die Zuständigkeit für den Patch-Rhythmus von GitLab überträgt, so wie es die Zuständigkeit für seine Firewall-Regeln vergibt, ist nicht mehr dreimal in Folge der Letzte, der es erfährt.

Weiterlesen: Ausgenutzt, Wochen Bevor PaperCut Patchte  |  GitLab-Notfallpatch: Self-Managed traf es, SaaS nicht