Orthanc DICOM Server
Speichererschöpfung durch unbegrenzte Content-Length
Der HTTP-Server von Orthanc liest den Content-Length-Header in ein size_t, ruft body.resize() für die volle deklarierte Größe auf und wartet anschließend auf Body-Bytes, die der Angreifer nie sendet. Da keine Obergrenze für die Allokation existiert, erschöpft eine Handvoll Verbindungen mit jeweils ~4 GB den Speicher und der OOM-Killer beendet den Prozess.
Beschreibung
Der HTTP-Server von Orthanc (der eingebettete Mongoose-Stack) liest Request-Bodies über ReadBodyWithContentLength(). Die Funktion parst den Content-Length-Header in ein size_t, ruft body.resize(length) zur Allokation und Null-Initialisierung der vollen deklarierten Größe auf und betritt dann eine Schleife, die mg_read() für die verbleibenden Body-Bytes aufruft — und bis zum Request-Timeout (~30 Sekunden) auf Daten wartet, die der Angreifer schlicht nicht sendet.
OrthancFramework/Sources/HttpServer/HttpServer.cpp:496-532
size_t length;int64_t tmp = boost::lexical_cast<int64_t>(contentLength);// ...length = static_cast<size_t>(tmp); // keine Obergrenze geprüft
body.resize(length); // allokiert vom Angreifer kontrollierte Bytes// ...while (length > 0){ int r = mg_read(connection, &body[pos], length); // blockiert auf Daten // ...}Auf Linux mit Default-Memory-Overcommit gelingt body.resize() optimistisch und die Null-Initialisierung committet physischen Speicher Seite für Seite. Zwanzig parallele Verbindungen mit jeweils Content-Length: 4294967295 allokieren zusammen rund 80 GB. Der OOM-Killer des Kernels beendet den Orthanc-Prozess mit Exit-Code 137 (SIGKILL); die Service-Überwachung startet den Prozess neu, der sofort wieder angreifbar ist.
Zwei Eigenschaften unterscheiden diesen Fall von einem typischen Request-Size-Denial-of-Service. Erstens besteht der gesamte Payload aus HTTP-Headern — es werden keine Body-Bytes gesendet, sodass Reverse-Proxies, die nur die übertragenen Body-Bytes begrenzen, den Angriff nicht erkennen, sofern sie keine zusätzliche Content-Length-Obergrenze erzwingen. Zweitens betrifft die Schwachstelle jeden POST- und PUT-Endpunkt, der ReadBodyWithContentLength() verwendet, nicht nur /instances.
Authentifizierung ist erforderlich: Die Auth-Prüfung in HttpServer.cpp:1298 läuft vor dem body.resize() in HttpServer.cpp:1430. Diese Schwachstelle gehört zur selben Klasse von „Den-Metadaten-Vertrauen"-Bugs wie CVE-2026-5439 (gefälschtes ZIP-uncompressed_size) und CVE-2026-5438 (gzip-ISIZE-Bombe); eine einzige Content-Length-Obergrenze am Reverse-Proxy deckt alle drei ab.
Auswirkung
- Denial-of-Service: Eine Welle von ~20 parallelen HTTP-Requests (jeweils nur HTTP-Header, kein Body) beendet den Orthanc-Prozess über den Linux-OOM-Killer (Exit-Code 137).
- Die Schwachstelle betrifft jeden
POST/PUT-Endpunkt, derReadBodyWithContentLength()verwendet, nicht nur/instances. Bei aktiver HTTP-Authentifizierung handelt es sich um einen authentisierten Aufrufer; das publizierte PR:N spiegelt Deployments ohne HTTP-Auth wider (eine zulässige Orthanc-Konfiguration). - Der gesamte Angriffs-Payload umfasst nur einige hundert Bytes HTTP-Header pro Verbindung. Es werden niemals Body-Daten gesendet; die Allokation wird bis zum konfigurierten Request-Timeout (~30 Sekunden) gehalten.
Abhilfe
Aktualisieren Sie Orthanc auf Version 1.12.11 oder höher. Der Patch begrenzt das Resize gegen ein konfigurierbares Maximum und weist überdimensionierte Requests mit HTTP 413 (Request Entity Too Large) ab. Als Defense-in-Depth-Schicht konfigurieren Sie an Ihrem Reverse-Proxy eine harte Content-Length-Obergrenze (client_max_body_size in nginx, Äquivalent in Traefik/HAProxy), passend zu Ihrer DICOM-Workload — typischerweise einige hundert MB.
Checkliste für Betreiber
Version prüfen.
curl -u <user>:<pass> http://<orthanc>:8042/system | jq .Version— der gepatchte Bereich beginnt bei 1.12.11.Request-Größe am Reverse-Proxy begrenzen.
Konfigurieren Sie eine
Content-Length-Obergrenze passend zu Ihrer DICOM-Workload (client_max_body_size 512m;in nginx,maxRequestBodyBytesin Traefik). Das blockiert den Angriff vor Erreichen von Orthanc und überlebt Orthanc-Neustarts.POST/PUT rate-limiten.
Der Angriff lebt von Bursts paralleler Verbindungen. Per-IP-Request-Rate- oder Concurrent-Connection-Limits am Proxy erhöhen die Angriffskosten spürbar.
Zugangsdaten überprüfen.
Jede authentisierte Person mit
POST/PUT-Rechten kann die Schwachstelle auslösen. Prüfen SieRegisteredUsersinorthanc.jsonund ein externes Authentifizierungsbackend; widerrufen Sie ungenutzte oder überprivilegierte API-Tokens.Auf OOM-Restart-Zyklen achten.
Alarmieren Sie in Ihrer Service-Überwachung auf wiederholte SIGKILL-Exits (z. B.
journalctl -u orthanc | grep -E 'killed|OOM|exit code 137'). Ein wiederkehrender Restart-Zyklus deutet auf laufende Ausnutzung statt auf ein einmaliges Ressourcenereignis hin.
Bewertung im Detail
POST/PUT-Endpunkt erreichbar.AC:LKeine Timing- oder Umgebungsvorbedingungen; ein einzelner HTTP-Header-Trick genügt.PR:NDer publizierte Vektor spiegelt Deployments wider, in denen Orthanc ohne HTTP-Authentifizierung exponiert ist, was Orthanc per Konfiguration erlaubt. Bei aktivem AuthenticationEnabled läuft die Auth-Prüfung vor der verwundbaren Allokation, sodass nur ein authentisierter Aufrufer die Schwachstelle auslösen kann.UI:NKeine Interaktion durch eine zweite Person erforderlich.S:UDer OOM-Killer beendet den Orthanc-Prozess; betroffen ist der Prozess selbst, keine prozessübergreifenden Ressourcen jenseits seiner Sicherheitsgrenze.C:NKeine Informationen werden gelesen oder offengelegt.I:NEs werden keine Zustände modifiziert.A:HAnhaltende Beendigung des Orthanc-Prozesses. Ein Neustart stellt den Dienst wieder her, lässt den Prozess aber sofort wieder angreifbar.Referenzen
So können wir helfen
Wer wir sind
Die Sicherheitsforscher hinter diesem Sicherheitshinweis.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec-Forscher
Ich evaluiere Ihr SaMD mit derselben branchenprägenden Sicherheitsexpertise, die ich dem BAK MV für die Überarbeitung des B3S-Standards beigetragen habe.
- Promotion über Krankenhaus-Cybersicherheit
- Kritische Schwachstellen in Krankenhaussystemen gefunden
- Alumni der THB MedSec-Forschungsgruppe
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
Als ehemaliger CTO und Entwickler, der zum Pentester wurde, arbeite ich mit Ihrem Team zusammen, um Schwachstellen aufzudecken und Lösungen zu finden, die zu Ihrer Architektur passen.
- 20+ Jahre als CTO, 50+ Mio. App-Downloads
- Architektur und Absicherung großer IoT-Flotten
- Certified Web Exploitation Specialist
- gematik Security Hero
Penetrationstest gesucht?
Machine Spirits ist spezialisiert auf Sicherheitsbewertungen für Medizinprodukte und Gesundheits-IT. Von MDR-Penetrationstests bis C5-Cloud-Compliance helfen wir MedTech-Unternehmen, regulatorische Anforderungen zu erfüllen.