⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

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

Bereich

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

Eine Path-Traversal-Schwachstelle in GitLab Community Edition und Enterprise Edition ermöglicht es einem nicht authentifizierten Angreifer, durch eine fehlerhafte Pfadbeschränkung und fehlende Authentifizierungsdurchsetzung im Repository-Commits-API beliebige Dateien auf dem Server zu lesen. Da kein Anmeldedaten erforderlich sind, kann ein Angreifer aus dem Netzwerk oder dem Internet auf potenziell vertrauliche Dateien zugreifen, ohne sich identifizieren zu müssen. GitLab wird in Gesundheitseinrichtungen häufig als zentrale Plattform für Softwareentwicklung, DevOps-Pipelines und die Verwaltung von Konfigurationsdateien eingesetzt; sofern dort Zugangsdaten, Konfigurationen klinischer Systeme oder patientenbezogene Daten in Repositories gespeichert sind, besteht ein erhöhtes Risiko für Datenverlust und Folgeangriffe. Angesichts der aktiven Ausnutzung laut CISA-KEV-Aufnahme ist eine sofortige Aktualisierung der GitLab-Instanz sowie eine Überprüfung der Zugriffsprotokolle dringend erforderlich.

Handlungsempfehlung

1 GitLab sofort auf die aktuell verfügbare gepatchte Version aktualisieren (Hersteller-Advisories auf gitlab.com/security prüfen) und sicherstellen, dass der Repository-Commits-API-Endpunkt nicht ohne Authentifizierung erreichbar ist.

2. GitLab-Instanz vom öffentlichen Internet isolieren oder durch Firewall-Regeln auf autorisierte Quell-IPs beschränken, bis der Patch eingespielt ist.

3. Zugriffsprotokolle des Repository-Commits-API-Endpunkts rückwirkend auf unauthentifizierte Anfragen und Path-Traversal-Muster (z. B. '../') untersuchen, um mögliche Dateiexfiltration zu erkennen.

4. Sensible Konfigurationsdateien und Credentials (z. B. .env, Datenbankpasswörter, SSH-Keys) im GitLab-Dateisystem inventarisieren und ggf. rotieren, falls ein Zugriff nicht ausgeschlossen werden kann.

5. Vorfall gemäß internem Incident-Response-Plan dokumentieren und CISO sowie Datenschutzbeauftragten informieren, da ein unbefugter Zugriff auf patientenbezogene Daten nicht ausgeschlossen werden kann.

🔒

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 →
Quelle: CISA KEV — Original-Meldung →