⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

🏥 Krankenhaus🏨 Fachklinik🏃 Rehaklinik🏡 Pflegeheim🔬 Labor🏢 Ambulantes Zentrum

Bereich

IT-InfrastrukturKIS-SoftwareLIS / RIS / PACSCloud-Dienste
Beschreibung

Eine Integer-Overflow- bzw. Wraparound-Schwachstelle in GitLab Community Edition und Enterprise Edition ermöglicht es einem nicht authentifizierten Angreifer, durch eine speziell präparierte Regular Expression in einer CI/CD-Konfiguration beliebigen Code auf dem GitLab-Server auszuführen. Ursache ist eine unzureichende Validierung regulärer Ausdrücke, sodass keinerlei Anmeldedaten für eine erfolgreiche Ausnutzung erforderlich sind. Im Gesundheitswesen wird GitLab häufig als Plattform für die Verwaltung von Softwareentwicklungs- und Automatisierungsprozessen eingesetzt, etwa zur Pflege von Integrationsskripten zwischen KIS, LIS oder PACS sowie für DevOps-Pipelines; sofern solche Instanzen betrieben werden, besteht das Risiko einer vollständigen Kompromittierung des Servers und damit potenziell der Patientendaten und angebundenen Systeme. Betroffene Einrichtungen sollten die GitLab-Instanz unverzüglich patchen, den unauthentifizierten Zugriff sperren und Anzeichen einer Ausnutzung prüfen.

Handlungsempfehlung

1 CI/CD-Konfigurationen in GitLab sofort auf verdächtige oder ungewöhnliche Regular Expressions prüfen und den öffentlichen (unauthentifizierten) Zugriff auf GitLab-Instanzen über Firewall-Regeln oder Netzwerksegmentierung unterbinden, bis der offizielle Patch eingespielt ist.

2. GitLab Community Edition und Enterprise Edition umgehend auf die vom Hersteller bereitgestellte gepatchte Version aktualisieren – GitLab-Sicherheitsadvisory unter https://about.gitlab.com/releases/categories/releases/ prüfen.

3. Netzwerkzugang zur GitLab-Instanz auf autorisierte interne Nutzer und IP-Bereiche beschränken; externen Zugriff ohne Authentifizierung vollständig deaktivieren.

4. Log-Dateien der GitLab-Server auf ungewöhnliche CI/CD-Pipeline-Ausführungen und Anomalien untersuchen, die auf eine mögliche Ausnutzung hinweisen könnten.

5. Interne Meldekette aktivieren und – sofern eine KRITIS-Einrichtung betroffen ist – Vorfall gemäß NIS2/BSI-Anforderungen dokumentieren und bei Anzeichen aktiver Ausnutzung beim BSI melden.

🔒

Weitere konkrete Handlungsschritte für Ihre IT-Abteilung
sind ISMShield AI Kunden vorbehalten.

Jetzt freischalten →
Regulatorische Einordnung

NIS2-Relevanz: •••    B3S: •••    ISG: ••ˆ    Meldepflicht DE: ja

🔒

Regulatorische Einordnung (NIS2, B3S, ISG, nDSG)
nur für ISMShield AI Kunden.

Details freischalten →