Nine CVEs in Orthanc, and the image decoder is the soft spot

MedDevice Cyber Staff · Apr 9 · 3 min read · Via CERT/CC

CERT/CC published VU#536588 on the Orthanc open-source DICOM server, every version up to and including 1.12.10, fixed in 1.12.11. Nine CVEs, CVE-2026-5437 through CVE-2026-5445. The dangerous cluster is in the DICOM image decoder: heap buffer overflows rated as high as 9.8, out-of-bounds reads, and memory exhaustion through decompression bombs and unbounded Content-Length. Impact runs from crash and memory leak to potential remote code execution.

Memory-safety flaws of this kind live in the code that turns a stored file back into an image. A decoder reads fields describing how large the pixel data is and how it was compressed, and when it trusts those fields without checking them against the memory set aside, a crafted file can drive data past the end of a buffer. Corrupted memory can crash the process, or hand an attacker control over what it runs next.

Simon Weber and Volker Schoenefeld of Machine Spirits UG found them, the same researchers behind the OHIF work. A pattern is forming across the year: parsers that accept attacker-controlled medical file formats are where the CVEs are landing.

A DICOM server is the store and switchboard for medical images, holding studies and passing them between the equipment that produces them and the viewers that read them. A decoder that can be crashed leaves that archive unavailable, and one driven to code execution puts the repository in an outsider's hands. Because the server accepts files from many sources, hostile input need not arrive through the front door.

Because the software is open source and freely embedded, it turns up inside commercial products whose operators may not know it is there. A weakness in a shared component radiates outward to everything built on it, and each downstream maker must recognize the dependency, take in the upstream fix and ship its own update before the correction reaches a hospital.

If you embed Orthanc, get to 1.12.11. If you wrote your own decoder, the lesson transfers. Fuzz the format parser, cap the allocations, and treat every incoming DICOM object as hostile until proven otherwise.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

CERT/CC VU#536588 lists nine flaws in Orthanc through 1.12.10, including critical heap overflows in the image decoder and a decompression-bomb path to memory exhaustion. Update past 1.12.10, put the server behind authentication, and cap resource use so a single crafted file cannot exhaust memory.

Update past 1.12.10. Move to the fixed Orthanc release that closes the VU#536588 findings.
Authenticate and segment the server. Require authentication on the HTTP interface and keep the archive off any network segment that does not need it.
Bound decoder resources. Set memory and size limits on image decoding so a decompression bomb hits a limit instead of the whole host.
Harden the parser path. If you embed Orthanc or its decoder, fuzz the image path and run it with least privilege.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the properties below. Check them against your product to gauge exposure.

Required

parse_image app_file_upload

Contributing

net_wired net_remote_access app_database data_phi use_hospital_net sys_ots_software net_cloud

EMB3D

PID-3122

Fix the class in your product

A crafted file drives the parser out of bounds. As the maker, validate every length and offset against the real buffer before you copy, decode in a sandboxed least-privilege process, and fuzz the path continuously so the next bug is yours to find.

Bound every copy. Check declared sizes against allocated buffers before memcpy; prefer memory-safe parsers for new work.
Sandbox the decoder. Run it least-privilege and isolated so a crash or exploit is contained, not privileged.
Fuzz as a release gate. Run malformed-input fuzzing on every file-format parser before shipping.

Mapped EMB3D mitigations

Questions & Answers

What was disclosed in the Orthanc DICOM server?

CERT/CC VU#536588 covers nine flaws in the Orthanc open-source DICOM server through version 1.12.10, including heap overflows in the image decoder rated up to critical.

Why does the image decoder matter so much?

The decoder parses files that arrive from other systems, so a malformed image can reach it without a login. That makes the decoder the part most likely to be hit first.

Who needs to act on this?

Anyone running Orthanc directly, and also teams who embed it inside a commercial product. Update to a release past 1.12.10 and check whether your vendor bundles Orthanc under the hood.

← Back to Vulnerabilities