⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

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

Bereich

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

Apache Traffic Server in den Versionen 8.0.0–8.1.9, 9.0.0–9.2.14 und 10.0.0–10.1.3 weist eine kritische Schwachstelle auf, die Request Smuggling durch fehlerhaft formatierte Chunked-Transfer-Encoding-Nachrichten ermöglicht. Ein Angreifer kann dadurch HTTP-Anfragen so manipulieren, dass sie vom vorgelagerten Proxy und dem Backend-Server unterschiedlich interpretiert werden, was unter anderem Session-Hijacking, Cache-Poisoning, den Zugriff auf geschützte Backend-Routen oder die Umgehung von Sicherheitskontrollen ermöglichen kann. Apache Traffic Server wird in größeren IT-Infrastrukturen häufig als Reverse Proxy oder Load Balancer eingesetzt und kann in Gesundheitseinrichtungen vor kritischen Systemen wie KIS, PACS oder Patientenportalen betrieben werden – sofern dies der Fall ist, sind Vertraulichkeit und Integrität von Patientendaten potenziell gefährdet. Angesichts des maximalen CVSS-Scores von 10.0 ist eine umgehende Aktualisierung auf die bereitgestellten Patches höchste Priorität.

Handlungsempfehlung

1 Apache Traffic Server auf Version 9.2.15 (für 9.x-Zweig) bzw. 10.1.4 (für 10.x-Zweig) aktualisieren – Versionen 8.0.0–8.1.9, 9.0.0–9.2.14 und 10.0.0–10.1.3 sind verwundbar.

2. Prüfen, ob Apache Traffic Server als Reverse Proxy oder Load Balancer vor klinikinternen Webanwendungen (KIS, PACS, Webportalen) betrieben wird, und betroffene Instanzen sofort priorisieren.

3. Bis zur Einspielung des Patches Netzwerksegmentierung und vorgelagerte WAF/IDS-Regeln aktivieren, um manipulierte Chunked-Transfer-Encoding-Anfragen zu erkennen und zu blockieren.

4. Zugriffsprotokolle (Access Logs) des Traffic Servers auf ungewöhnliche HTTP-Anfragemuster und Request-Smuggling-Indikatoren überprüfen und ein Monitoring auf anomale Backend-Anfragen einrichten.

5. Hersteller-Advisories und BSI-Meldungen zu aktiver Ausnutzung dieser Schwachstelle beobachten und im Falle eines bestätigten Sicherheitsvorfalls den Incident-Response-Prozess nach NIS2/B3S einleiten.

🔒

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 →