CVE-2026-5438: Orthanc Gzip Decompression DoS Vulnerability

CVE-2026-5438 Overview

A gzip decompression bomb vulnerability exists in Orthanc DICOM server when processing HTTP requests with Content-Encoding: gzip. The server fails to enforce limits on decompressed size and allocates memory based on attacker-controlled compression metadata. A specially crafted gzip payload can trigger excessive memory allocation, leading to resource exhaustion and denial of service conditions.

This vulnerability affects Orthanc, an open-source DICOM (Digital Imaging and Communications in Medicine) server commonly used in healthcare environments for medical imaging workflows. The lack of proper decompression size validation allows remote attackers to crash the server or exhaust system resources with minimal bandwidth.

Critical Impact

Remote attackers can exhaust server memory using specially crafted gzip-compressed HTTP requests, causing denial of service to critical medical imaging infrastructure.

Affected Products

• Orthanc DICOM Server (affected versions not yet specified)

Discovery Timeline

• 2026-04-09 - CVE-2026-5438 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-5438

Vulnerability Analysis

This vulnerability belongs to the class of decompression bomb (also known as "zip bomb" or "billion laughs" style) attacks targeting gzip-encoded HTTP content. When Orthanc receives an HTTP request with the Content-Encoding: gzip header, it attempts to decompress the request body before processing. The vulnerability stems from the server trusting attacker-controlled metadata within the gzip stream without validating the actual decompressed size against reasonable limits.

In a typical decompression bomb scenario, an attacker crafts a small compressed payload (often just kilobytes) that expands to gigabytes of data when decompressed. Since the server allocates memory based on the decompression output, this can rapidly exhaust available system memory, crash the Orthanc process, or destabilize the entire host system.

Healthcare environments running Orthanc for medical imaging are particularly vulnerable since DICOM servers often need to be accessible on internal networks and may handle large imaging datasets, making unusual memory consumption patterns harder to detect immediately.

Root Cause

The root cause is improper input validation in the HTTP request handling code. Specifically, Orthanc does not implement:

• A maximum decompressed size limit for gzip-encoded request bodies
• Ratio-based detection to identify suspicious compression ratios (e.g., when a small compressed payload decompresses to an unexpectedly large size)
• Streaming decompression with incremental size checks

The server allocates memory proportional to the uncompressed data size without safeguards, allowing attackers to control memory allocation through carefully crafted compression metadata.

Attack Vector

The attack can be executed remotely by any attacker who can send HTTP requests to the Orthanc server. The attacker constructs a malicious gzip payload with an extremely high compression ratio and sends it to any Orthanc endpoint that accepts gzip-encoded content.

The attack workflow involves:

1. The attacker creates a gzip bomb payload containing highly repetitive data that compresses to a small size
2. The attacker sends an HTTP request to the Orthanc server with Content-Encoding: gzip header and the malicious payload
3. Orthanc's HTTP handler decompresses the payload without size validation
4. The server attempts to allocate memory for the full decompressed content
5. System memory is exhausted, causing denial of service

For additional technical details, refer to the CERT Vulnerability Advisory and the Orthanc Server Documentation.

Detection Methods for CVE-2026-5438

Indicators of Compromise

• HTTP requests to Orthanc with Content-Encoding: gzip header containing abnormally small payloads (typically under 100KB)
• Sudden spikes in memory usage on systems running Orthanc
• Orthanc process crashes or out-of-memory (OOM) killer events in system logs
• Unusual volume of HTTP POST requests from single source IPs targeting Orthanc endpoints

Detection Strategies

• Monitor Orthanc process memory usage and establish baseline thresholds for alerting
• Implement network-level inspection for HTTP requests with Content-Encoding: gzip and unusually small Content-Length values
• Deploy application-layer firewalls or web application firewalls (WAF) with decompression bomb detection capabilities
• Enable verbose HTTP request logging to capture headers and payload sizes for forensic analysis

Monitoring Recommendations

• Configure system-level monitoring to alert on rapid memory consumption exceeding normal operational parameters
• Set up log aggregation for Orthanc server logs and system OOM events
• Monitor for repeated connection attempts from single sources with gzip-encoded payloads
• Implement network flow analysis to detect unusual request patterns targeting DICOM server ports

How to Mitigate CVE-2026-5438

Immediate Actions Required

• Review and restrict network access to Orthanc servers, limiting exposure to trusted networks only
• Deploy a reverse proxy with request size limiting and decompression validation in front of Orthanc
• Monitor memory usage on Orthanc hosts and configure alerts for anomalous consumption
• Consider temporarily disabling gzip content encoding acceptance if operationally feasible

Patch Information

No vendor patch information is currently available for this vulnerability. Monitor the Orthanc Server Documentation and the CERT Vulnerability Advisory for updates regarding security patches and vendor guidance.

Organizations should subscribe to security announcements from Orthanc developers and apply patches as soon as they become available.

Workarounds

• Deploy a reverse proxy (such as nginx or Apache) configured to limit maximum request body size and reject oversized decompressed content
• Implement network segmentation to restrict Orthanc server access to authorized medical imaging systems only
• Configure web application firewall rules to detect and block potential decompression bomb payloads
• Set up resource limits (cgroups, ulimits) for the Orthanc process to prevent complete system memory exhaustion

Example nginx configuration to limit request body size:

# Configuration example for nginx reverse proxy
# Add to nginx server block configuration for Orthanc

# Limit maximum request body size to prevent large payload attacks
client_max_body_size 100m;

# Limit decompressed request body size (requires ngx_http_gunzip_module)
gunzip_buffers 32 4k;

# Rate limiting to slow down potential attack attempts
limit_req_zone $binary_remote_addr zone=orthanc_limit:10m rate=10r/s;
limit_req zone=orthanc_limit burst=20 nodelay;