# Vorfall-Lagebild: GitLab: kritische Lücke CVE-2026-97229

Von Max Gilg · 14.10.2026 · 9 Min. Lesezeit

Kurz gesagt: Erstmeldung zu „GitLab: kritische Lücke CVE-2026-97229“: was bekannt ist, was offen ist und was wahrscheinlich passiert ist.
Vorfall-Lagebild · Erstmeldung · Stand 14.10.2026 08:26 – Prozent = Einschätzung: 100 % bestätigt, 0 % sicher falsch.

[Bild: Infografik: GitLab CVE-2026-97229: kritische RCE-Lücke]

Wissensstand: Wissen 43 % · wahrscheinlich 27 % · nicht bekannt 30 %

Am 12.10.2026 hat GitLab für selbst gehostete CE/EE-Instanzen die Versionen 19.4.2, 19.3.5 und 19.2.8 veröffentlicht. Damit ist CVE-2026-97229 geschlossen, ein Integer-Overflow im CI/CD-Regex-Compiler mit CVSS 10.0, über den Angreifer Code auf dem GitLab-Server ausführen können. Rapid7 hat die RCE nachgestellt und am 13.10. einen Proof of Concept verlinkt. In der Praxis braucht ein Angreifer laut Rapid7 ein Konto, mit dem er in ein öffentliches Projekt committen kann. Bis 13./14.10. ist keine Ausnutzung in freier Wildbahn bestätigt, die Lücke steht nicht im CISA-KEV, und ein konkreter Geschädigter ist nicht bekannt. Für Maschinenbauer und Hersteller ist der Fall heikel, weil dort in GitLab oft Quellcode, SPS-Projekte, Firmware-Build-Pipelines und CI/CD-Secrets liegen. Die Schwester-Lücke CVE-2026-85706 wurde im September etwa einen Tag nach dem Patch ausgenutzt.

## 1. Was ist passiert, und warum?

