CVE-2026-5440: HTTP Server Memory Exhaustion DoS Flaw

CVE-2026-5440 Overview

A memory exhaustion vulnerability exists in the HTTP server due to unbounded use of the Content-Length header. The server allocates memory directly based on the attacker-supplied header value without enforcing an upper limit. A crafted HTTP request containing an extremely large Content-Length value can trigger excessive memory allocation and server termination, even without sending a request body.

Critical Impact

Remote attackers can cause denial of service by sending a single malformed HTTP request with an oversized Content-Length header, leading to memory exhaustion and server termination without authentication.

Affected Products

• Orthanc Server (specific versions not specified in advisory)

Discovery Timeline

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

Technical Details for CVE-2026-5440

Vulnerability Analysis

This vulnerability represents a classic resource exhaustion attack targeting memory allocation routines in the HTTP server implementation. The flaw exists in how the server processes the Content-Length HTTP header, which is typically used to indicate the size of the request body in bytes.

When the server receives an HTTP request, it reads the Content-Length header value and uses this value to pre-allocate a memory buffer for the incoming request body. The critical flaw is that no upper bound validation is performed on this value before memory allocation occurs. An attacker can exploit this by sending an HTTP request with an arbitrarily large Content-Length value (e.g., several gigabytes or terabytes), causing the server to attempt allocating an unreasonable amount of memory.

The attack is particularly dangerous because the server attempts memory allocation immediately upon parsing the header, before any actual request body data is received. This means an attacker can exhaust server memory and cause a crash with minimal bandwidth, as only the HTTP headers need to be transmitted.

Root Cause

The root cause is improper input validation on the Content-Length HTTP header. The server implementation fails to validate or cap the incoming header value against reasonable limits before using it for memory allocation. A properly secured implementation would enforce a maximum content length limit, rejecting requests that exceed this threshold before allocating memory.

Attack Vector

The attack can be executed remotely by any network client capable of sending custom HTTP requests. The attacker crafts an HTTP request with an extremely large Content-Length header value and sends it to the vulnerable server. No authentication is required, and the attack requires minimal bandwidth since only the headers need to be transmitted. The server will attempt to allocate the specified amount of memory, exhausting available system resources and causing service termination.

The attack sequence involves:

1. Establishing a TCP connection to the target HTTP server
2. Sending HTTP headers including a malicious Content-Length value specifying gigabytes or more
3. The server parses the header and attempts memory allocation based on the malicious value
4. System memory is exhausted, causing the server process to crash or become unresponsive

Detection Methods for CVE-2026-5440

Indicators of Compromise

• HTTP requests with abnormally large Content-Length header values (exceeding tens of megabytes without corresponding body data)
• Sudden memory usage spikes on systems running the affected HTTP server
• Server process crashes or restarts without corresponding error messages in application logs
• Incomplete HTTP requests where header size greatly exceeds actual body data received

Detection Strategies

• Implement network monitoring to flag HTTP requests with Content-Length values exceeding expected thresholds
• Configure web application firewalls (WAF) to block requests with abnormally large Content-Length headers
• Monitor server process memory consumption for unusual allocation patterns
• Review HTTP access logs for requests with disproportionate header sizes relative to body content

Monitoring Recommendations

• Set up alerts for server process memory utilization exceeding normal operational thresholds
• Implement logging of all HTTP requests with Content-Length values above a configurable limit
• Monitor for repeated connection attempts from the same source IP followed by server instability
• Deploy endpoint monitoring solutions to detect resource exhaustion patterns on affected systems

How to Mitigate CVE-2026-5440

Immediate Actions Required

• Review vendor security advisories at the Orthanc Server Official Site for available patches
• Consult the CERT Vulnerability Advisory #536588 for the latest mitigation guidance
• Implement network-level controls to limit maximum HTTP request sizes
• Consider placing a reverse proxy with request size validation in front of vulnerable servers
• Restrict network access to the affected server to trusted clients only where possible

Patch Information

Users should consult the official Orthanc Server Official Site and the CERT Vulnerability Advisory #536588 for information on available patches and updates that address this vulnerability.

Workarounds

• Deploy a reverse proxy (such as nginx or Apache) in front of the vulnerable server with client_max_body_size or equivalent directives configured to enforce reasonable limits
• Implement network-level rate limiting and connection throttling to reduce the impact of exploitation attempts
• Configure firewall rules to restrict HTTP access to trusted IP ranges only
• Use container resource limits (memory cgroups) to prevent a single server process from exhausting all system memory
• Monitor and automatically restart the server process if it exceeds memory thresholds

# Example nginx reverse proxy configuration to limit request body size
# Place this in the server or location block

# Limit maximum request body size to 10MB
client_max_body_size 10m;

# Limit header buffer sizes
large_client_header_buffers 4 16k;
client_header_buffer_size 1k;