⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

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

Bereich

IT-InfrastrukturKIS-SoftwareCloud-Dienste
Beschreibung

In ONLYOFFICE Docs besteht eine Path-Traversal-Schwachstelle, die selbst dann ausgenutzt werden kann, wenn JWT (JSON Web Token) zur Absicherung verwendet wird. Über eine '/..'-Sequenz in einem Bild-Upload-Parameter können Angreifer aus erlaubten Verzeichnissen ausbrechen und möglicherweise serverseitigen Code aus der Ferne ausführen (Remote Code Execution). ONLYOFFICE Docs wird in Gesundheitseinrichtungen häufig als kollaborative Dokumentenbearbeitungsplattform eingesetzt – etwa für medizinische Berichte, Befunddokumente oder administrative Unterlagen, oft integriert in bestehende KIS- oder Intranet-Umgebungen. Eine erfolgreiche Ausnutzung könnte zur vollständigen Kompromittierung des Dokumentenservers führen, wodurch Patientendaten gefährdet und abhängige klinische Prozesse gestört werden könnten. Angesichts der aktiven Ausnutzung (CISA KEV) ist umgehender Handlungsbedarf geboten: Patch einspielen, Upload-Endpunkt absichern und auf Kompromittierungsanzeichen untersuchen.

Handlungsempfehlung

1 ONLYOFFICE Docs Server sofort auf die aktuelle gepatchte Version aktualisieren (Herstellerhinweise unter onlyoffice.com/security prüfen) und bis zum Patch-Einspielen den Bild-Upload-Endpunkt durch WAF-Regeln oder Netzwerksegmentierung sperren.

2. JWT-Konfiguration überprüfen: Sicherstellen, dass JWT-Secrets stark und einzigartig sind und JWT-Validierung serverseitig korrekt erzwungen wird, da die Schwachstelle im JWT-Kontext ausgenutzt wird.

3. Web-Server-Logs auf Anfragen mit '/..'-Sequenzen in Upload-Parametern durchsuchen, um mögliche bereits erfolgte Ausnutzungsversuche zu erkennen und zu bewerten.

4. ONLYOFFICE Docs-Instanzen in einem isolierten Netzwerksegment betreiben und ausgehende Verbindungen vom Server auf das notwendige Minimum beschränken, um die Auswirkungen einer möglichen Remote-Code-Execution zu begrenzen.

5. Vorfall gemäß internem Incident-Response-Plan dokumentieren und bei Hinweisen auf aktive Ausnutzung die zuständige Meldebehörde (BSI/BACS/CERT.at) informieren.

🔒

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 →