Die US-Cybersicherheitsbehörde CISA hat die kritische GitLab-Sicherheitslücke CVE-2026-97229 am 29. Oktober als ausgenutzt eingestuft. Bundesbehörden müssen ihre Server bis Sonntag absichern. Vor dem Update sollen sie Spuren sichern, die das Einspielen verwischen kann.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 4 Abschnitte
Siebzehn Tage nach GitLabs Notfall-Update vom 12. Oktober steht die Lücke im Katalog der CISA für ausgenutzte Schwachstellen, kurz KEV.[1] Welche Server angegriffen wurden, nennt die Behörde nicht. Öffentlich bekannt ist bislang nur der Angriffsversuch auf Alpine Linux vom 20. und 21. Oktober.
Das Wichtigste in Kürze
- Die Lücke erreicht 10,0 von 10 Punkten im Bewertungssystem CVSS, Angreifer führen ohne Anmeldung Code auf selbst betriebenen GitLab-Servern aus.
- Die Frist für US-Bundesbehörden endet am 1. November, drei Tage nach der Aufnahme in den Katalog.
- Zusätzlich verlangt die CISA eine forensische Erstprüfung der betroffenen Server.
- Laut CISA können auch andere Anwendungen betroffen sein, die die Ruby-Bibliothek Onigmo nutzen.
Warum bekommen die Behörden nur drei Tage?
Die Frist folgt aus der verbindlichen Anweisung BOD 26-04, die seit dem 10. Juni 2026 für zivile US-Bundesbehörden gilt. Die CISA begründet die Anweisung auch damit, dass Angreifer mit KI die Zeit zwischen Patch und Angriff weiter verkürzen könnten.[3] Statt am CVSS-Wert hängt die Frist an vier Fragen: Steht die Lücke im KEV-Katalog, ist der Server aus dem Internet erreichbar, lässt sich der Angriff automatisieren, und erlangt der Angreifer die volle Kontrolle? Treffen alle zu, bleiben laut CISA drei Tage.[4]
Für GitLab ist das der zweite solche Eilfall binnen sieben Wochen. Die Lücke CVE-2026-85706 in der Commit-API nahm die CISA am 11. September auf, einen Tag nach dem Patch, ebenfalls mit drei Tagen Frist und forensischer Prüfung. Die vier älteren GitLab-Einträge im Katalog hatten zwei bis drei Wochen Frist und keine Prüfpflicht.[2]
Ein Update schließt die Lücke, es beweist aber nicht, dass niemand durchgekommen ist.
Markus Seyfferth, Chefredakteur Dr. Web
Warum erst Spuren sichern und dann patchen?
Die forensische Erstprüfung soll klären, ob Angreifer den Server schon vor dem Patch übernommen haben.[1] Die CISA gibt die Reihenfolge vor: zuerst flüchtige Daten wie den Arbeitsspeicher sichern, dann Protokolle und Festplatteninhalte, erst danach das Update einspielen. Bis dahin sollen die Systeme möglichst unverändert bleiben, weil ein Patch Spuren vernichten kann.[4]
Wie schnell Spuren verloren gehen, zeigt Alpine Linux. Ein gelungener Angriff hätte dort weder einen Absturz noch einen Eintrag im Webserver-Protokoll hinterlassen. Die Protokolle der Hintergrundprozesse und das Dateisystem des alten Containers vom Angriffstag waren nicht mehr vorhanden.[5] Einen gelungenen Einbruch kann das Projekt deshalb nicht ausschließen.
Was sollten Betreiber in Deutschland jetzt tun?
Die Frist der CISA bindet nur US-Bundesbehörden, die Behörde rät aber allen Organisationen, Lücken aus dem Katalog vorrangig zu schließen.[1] Für wichtige und besonders wichtige Einrichtungen gilt in Deutschland das BSI-Gesetz: Ein erheblicher Sicherheitsvorfall geht binnen 24 Stunden als Erstmeldung an das BSI. Nach 72 Stunden folgt eine Meldung mit erster Bewertung und gegebenenfalls den Kompromittierungsindikatoren.[6] Ohne gesicherte Spuren lässt sich diese Bewertung kaum liefern. Für eigene Server gilt:
- Lief GitLab 19.2, 19.3 oder 19.4 ohne das Update vom 12. Oktober und war aus dem Internet erreichbar, vor jedem Eingriff Arbeitsspeicher, Protokolle und Container-Dateisystem sichern.
- Danach direkt auf die Fassungen vom 21. Oktober aktualisieren, etwa 19.5.1, 19.4.3, 19.3.6 oder 19.2.9. Sie schließen auch die später gemeldete Lücke CVE-2026-110264.[7]
- Selbst gebaute Images brauchen Ruby 4.0.9, 3.4.12 oder 3.3.13, sonst bleibt der Server trotz neuer Versionsnummer angreifbar.
- Die sechs Erkennungsregeln von GitLab auf die Protokolle seit dem 12. Oktober anwenden.[8]
Eine Liste aller aus dem Internet erreichbaren GitLab-Server samt Version und Ruby-Stand spart beim nächsten Katalogeintrag den ersten Tag, weitere Schritte sammeln die Cybersecurity-Grundlagen.
Quellen
8 Quellen anzeigenQuellen ausblenden
- CISACISA Adds Two Known Exploited Vulnerabilities to Catalog
- CISAKnown Exploited Vulnerabilities Catalog, Katalogversion 2026.10.29, Einträge zu GitLab
- CISABOD 26-04: Prioritizing Security Updates Based on Risk
- CISABOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk (abgerufen am 30. Oktober 2026)
- Alpine LinuxGitLab security incident: attempted exploitation of CVE-2026-97229
- Gesetz über das Bundesamt für Sicherheit in der Informationstechnik§ 32 BSIG, Meldepflichten, Absatz 1 Nummer 1 und 2
- GitLabGitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
- GitLabGitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
Mehr Newshunger?
- Alpine Linux: Ein Angreifer versuchte, eine kritische GitLab-Sicherheitslücke auszunutzen
- GitLab: Kritische Sicherheitslücke trifft alle Versionen seit 2014
- GitLab-Lücke mit CVSS 10,0: Die Commit-API prüft die Anmeldung nicht
- GitLab-Exploit ohne CVE: Warum der entscheidende Patch als Routine-Update durchging
- Kritische Cisco-Sicherheitslücke: Schadsoftware liest die Schlüssel zwischen Firmenstandorten mit
- HTTP2Shell: Lücke in Googles Brotli trifft Node.js, Python und weitere Software