- Wissen: GitLab hat am 12.10.2026 kritische Patch-Releases für CE/EE veröffentlicht: 19.4.2, 19.3.5 und 19.2.8. Insgesamt sind es 24 Sicherheitsfixes (1 kritisch, 5 hoch, 14 mittel, 4 niedrig). (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Wissen: CVE-2026-97229 ist ein Integer-Overflow im CI/CD-Regex-Compiler. Laut GitLab kann ein nicht authentifizierter Nutzer „unter bestimmten Bedingungen“ über eine präparierte CI/CD-Konfiguration beliebigen Code auf dem Server ausführen. Bewertung: CVSS 3.1 = 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Wissen: Betroffen sind 19.2 vor 19.2.8, 19.3 vor 19.3.5 und 19.4 vor 19.4.2. Version 19.3.4 hatte einen Bug bei Merge-Request-Seiten (Ona-Integration), den 19.3.5 behebt. 19.3.5 ist deshalb der richtige Stand. (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Wissen: Laut Rapid7 besteht der präparierte reguläre Ausdruck zunächst GitLabs Prüfung. Danach erzeugt Rubys Regex-Engine beim erneuten Kompilieren ungültige Instruktionen, und am Ende wird Code als Benutzer „git“ ausgeführt. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Rapid7 widerspricht der Einstufung „unauthentifiziert“ teilweise. Der Angreifer muss eine bösartige CI/CD-Konfiguration in einen Branch eines öffentlichen Projekts committen können. Wo sich jeder selbst registrieren und Projekte anlegen kann, fällt diese Hürde praktisch weg. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Gemeldet hat die Lücke ein Forscher mit dem Handle „joaxcar“ über GitLabs HackerOne-Programm, also über ein Bug-Bounty-Programm und nicht wegen eines beobachteten Angriffs. (100 %) – Quelle (https://www.helpnetsecurity.com/2026/10/13/gitlab-ci-cd-regular-expression-compiler-vulnerability-cve-2026-97229/ ; https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/)

- Wissen: Im selben Release wurden weitere hohe Lücken geschlossen: CVE-2026-92883 (XSS, CVSS 8.7) und CVE-2026-16301 (fehlende Berechtigungsprüfung bei Downstream-Pipelines bzw. Pipelines auf geschützten Branches, CVSS 8.5). (100 %) – Quelle (https://cert.europa.eu/publications/security-advisories/2026-016/ ; https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Nicht bekannt: Ob jemand die Lücke schon vor dem Patch kannte oder gegen echte Instanzen ausgenutzt hat.

- Nicht bekannt: Seit welcher Version der fehlerhafte Code in GitLab steckt (widersprüchlich: A sieht in den Quellen teils 19.1, teils 19.2 als Beginn / B nennt eine Sekundärquelle (techjacksolutions) mit Versionen ab 18.1, ohne Primärbeleg). Belegt ist nur der Bereich 19.2 bis 19.4.1 aus dem GitLab-Advisory.

- Nicht bekannt: Technische Details aus dem GitLab-Issue-Tracker. GitLab veröffentlicht sie erst 90 Tage nach dem Patch.

- Einschätzung: Es handelt sich um einen gewöhnlichen Programmierfehler, den ein Forscher gefunden und verantwortungsvoll gemeldet hat, nicht um eine gezielte Backdoor. (85 %) – Die Meldung kam über HackerOne, und ein Integer-Overflow ist ein typischer Programmierfehler.

- Einschätzung: Auf typischen Firmen-Instanzen ohne öffentliche Registrierung greift die Einstufung „unauthentifiziert“ in der Praxis zu hoch, dort braucht ein Angreifer ein Konto. (70 %) – Rapid7 knüpft die Reproduktion ausdrücklich an ein Konto mit Commit-Recht auf ein öffentliches Projekt. Wie viele Instanzen offene Registrierung haben, ist nicht bekannt.

## 2. Was ist die Auswirkung?

- Wissen: Bei erfolgreicher Ausnutzung kann ein Angreifer beliebigen Code auf dem GitLab-Server ausführen, und zwar als Benutzer „git“. Rapid7 hat das auf einem ungepatchten GitLab 19.4.1 CE nachgestellt. Gegen 19.4.2 funktionierte dieselbe Eingabe nicht. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Betroffen sind nur selbst gehostete Instanzen. GitLab.com ist gepatcht, Kunden von GitLab Dedicated müssen nichts tun. (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Wissen: Laut Rapid7 ist bisher keine Ausnutzung in freier Wildbahn bestätigt. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Laut CERT-EU ist unter den übrigen Fixes auch eine Cache-Poisoning-Lücke (CVSS 8.2), über die geschützte CI/CD-Variablen offengelegt werden könnten. (100 %) – Quelle (https://cert.europa.eu/publications/security-advisories/2026-016/)

- Wissen: Für die Schwester-Lücke CVE-2026-85706 nennen Analysten als Folgen: Diebstahl von CI/CD-Variablen, Runner-Tokens, SSH- und Deploy-Keys, kompromittierte Pipelines und Lateral Movement auf weitere Systeme. (100 %) – Quelle (https://www.infoq.com/news/2026/10/gitlab-critical-vulnerabilities/)

- Nicht bekannt: Ob es konkrete Opfer oder Schäden gibt, insbesondere in DACH oder in der Industrie.

- Nicht bekannt: Ob irgendwo Daten, Zugangsdaten oder Pipelines tatsächlich abgeflossen oder manipuliert wurden.

- Nicht bekannt: Ob ein Industrie- oder OT-Betreiber betroffen ist. Dazu gibt es keinen öffentlichen Beleg.

- Einschätzung: Nach einer erfolgreichen RCE wären die Secrets auf dem Server (Quellcode, CI/CD-Variablen, Runner- und Deploy-Tokens, Keys) für den Angreifer erreichbar. (75 %) – Der Code läuft im Kontext des GitLab-Dienstes, der genau diese Daten verwaltet. Bei der Schwester-Lücke haben Analysten das ähnlich beschrieben. Für diese CVE ist es nicht einzeln belegt, und der genaue Umfang hängt von der Installation ab.

- Einschätzung: Bei Herstellern, die Firmware oder Software über GitLab-Pipelines bauen, bestünde das Risiko manipulierter Builds vor der Auslieferung an Kunden (Supply Chain). (40 %) – Technisch naheliegend, weil der Server die Pipelines steuert. Es braucht aber zusätzliche Schritte, ein Fall ist nicht bekannt, und viel hängt davon ab, ob Builds signiert und Runner getrennt sind.

## 3. Wie lange dauert es digital (Wiederherstellung IT)?

- Wissen: Das Update enthält Datenbank- bzw. Post-Deploy-Migrationen. Single-Node-Instanzen haben beim Upgrade eine Downtime, Multi-Node-Instanzen lassen sich ohne Downtime aktualisieren. (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Wissen: Rapid7 rät, außerhalb des normalen Zyklus zu patchen. Übergangsweise soll man anonymen Zugriff auf öffentliche Projekte einschränken und nicht vertrauenswürdigen Nutzern das Anlegen und Beschreiben öffentlicher Projekte verbieten. Das blockiert nur den gezeigten Weg und ersetzt den Patch nicht. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Bei der Schwester-Lücke wurde empfohlen, Deploy-Tokens, CI-Variablen und SSH-Keys zu rotieren und die Logs zu durchsuchen. (100 %) – Quelle (https://www.infoq.com/news/2026/10/gitlab-critical-vulnerabilities/)

- Nicht bekannt: Wie viele Betreiber schon gepatcht haben.

- Nicht bekannt: Wie lange eine Wiederherstellung dauert. Gesicherte Zahlen gibt es nicht, weil kein konkreter Vorfall bekannt ist.

- Nicht bekannt: Ob es für diese CVE bereits Indicators of Compromise gibt.

- Einschätzung: Wer noch nicht kompromittiert ist, spielt das Update in Stunden ein. (70 %) – Es ist ein regulärer Patch-Release mit dokumentiertem Upgrade-Pfad. Das gilt aber nur für gepflegte Instanzen, und die Dauer hängt von Größe und Architektur ab.

- Einschätzung: Nach einer echten Kompromittierung dauert die Bereinigung eher Tage bis Wochen: Secrets rotieren, Pipelines und Artefakte prüfen, gegebenenfalls neu aufsetzen. (60 %) – Erfahrungswert aus der Incident Response bei kompromittierten DevOps- und CI/CD-Plattformen. Alle Secrets müssen als kompromittiert gelten. Für diesen Fall gibt es keine Daten.

[Bild: Diagramm: GitLab-Patch 19.4.2: 24 Sicherheitsfixes (Quelle: GitLab Patch Release 19.4.2 (docs.gitlab.com))]

## 4. Ist in der Anlage etwas kaputt, das lange dauert?

- Wissen: Die Lücke betrifft die GitLab-Serversoftware, also IT bzw. die Entwicklungsumgebung, und nicht direkt Steuerungen oder Anlagen. Die Quellen nennen keinen physischen Schaden. (100 %) – Quelle (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)

- Nicht bekannt: Ob manipulierte SPS-Programme oder Firmware über eine kompromittierte Pipeline in Anlagen gelangt sind. Dafür gibt es keinen Hinweis.

- Nicht bekannt: Wie viele OT-Betreiber oder Maschinenbauer GitLab mit SPS-Projekten oder Firmware-Pipelines selbst hosten.

- Einschätzung: Kurzfristig entsteht durch diese Lücke kein physischer Schaden an Anlagen. (85 %) – Es gibt keine direkte Verbindung zur Leittechnik. Für einen Schaden bräuchte es eine lange Kette: Kompromittierung, dann manipulierter Code, dann Auslieferung und Einspielen in die Anlage. Nichts davon ist beobachtet.

- Einschätzung: Das realistischere indirekte OT-Risiko: Angreifer stehlen Zugangsdaten, Projekte oder Fernwartungsinformationen aus GitLab. (45 %) – In Entwicklungs-Repos liegen oft Zugangsdaten und Konfigurationen. Für diese CVE ist kein Fall belegt.

- Einschätzung: Manipulierte Steuerungssoftware oder Firmware landet unbemerkt bei Kunden. (20 %) – Das Supply-Chain-Szenario ist grundsätzlich bekannt. Für einen konkreten Fall fehlen aber Ausnutzung, Ziel und Zugang zur Pipeline.

## 5. Wie viele solcher Ziele gibt es?

- Wissen: Für CVE-2026-97229 gibt es bisher keine veröffentlichte Zahl öffentlich erreichbarer, verwundbarer Instanzen. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: Bei der Schwester-Lücke CVE-2026-85706 im September zählte Shadowserver laut Cybernews mindestens 13.700 öffentlich erreichbare, verwundbare GitLab-Server. Censys zählte mehr als 86.000 erreichbare GitLab-Hosts, Deutschland mit rund 12.249 auf Platz 3 hinter China und den USA. Die Seite war nur über einen Suchauszug lesbar, die Primärquelle ist nicht geprüft. (100 %) – Quelle (https://cybernews.com/security/gitlab-attackers-find-thousands-exposed-servers/)

- Wissen: Laut GitLab hat die Plattform über 30 Millionen registrierte Nutzer, und mehr als 50 % der Fortune 100 nutzen sie, unter anderem Airbus und Lockheed Martin. (100 %) – Quelle (https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/)

- Wissen: Laut Cybersecurity Dive zählt auch Siemens zu den GitLab-Kunden. Daraus folgt nicht, dass Siemens betroffen ist. (100 %) – Quelle (https://www.cybersecuritydive.com/news/gitlab-vulnerability-remote-code-execution/832736/)

- Wissen: Shodan (aggregiert): OT-Protokolle öffentlich erreichbar in Deutschland: 141547 gesamt (DNP3 33250, OMRON FINS 21865, ProConOS 16366, EtherNet/IP 15741, Siemens S7 8251, OPC UA 5654) (100 %)

- Nicht bekannt: Wie viele Instanzen für CVE-2026-97229 konkret verwundbar sind, also auf 19.2 bis 19.4.1 laufen.

- Nicht bekannt: Wie viele davon offene Selbstregistrierung oder öffentliche Projekte haben.

- Nicht bekannt: Wie viele Instanzen in DACH zu Industrie oder OT gehören.

- Einschätzung: Weltweit sind fünfstellig viele selbst betriebene GitLab-Server aus dem Internet erreichbar, in Deutschland mehrere Tausend. Ein Teil davon läuft auf betroffenen Versionen. (65 %) – Das legen die Censys- und Shadowserver-Zahlen vom September nahe. Sie stammen aus einer Sekundärquelle, und wie viele Instanzen diese Lücke haben, ist offen.

- Einschätzung: Leicht ausnutzbar ist nur ein Teil dieser Instanzen, nämlich der mit offener Registrierung und öffentlichen Projekten. (65 %) – Das folgt aus den Voraussetzungen, die Rapid7 beschreibt. Der Anteil ist nicht gemessen.

- Einschätzung: Unter den betroffenen Instanzen sind auch Maschinenbauer und Komponentenhersteller aus DACH. (55 %) – GitLab ist in der Industrie-Entwicklung verbreitet, und Deutschland liegt bei erreichbaren Hosts weit vorn. Für konkrete Firmen gibt es aber keinen öffentlichen Beleg.

## 6. Kann das wieder passieren?

- Wissen: Die Schwester-Lücke CVE-2026-85706 (CVSS 10.0, Path Traversal) hat GitLab am 10.09.2026 gepatcht. CISA hat sie am 11.09.2026 in den KEV aufgenommen, mit Frist 14.09.2026. Ausnutzungsversuche wurden schnell beobachtet. (100 %) – Quelle (https://www.cybersecuritydive.com/news/gitlab-vulnerability-exploitation-cisa-kev/830278/ ; https://www.bleepingcomputer.com/news/security/cisa-hackers-now-exploit-max-severity-gitlab-flaw-in-attacks/amp/)

- Wissen: Das BSI hat im September vor aktiver Ausnutzung von GitLab-Lücken gewarnt. Viele Betreiber hatten kaum Zeit zum Patchen. (100 %) – Quelle (https://www.it-daily.net/shortnews/gitlab-luecken-bsi-warnt-admins-vor-aktiver-ausnutzung/)

- Wissen: Laut CISA-Katalog wurden seit 2021 mindestens fünf GitLab-Schwachstellen bei Angriffen ausgenutzt, darunter CVE-2021-22205 (ExifTool-RCE), die seit 03.11.2021 im KEV steht. (100 %) – Quelle (https://www.cybersecuritydive.com/news/gitlab-vulnerability-remote-code-execution/832736/ ; https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/ ; https://vulnerability.circl.lu/vuln/cve-2021-22205)

- Wissen: CVE-2026-97229 stand nach dem Patch nicht im CISA-KEV (widersprüchlich beim Zeitpunkt: A „am Morgen nach dem Patch“ / B „bis Montagmorgen, 12.10.“). Belegt ist, dass es bis 13.10. keinen KEV-Eintrag gab. (100 %) – Quelle (https://www.cybersecuritydive.com/news/gitlab-vulnerability-remote-code-execution/832736/)

- Wissen: Rapid7 hat am 13.10. einen Link zu seinem Proof-of-Concept-Repository ergänzt. (100 %) – Quelle (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/)

- Wissen: CERT-EU rät, sofort zu patchen und öffentlich erreichbare Instanzen zuerst zu behandeln. (100 %) – Quelle (https://cert.europa.eu/publications/security-advisories/2026-016/)

- Nicht bekannt: Ob und wann CISA die Lücke in den KEV aufnimmt.

- Nicht bekannt: Ob neben dem Rapid7-PoC weiterer funktionierender Exploit-Code öffentlich ist. Andere Einträge auf Sploitus sind nach eigener Beschreibung kein funktionierender RCE-PoC.

- Nicht bekannt: Ob das BSI einen eigenen Hinweis (WID-SEC) zu dieser CVE veröffentlicht hat. Gefunden wurde keiner.

- Einschätzung: In den kommenden Tagen bis Wochen kommt es zu Ausnutzungsversuchen gegen ungepatchte Instanzen. (65 %) – Die Schwester-Lücke wurde innerhalb eines Tages ausgenutzt, Rapid7 hat die RCE nachgestellt und einen PoC verlinkt. Die Kontovoraussetzung senkt aber die Zahl der Ziele. A schätzt 70, B 65; übernommen ist der niedrigere Wert.

- Einschätzung: Weitere kritische GitLab-Lücken werden folgen. (80 %) – Allein seit August 2026 gab es mehrere kritische, teils ausgenutzte GitLab-Lücken. Komplexe Software mit großer Angriffsfläche hat solche Fehler regelmäßig.

[Bild: Schema: So läuft der Angriff laut Rapid7 ab]

## Quellen

- https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/

- https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/

- https://www.helpnetsecurity.com/2026/10/13/gitlab-ci-cd-regular-expression-compiler-vulnerability-cve-2026-97229/ ; https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/

- https://cert.europa.eu/publications/security-advisories/2026-016/ ; https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/

- https://cert.europa.eu/publications/security-advisories/2026-016/

- https://www.infoq.com/news/2026/10/gitlab-critical-vulnerabilities/

- https://cybernews.com/security/gitlab-attackers-find-thousands-exposed-servers/

- https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/

- https://www.cybersecuritydive.com/news/gitlab-vulnerability-remote-code-execution/832736/

- https://www.cybersecuritydive.com/news/gitlab-vulnerability-exploitation-cisa-kev/830278/ ; https://www.bleepingcomputer.com/news/security/cisa-hackers-now-exploit-max-severity-gitlab-flaw-in-attacks/amp/

- https://www.it-daily.net/shortnews/gitlab-luecken-bsi-warnt-admins-vor-aktiver-ausnutzung/

- https://www.cybersecuritydive.com/news/gitlab-vulnerability-remote-code-execution/832736/ ; https://www.bleepingcomputer.com/news/security/gitlab-warns-of-max-severity-rce-flaw-in-regex-compiler-engine/ ; https://vulnerability.circl.lu/vuln/cve-2021-22205

Den vollständigen Bericht als PDF und alle verfolgten Vorfälle finden Sie unter Vorfall-Lagebilder (/vorfaelle/).

Fachliche Einschätzung auf Basis öffentlicher Quellen, keine Schuldzuweisung an Betroffene.

[Bild: Max Gilg]Über den Autor
Max Gilg ist OT-Cybersecurity-Experte aus Rosenheim und in der Anlagentechnik zu Hause – dort, wo IT die echte Welt sabotiert. Seit über 15 Jahren schützt er Strom, Wasser und Industrie (heute mit Dragos, zuvor u. a. Claroty, Stadtwerke Rosenheim) und ordnet für Redaktionen Angriffe und unklare Schadensereignisse ein – kurzfristig, auch live aus dem Studio in Rosenheim. Mehr über Max Gilg → (/max-gilg/)
← Alle Artikel (/blog/)
Zuletzt aktualisiert: 14.10.2026
Seite teilen: LinkedIn (https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html)XING (https://www.xing.com/spi/shares/new?url=https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html)Facebook (https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html)X (https://twitter.com/intent/tweet?url=https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html&text=Vorfall-Lagebild%3A%20GitLab%3A%20kritische%20L%C3%BCcke%20CVE-2026-97229)WhatsApp (https://wa.me/?text=Vorfall-Lagebild%3A%20GitLab%3A%20kritische%20L%C3%BCcke%20CVE-2026-97229%20https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html)E-Mail (mailto:?subject=Vorfall-Lagebild%3A%20GitLab%3A%20kritische%20L%C3%BCcke%20CVE-2026-97229&body=https%3A%2F%2Fot-cyber.de%2Fblog%2Fvorfall-lagebild-gitlab-kritische-luecke-cve-2026-97229.html)
