Wenn Ihr Unternehmen GitLab auf einem eigenen Server betreibt, aktualisieren Sie es heute. Am 12. Oktober 2026 hat GitLab einen kritischen Sicherheitspatch veröffentlicht, der 24 Schwachstellen behebt. Die schwerste, CVE-2026-97229, erhielt die höchstmögliche Schweregradbewertung: 10 von 10. Sie ermöglicht es jemandem ohne Konto auf Ihrem Server, eigenen Code darauf auszuführen. Betroffen ist jeder Server mit den Versionen 19.2 vor 19.2.8, 19.3 vor 19.3.5 oder 19.4 vor 19.4.2. Die einzige Lösung, die GitLab nennt, ist ein Upgrade auf 19.4.2, 19.3.5 oder 19.2.8. Wenn Sie den Cloud-Dienst GitLab.com nutzen, müssen Sie nichts tun.

Was ist GitLab, und warum sollte es Unternehmer interessieren?

In GitLab bewahrt Ihr technisches Team den Quellcode Ihrer Systeme und Apps auf, und dort werden neue Versionen gebaut und auf Ihre Server ausgeliefert. Viele Unternehmen betreiben es auf einem eigenen Server statt im Cloud-Dienst, um Code und Daten im Unternehmen zu halten. Dieser Server enthält meist mehr, als der Inhaber erwartet: den vollständigen Quellcode, Datenbankpasswörter, die Schlüssel für die Anbindung an Zahlungsanbieter und Behördendienste sowie das Recht, auf die Server zu deployen, die Ihre Kunden nutzen. Wer ihn kontrolliert, kann all das lesen und Ihren Code verändern, bevor er Ihre Kunden erreicht.

Was genau hat GitLab bekannt gegeben?

Laut der offiziellen Patch-Ankündigung von GitLab liegt die Schwachstelle in dem Teil, der reguläre Ausdrücke in den Einstellungen der Build- und Deployment-Pipelines (CI/CD) verarbeitet. Ein regulärer Ausdruck ist ein kurzer Text, der ein Suchmuster beschreibt. Laut der Ankündigung könnte die Schwachstelle es einem nicht authentifizierten Nutzer ermöglichen, über einen speziell präparierten regulären Ausdruck beliebigen Code auf dem GitLab-Server auszuführen, weil diese Ausdrücke unzureichend validiert werden. Ein Forscher hat sie über das Bug-Bounty-Programm von GitLab auf HackerOne gemeldet.

Die Ankündigung sagt nicht, dass die Schwachstelle ausgenutzt wurde. Aber eine Bewertung von 10 bedeutet, dass sie über das Internet ausgenutzt werden kann, ohne Passwort und ohne Hilfe eines Mitarbeiters. Angreifer beginnen in der Regel wenige Tage nach Veröffentlichung einer Korrektur, nach solchen Schwachstellen zu suchen, weil die Korrektur selbst zeigt, wo die Schwäche liegt.

Was enthält der Patch noch?

Derselbe Patch behebt 23 weitere Schwachstellen, fünf davon mit hohem Schweregrad:

  • Eine Einschleusung bösartiger Skripte (XSS) in der Syntaxhervorhebung, bewertet mit 8,7.
  • Eine Autorisierungslücke beim Erstellen von Pipelines, bewertet mit 8,5.
  • Ein zu großzügiger regulärer Ausdruck, der den Dateizugriff betrifft, bewertet mit 8,2.
  • Eine Autorisierungslücke in den Richtlinien zur Pipeline-Ausführung in der kostenpflichtigen Edition, bewertet mit 7,7.
  • Eine Prompt-Injection-Lücke im KI-Agenten GitLab Duo in der kostenpflichtigen Edition, bewertet mit 7,3.

