Orthanc DICOM Server
Memory Exhaustion via Forged ZIP Metadata
Orthanc auto-detects ZIP archives uploaded to POST /instances by magic bytes and unpacks them with ZipReader::ReadNextFile. The reader trusts the uncompressed_size field from ZIP central-directory metadata and calls content.resize() for that size with no upper bound. A small ZIP with a forged ~4 GB size triggers a giant allocation per request.
Description
Orthanc accepts ZIP archives uploaded to POST /instances and unpacks them entry by entry, treating each contained file as a candidate DICOM. The upload handler detects ZIP archives by their magic bytes (PK\x03\x04) and constructs a ZipReader:
OrthancServer/Sources/OrthancRestApi/OrthancRestApi.cpp:172
if (ZipReader::IsZipMemoryBuffer(call.GetBodyData(), call.GetBodySize())){ std::unique_ptr<ZipReader> reader(ZipReader::CreateFromMemory(...)); std::string filename, content; while (reader->ReadNextFile(filename, content)) // triggers resize { // ... processes extracted file as DICOM }}ReadNextFile() queries minizip for the entry's metadata via unzGetCurrentFileInfo64, then resizes the output buffer to whatever uncompressed_size the ZIP itself declares — without any upper bound:
OrthancFramework/Sources/Compression/ZipReader.cpp:294-322
unz_file_info64_s info;if (unzGetCurrentFileInfo64(pimpl_->unzip_, &info, ...) != 0){ throw OrthancException(ErrorCode_BadFileFormat);}
content.resize(info.uncompressed_size); // trusts ZIP metadata, no upper boundAn attacker constructs a 126-byte ZIP file with a dummy 64-byte entry, then patches the uncompressed_size field in both the local file header and the central directory to 0xFFFFFFFE (~4 GB). The minizip layer reads the patched value verbatim and returns it through info.uncompressed_size. content.resize() then allocates and zero-initializes ~4 GB before any decompression actually starts.
Twenty concurrent POST /instances requests each carrying a 126-byte forged ZIP allocate ~80 GB collectively. The Linux OOM killer terminates the Orthanc process with exit code 137. The total attack payload is 2,520 bytes (20 × 126 bytes); no valid DICOM data is required, only a valid ZIP structure with forged size metadata.
Authentication is required: the auth check at HttpServer.cpp:1298 runs before the ZIP processing in the POST /instances handler at OrthancRestApi.cpp:172. This is the same class of trust-the-metadata bug as CVE-2026-5440 (unbounded Content-Length) and CVE-2026-5438 (gzip ISIZE bomb).
Impact
- Denial of service: a burst of ~20 concurrent uploads of 126-byte forged-ZIP payloads terminates the Orthanc process via the Linux OOM killer (exit code 137).
- Total attack payload is 2,520 bytes (20 × 126-byte ZIPs). No valid DICOM data is required, only a valid ZIP structure with forged size metadata.
- The server must be restarted after each crash and is immediately vulnerable to the same attack again.
Mitigation
Update Orthanc to version 1.12.11 or later. The fix bounds the resize against a configurable maximum entry size and rejects entries that exceed it with BadFileFormat. As defense in depth, configure your reverse proxy to enforce a hard Content-Length ceiling appropriate to your DICOM workload — typically a few hundred MB — which also caps the Content-Length bomb in CVE-2026-5440 and the gzip bomb in CVE-2026-5438.
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). The forged ZIP triggers a ~4 GB allocation regardless of upload size, but a per-request body cap reduces the attack surface for the family of trust-the-metadata bombs (this finding plusCVE-2026-5440andCVE-2026-5438).Rate-limit POST /instances.
The attack relies on bursts of concurrent uploads. Per-IP request-rate or concurrent-connection limits at the proxy meaningfully raise the cost.
Audit credentials.
Any authenticated user with
POST /instancesrights can trigger the bug. ReviewRegisteredUsersinorthanc.jsonand any external authentication backend; revoke unused or over-permissioned API tokens.Watch for OOM-restart cycles.
Alert on repeated SIGKILL exits in your service supervisor (e.g.
journalctl -u orthanc | grep -E 'killed|OOM|exit code 137'). A recurring cycle indicates ongoing exploitation rather than a one-off resource event.
Severity Reasoning
POST /instances.AC:LA single forged ZIP with a patched uncompressed_size field; no timing or environmental conditions.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 ZIP processing and only an authenticated caller can trigger the allocation.UI:NNo interaction by a second user is needed.S:UThe OOM killer terminates the Orthanc process; the impacted component is the process itself.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.