A Tiny File Can Crash the Servers Storing Your Medical Scans

Imagine a hospital's radiology department going dark mid-shift — MRI results disappearing, CT scans unreachable, surgeons waiting — because someone on the internet sent one cleverly disguised file to the wrong port.

Who's at Risk — and How Many People That Really Means

Orthanc is the quiet backbone of medical imaging at thousands of hospitals, clinics, and research institutions worldwide. It's free, open-source, and trusted by organizations across more than 80 countries to store and serve the images that doctors use to diagnose cancer, assess broken bones, and guide surgeries. Estimates put active deployments in the tens of thousands, many of them internet-facing by design — because sharing scans between facilities is exactly what the software is built to do.

A newly disclosed vulnerability, tracked as CVE-2026-5438 and rated HIGH severity, means any one of those servers can be knocked offline by a single unauthenticated HTTP request. No stolen password. No inside access. Just a packet and a few seconds of patience. The consequences ripple immediately into patient care: delayed diagnoses, diverted emergency cases, and radiologists staring at error screens instead of images.

What's Actually Happening — In Plain English

Think of gzip compression the way you think of a vacuum-sealed storage bag. You stuff a winter duvet into a bag, suck out the air, and suddenly it's the size of a paperback. The bag is small and easy to carry. When you unseal it, the duvet explodes back to full size. That's compression — making big data small for easy transport, then expanding it at the destination.

Orthanc accepts compressed data over the web because it's efficient — hospitals send large imaging files back and forth constantly, and compression saves bandwidth. The problem is that Orthanc, when it receives a compressed file, doesn't ask a critical question before it starts unpacking: how big is this going to get? An attacker can craft what's known as a "decompression bomb" — a tiny compressed file, perhaps just a few kilobytes in size, that expands into hundreds of gigabytes of data when unpacked. The server faithfully tries to hold all of that in memory at once. The memory fills. The system chokes. Orthanc crashes.

What makes this particularly dangerous is the bar to entry. The attack requires no account, no credentials, and no special knowledge of the target institution. If an Orthanc server is reachable on the network — and many are, by design — an attacker can send this malformed request from anywhere in the world. Hospitals that have federated their imaging networks across campuses, or that expose Orthanc to partner clinics, are especially exposed. A single automated script could scan for and crash vulnerable servers at scale.

The Technical Detail Security Teams Need

The root cause is an unbounded decompression path in Orthanc's HTTP server layer when handling requests with the Content-Encoding: gzip header. Orthanc allocates memory based on attacker-controlled metadata embedded in the gzip stream — specifically the uncompressed size hint in the gzip header — without enforcing any server-side cap on that allocation. This is a classic resource exhaustion via decompression bomb (CWE-400 / CWE-789), and it carries a CVSS score of 7.5. The lack of a decompressed-size limit before allocation is the fix target: a hard ceiling on accepted decompressed payload size, applied before memory is committed.

Has Anyone Been Attacked Yet?

As of publication, there is no confirmed active exploitation of CVE-2026-5438 in the wild. No threat actor groups have been publicly linked to campaigns targeting this vulnerability, and no victims have been identified. That's the good news. The less comfortable news is that decompression bomb vulnerabilities are trivially weaponized — proof-of-concept payloads for this class of attack are well understood and easy to construct from public documentation. The window between "no known exploitation" and "actively scanned" tends to be short once a CVE is public, and healthcare infrastructure has become an increasingly attractive target for ransomware operators and nation-state actors alike.

Security researchers have not publicly attributed the discovery to a specific individual or team at the time of writing. The severity rating and public disclosure suggest coordinated responsible disclosure, but details of the reporting timeline have not been released.

What You Should Do Right Now

If you run, manage, or advise any organization using Orthanc, treat this as urgent. Here's what to do:

1. Check your version immediately. Log into your Orthanc instance and verify the running version via the built-in REST API at http://[your-server]/system. If a patched version has been released by the Orthanc Project (check orthanc-server.com and the official GitHub at orthanc-team/orthanc), upgrade to the latest patched release immediately. Do not wait for your next scheduled maintenance window.
2. Restrict network access as a stopgap. If you cannot patch immediately, use your firewall or network access control list to limit which IP addresses or ranges can reach Orthanc's HTTP port (default: 8042) and DICOM port (4242). Orthanc should never be openly reachable from the public internet unless there is an explicit, reviewed business requirement — and even then, it should sit behind a reverse proxy with strict request filtering.
3. Enable request size limits at the proxy layer. If Orthanc sits behind a reverse proxy (nginx, Apache, HAProxy), configure a hard cap on incoming request body size right now. In nginx, this is client_max_body_size; in Apache, it's LimitRequestBody. Setting this to a sane ceiling — typically 1GB or less, depending on your imaging workflows — will blunt this attack class even before a native patch is applied. Monitor your Orthanc logs for anomalous request patterns: repeated large Content-Encoding: gzip POST requests from unexpected sources are a red flag.

Bottom line: This is a straightforward but serious vulnerability in software that sits at the intersection of networking and patient care. The attack is easy. The impact is real. The fix path exists. Act before exploitation becomes active — in healthcare, "we'll patch it next quarter" is not an acceptable answer.