Versionen älter als 19.2, die von der kritischen Schwachstelle nicht betroffen sind, sind also nicht unbedingt sicher. Die offizielle Wartungsrichtlinie von GitLab besagt, dass Sicherheitskorrekturen nur für die aktuelle Version und die beiden vorherigen Monatsversionen zurückportiert werden. Ein Server mit einer älteren Version erhält überhaupt keine Sicherheitskorrekturen mehr und muss ohnehin aktualisiert werden.

Wer muss handeln?

  • Nutzer der Cloud GitLab.com: nichts zu tun; laut GitLab läuft der Dienst bereits mit der gepatchten Version.
  • Kunden von GitLab Dedicated: ebenfalls nichts zu tun, laut der Ankündigung.
  • Alle, die GitLab auf einem eigenen Server betreiben: sofort aktualisieren. Das ist die ausdrückliche Empfehlung von GitLab für jede selbst verwaltete Installation.
  • Alle, die nicht sicher sind, wo ihr GitLab läuft: Fragen Sie noch heute Ihr Team oder den Dienstleister, der Ihre Systeme entwickelt hat. Viele interne Server wurden von einem früheren Dienstleister eingerichtet und dann vergessen.

Praktische Schritte für diese Woche

  1. Version ermitteln: Bitten Sie Ihre technische Leitung, in GitLab die Hilfeseite zu öffnen, die dort angezeigte Versionsnummer abzulesen und mit den oben genannten Nummern zu vergleichen.
  2. Upgrade heute planen, nicht am Monatsende: Laut der Ankündigung von GitLab ist ein Single-Node-Server während des Patches nicht erreichbar, bis die Datenbankmigrationen abgeschlossen sind, während Multi-Node-Setups ohne Ausfallzeit gepatcht werden können, wenn das passende Zero-Downtime-Verfahren befolgt wird. Eine Stunde Ausfall außerhalb der Arbeitszeit kostet weit weniger als ein kompromittierter Server.
  3. Wenn Sie auf 19.3 sind: Gehen Sie direkt auf 19.3.5, nicht auf 19.3.4. Die Ankündigung weist darauf hin, dass 19.3.4 einen Fehler hatte, der Merge-Request-Seiten bei aktivierter Ona-Integration betraf und in 19.3.5 behoben wurde.
  4. Internet-Exposition verringern: Wenn niemand außerhalb des Unternehmens Ihren GitLab-Server erreichen muss, lassen Sie ihn nur Verbindungen aus dem Firmennetz oder über ein VPN annehmen. Das ersetzt das Patchen nicht, verengt aber beim nächsten Mal die Tür.
  5. Nach dem Patchen prüfen: Überprüfen Sie kürzlich erstellte Nutzer, Schlüssel und Zugriffstoken. Wenn etwas auftaucht, das niemand kennt, ändern Sie die auf dem Server gespeicherten Passwörter und Schlüssel.

Die Upgrade-Schritte für jede Installationsmethode finden Sie im offiziellen Upgrade-Leitfaden von GitLab.

Die Sicht von Origami

Wir nutzen GitLab jeden Tag, denn unsere Repositorys liegen dort, und verfolgen seine Sicherheitsankündigungen deshalb so genau wie unsere Rechnungen. Die Lehre reicht über GitLab hinaus: Jedes System, das Sie selbst betreiben, um Ihre Daten im Haus zu behalten, bringt die Pflicht mit sich, es am Tag des Erscheinens einer Korrektur zu patchen. Das Problem, das wir am häufigsten sehen, ist nicht diese Entscheidung selbst, sondern der fehlende Name der Person, die für Updates verantwortlich ist. Ein Server, den ein Dienstleister vor drei Jahren eingerichtet hat und von dem niemand weiß, wer ihn wartet, ist das Erste, wonach ein Angreifer sucht. Dasselbe haben wir zur Schwachstelle in Magento-Shops gesagt: Patchen allein reicht nicht, wenn es zu spät kommt. Wenn Sie jemanden brauchen, der Ihre Server prüft oder deren Updates übernimmt, nehmen Sie Kontakt auf.

Quellen