A crafted JPEG inside a DICOM file overflows a viewer heap

MedDevice Cyber Staff · Aug 6 · 2 min read · Via CISA

RadiAnt DICOM returns with ICSMA-26-218-01, a different flaw from its 2025 update-channel bug. CVE-2026-17264, a heap-based buffer overflow triggered when the viewer opens a DICOM file with crafted JPEG-compressed pixel data.

A heap overflow of this kind usually begins with a mismatch between what a file declares about itself and what it holds. The decoder reads length and dimension fields, reserves a block of memory sized from them, then copies the pixel data in. When the declared size and the real payload disagree, or an internal size calculation wraps, the copy runs past the end of that block into neighboring memory, corrupting structures the program later relies on.

The delivery path is what makes it clinically relevant. A malicious study does not need a special channel; it can arrive the way legitimate imaging does, referred from another facility or pulled from an archive, and land on the very workstation a radiologist reads it on. That workstation sits inside the trusted clinical network, so a foothold there is a foothold in a sensitive place. Memory corruption in a viewer is rarely the end of an attack; it is the opening move.

A DICOM object is a container, and inside it the compressed pixel data is attacker-controlled input the parser has to handle safely. CISA advises updating to 2026.1 and only opening files from trusted sources, though in practice imaging software opens whatever a clinician receives.

The same product had already appeared on the advisory list for an unrelated weakness, and viewers across this category keep drawing memory-safety findings against their image-handling code. Much of that code is mature and fast, written when the decoder's job was to render valid studies quickly rather than withstand a file built to break it. Hardening a parser to treat every field as hostile is slower and less visible than shipping features.

If you write an image decoder, fuzz it with malformed inputs until it stops crashing, then keep fuzzing. The JPEG path inside DICOM is where memory-corruption bugs hide, and this year kept proving it.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

Update RadiAnt DICOM to 2026.1 or later on every workstation that opens outside imagery. Until the fleet is patched, treat DICOM files that arrive from outside your own modalities as untrusted input and route them through a quarantine review.

Inventory RadiAnt installs. Check versions across reading workstations; anything at 2025.2 or earlier is exposed to CVE-2026-17264.
Push the 2026.1 update. The fix ships in RadiAnt DICOM 2026.1 per ICSMA-26-218-01. Prioritize workstations that receive CDs, USB media, or email-transferred studies.
Constrain untrusted imports. Open outside studies in a sandboxed or non-privileged account until patched, and strip auto-open handlers for DICOM media.
Fuzz your own parsers. If you ship an image decoder, run malformed-input fuzzing on the JPEG-in-DICOM path before an outside researcher does.

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_cloud use_hospital_net sys_ots_software data_phi net_remote_access

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 triggers CVE-2026-17264 in RadiAnt DICOM?

Maliciously crafted JPEG pixel data inside a DICOM file. When RadiAnt DICOM 2025.2 or earlier opens it, the crafted image overflows a heap buffer.

What is the realistic attack path?

Someone has to get the crafted file in front of the viewer, for example through an image sent into the workflow. It is rated medium because it needs that interaction rather than firing on its own.

How do you fix it?

Update RadiAnt DICOM past 2025.2 as directed in ICSMA-26-218-01. Handling images from outside your own systems with care reduces the exposure in the meantime.

← Back to Vulnerabilities