Orthanc DICOM Server
Memory Exhaustion via Unbounded Content-Length
Orthanc's HTTP server reads the Content-Length header into a size_t, calls body.resize() for the full declared size, then waits for body bytes the attacker never sends. With no upper bound on the resize, a handful of connections each declaring ~4 GB exhausts memory and the OOM killer terminates the process.
Description
Orthanc's HTTP server (the embedded Mongoose-derived stack) reads request bodies through ReadBodyWithContentLength(). The function parses the Content-Length header into a size_t, calls body.resize(length) to allocate and zero-initialize the full declared size, then enters a loop that calls mg_read() for the remaining body bytes — blocking up to the request timeout (~30 seconds) for data the attacker can simply not send.
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); // no upper bound check
body.resize(length); // allocates attacker-controlled bytes// ...while (length > 0){ int r = mg_read(connection, &body[pos], length); // blocks waiting for data // ...}On Linux with default memory overcommit, body.resize() succeeds optimistically and the zero-initialization commits physical memory page-by-page. Twenty concurrent connections each declaring Content-Length: 4294967295 allocate ~80 GB collectively. The kernel's OOM killer terminates the Orthanc process with exit code 137 (SIGKILL); the supervisor restarts the process, which is immediately vulnerable again.
Two characteristics distinguish this from a typical request-size DoS. First, the entire attack payload is HTTP headers — no body bytes are sent at any point, so reverse proxies that gate request size on body bytes do not catch it unless they additionally enforce a Content-Length ceiling. Second, the bug affects every POST and PUT endpoint that uses ReadBodyWithContentLength(), not only /instances.
Authentication is required: the auth check at HttpServer.cpp:1298 runs before body.resize() at HttpServer.cpp:1430. This is the same class of trust-the-metadata bug as CVE-2026-5439 (forged ZIP uncompressed_size) and CVE-2026-5438 (gzip ISIZE bomb); a single Content-Length ceiling at the reverse proxy caps all three.
Impact
- Denial of service: a burst of ~20 concurrent HTTP requests (each only HTTP headers, no body) terminates the Orthanc process via the Linux OOM killer (exit code 137).
- The bug affects every
POST/PUTendpoint that usesReadBodyWithContentLength(), not just/instances. With HTTP authentication enabled the attacker model is an authenticated caller; the published PR:N reflects deployments without HTTP auth (a permitted Orthanc configuration). - Total attack payload is a few hundred bytes of HTTP headers per connection. The attacker never sends body data; the allocation is held for up to the configured request timeout (~30 seconds).
Mitigation
Update Orthanc to version 1.12.11 or later. The fix bounds the resize against a configurable maximum and rejects oversized requests with HTTP 413 (Request Entity Too Large). As a defense-in-depth layer, configure your reverse proxy to enforce a hard Content-Length ceiling (client_max_body_size in nginx, equivalent in Traefik/HAProxy) appropriate to your DICOM workload — typically a few hundred MB.
Defender's Checklist
Verify your version.
curl -u <user>:<pass> http://<orthanc>:8042/system | jq .Version— the patched range begins at 1.12.11.Cap request size at the reverse proxy.
Configure a
Content-Lengthceiling appropriate to your DICOM workload (client_max_body_size 512m;in nginx,maxRequestBodyBytesin Traefik). This blocks the attack before it reaches Orthanc and adds a layer that survives Orthanc restarts.Rate-limit POST/PUT.
The attack relies on bursts of concurrent connections. Per-IP request-rate or concurrent-connection limits at the proxy meaningfully raise the cost of the attack.
Audit credentials.
Any authenticated user with
POST/PUTrights can trigger the bug. ReviewRegisteredUsersinorthanc.jsonand any external authentication backend; revoke unused or over-permissioned API tokens.Watch for OOM-restart cycles.
In your service supervisor, alert on repeated SIGKILL exits (e.g.
journalctl -u orthanc | grep -E 'killed|OOM|exit code 137'). A recurring restart cycle indicates ongoing exploitation rather than a one-off resource event.
Severity Reasoning
POST/PUT endpoint.AC:LNo timing or environmental pre-conditions; one HTTP header trick suffices.PR:NThe published vector reflects deployments where Orthanc is exposed without HTTP authentication, which Orthanc permits via configuration. With AuthenticationEnabled set, the auth check runs before the vulnerable allocation and only an authenticated caller can trigger it.UI:NNo interaction by a second user is needed.S:UThe OOM killer terminates the Orthanc process; the impacted component is the process itself, no out-of-process resources cross security boundaries.C:NNo information is read or disclosed.I:NNo state is modified.A:HSustained termination of the Orthanc process. Restart returns service but leaves the process vulnerable to immediate re-exploitation.References
How We Can Help
Who We Are
The security researchers behind this advisory.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec Researcher
I evaluate your SaMD with the same industry-defining security insight I contributed to the BAK MV for the revision of the B3S standard.
- PhD on Hospital Cybersecurity
- Critical vulnerabilities found in hospital systems
- Alumni of THB MedSec Research Group
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
As a former CTO and developer turned pentester, I work alongside your team to uncover vulnerabilities and find solutions that fit your architecture.
- 20+ years as CTO, 50M+ app downloads
- Architected and secured large-scale IoT fleets
- Certified Web Exploitation Specialist
- gematik Security Hero
Looking for a Penetration Test?
Machine Spirits specializes in security assessments for medical devices and healthcare IT. From MDR penetration testing to C5 cloud compliance, we help MedTech companies meet regulatory requirements.