CVE-2026-5442: DICOM Image Decoder Buffer Overflow

CVE-2026-5442 Overview

A heap buffer overflow vulnerability exists in the DICOM image decoder. Dimension fields are encoded using Value Representation (VR) Unsigned Long (UL), instead of the expected VR Unsigned Short (US), which allows extremely large dimensions to be processed. This causes an integer overflow during frame size calculation and results in out-of-bounds memory access during image decoding.

Critical Impact

Attackers can exploit this heap buffer overflow through maliciously crafted DICOM images to potentially achieve arbitrary code execution or cause denial of service in medical imaging applications.

Affected Products

• DICOM image processing software (specific versions not disclosed)
• Orthanc Server (refer to vendor advisory for affected versions)
• Medical imaging systems utilizing vulnerable DICOM decoders

Discovery Timeline

• April 9, 2026 - CVE-2026-5442 published to NVD
• April 9, 2026 - Last updated in NVD database

Technical Details for CVE-2026-5442

Vulnerability Analysis

This vulnerability stems from a fundamental type confusion issue in how DICOM image dimension fields are processed. The DICOM standard defines specific Value Representations (VR) for encoding different data types. In this case, the image decoder incorrectly handles dimension fields that use VR Unsigned Long (UL) instead of the expected VR Unsigned Short (US).

When dimension values are encoded as 32-bit unsigned integers (UL) rather than 16-bit unsigned integers (US), the decoder can process extraordinarily large dimension values that far exceed expected image boundaries. During subsequent frame size calculations, these oversized dimension values trigger an integer overflow condition.

The integer overflow results in an undersized memory allocation for the image buffer. When the decoder attempts to populate this buffer with actual image data, it writes beyond the allocated heap memory boundaries, creating a classic heap buffer overflow scenario.

Root Cause

The root cause is improper validation of DICOM Value Representation types for dimension fields. The decoder fails to enforce that dimension-related fields (Rows, Columns, and similar attributes) are encoded using the correct VR type (US - Unsigned Short). By accepting UL (Unsigned Long) encoded values, the decoder permits dimension values that exceed the 16-bit maximum (65,535), leading to integer overflow during buffer size calculations when these values are multiplied together for frame allocation.

Attack Vector

An attacker can exploit this vulnerability by crafting a malicious DICOM file with manipulated dimension field encodings. The attack proceeds as follows:

1. The attacker creates a DICOM image file where dimension fields (such as Rows and Columns) are encoded using VR type UL instead of US
2. Large dimension values are specified that, when multiplied during frame size calculation, cause an integer overflow
3. The victim's DICOM viewer or processing application opens the malicious file
4. The integer overflow results in a small buffer allocation
5. During image decoding, data is written beyond buffer boundaries, corrupting heap memory

The vulnerability can be triggered through any application that processes untrusted DICOM files, including medical imaging viewers, PACS (Picture Archiving and Communication System) servers, and image conversion utilities. For detailed technical information, refer to the CERT Vulnerability Advisory.

Detection Methods for CVE-2026-5442

Indicators of Compromise

• Unexpected application crashes in DICOM processing software with heap corruption errors
• DICOM files containing dimension fields with VR type UL instead of the standard US type
• Abnormally large dimension values in DICOM image metadata (exceeding 65,535)
• Memory access violations or segmentation faults during DICOM image loading operations

Detection Strategies

• Implement file integrity monitoring on DICOM storage directories to detect anomalous file modifications
• Deploy network-based detection rules to identify DICOM files with malformed VR type encodings in transit
• Configure application whitelisting to control which software can process DICOM files
• Use memory protection tools (ASLR, DEP, heap canaries) to detect and prevent exploitation attempts

Monitoring Recommendations

• Monitor DICOM processing applications for unusual crash patterns or memory corruption indicators
• Implement logging for all DICOM file processing operations including source and dimension metadata
• Track failed DICOM parsing attempts as potential indicators of exploitation attempts
• Enable verbose error logging in medical imaging applications to capture detailed failure information

How to Mitigate CVE-2026-5442

Immediate Actions Required

• Review DICOM processing workflows and restrict processing of files from untrusted sources
• Implement input validation to reject DICOM files with dimension fields using incorrect VR types
• Isolate DICOM processing systems from general network access where possible
• Apply available vendor patches for Orthanc Server and other affected DICOM processing software

Patch Information

Organizations should consult the CERT Vulnerability Advisory for comprehensive patch guidance. For Orthanc Server deployments, refer to the Orthanc Server Official Site for security updates. Additional technical resources may be available from Machine Spirits.

Workarounds

• Implement strict VR type validation at the DICOM parsing layer to reject dimension fields not encoded as US
• Add dimension value bounds checking to reject values exceeding reasonable thresholds (e.g., 65,535)
• Process DICOM files from untrusted sources in sandboxed environments with limited system access
• Deploy web application firewalls or DICOM-aware proxies to filter malformed DICOM files before they reach vulnerable applications

Administrators should implement strict input validation for DICOM files by configuring parsers to reject files where dimension fields use unexpected VR types. This can be achieved through pre-processing validation scripts or by enabling strict parsing modes in DICOM libraries where available.