CVE-2026-27633: TinyWeb Memory Exhaustion DoS Vulnerability

CVE-2026-27633 Overview

CVE-2026-27633 is a Memory Exhaustion Denial of Service vulnerability affecting TinyWeb, a lightweight web server (HTTP, HTTPS) written in Delphi for Win32 platforms. Versions prior to 2.02 are vulnerable to unauthenticated remote denial of service attacks where attackers can send specially crafted HTTP POST requests with exceptionally large Content-Length header values (e.g., 2147483647). The server fails to enforce maximum payload size limits, causing it to continuously allocate memory for the request body (EntityBody) while streaming the payload, ultimately consuming all available system memory and crashing the server.

Critical Impact
Unauthenticated remote attackers can crash TinyWeb servers by sending a single malicious HTTP POST request, causing complete service disruption for all hosted services.

Affected Products

TinyWeb versions prior to 2.02
All Windows (Win32) deployments running vulnerable TinyWeb versions
Services and applications hosted behind vulnerable TinyWeb instances

Discovery Timeline

2026-02-26 - CVE-2026-27633 published to NVD
2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-27633

Vulnerability Analysis

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption). The root issue lies in TinyWeb's HTTP request handling mechanism, which lacks proper bounds checking on incoming request payloads. When the server receives an HTTP POST request, it reads the Content-Length header to determine the expected payload size but fails to validate this value against any reasonable maximum threshold before allocating memory buffers.

An attacker can exploit this by setting an artificially large Content-Length value (such as the maximum 32-bit signed integer value of 2147483647) and then slowly streaming payload data to the server. The server will continue allocating memory in an attempt to store the incoming data, even when the requested size far exceeds available system resources.

Root Cause

The vulnerability stems from missing input validation on the Content-Length HTTP header value. Prior to version 2.02, the TinyWeb server had no CMaxEntityBodySize constant to limit the maximum acceptable payload size. The server trusted the client-provided Content-Length header unconditionally and allocated memory accordingly, creating a classic resource exhaustion condition.

Attack Vector

The attack is network-based and requires no authentication. An attacker simply needs network connectivity to the vulnerable TinyWeb server and can execute the attack by:

Establishing a TCP connection to the target server
Sending an HTTP POST request with a maliciously large Content-Length header value
Slowly streaming arbitrary data to keep the connection alive while the server continues allocating memory
Repeating as needed until server memory is exhausted and the service crashes

text

   //   - NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-34199
   CMaxHeaderLineLength = 8192;   // CVE-2024-34199: Max 8KB per request line
   CMaxTotalHeaderSize = 65536;   // CVE-2024-34199: Max 64KB total headers
-
+  
+  // Unbounded Content-Length Memory Exhaustion DoS Prevention
+  CMaxEntityBodySize = 10485760; // Max 10MB per request payload
   // Buffer size for FindExecutable API result path.
   // Windows supports long paths beyond MAX_PATH (260), so we use 1000.
   CMaxExecutablePathLength = 1000;

Source: GitHub Commit Update

Detection Methods for CVE-2026-27633

Indicators of Compromise

HTTP POST requests with abnormally large Content-Length header values (greater than 10MB)
Rapid memory consumption spikes on servers running TinyWeb
Server process crashes or restarts correlated with incoming HTTP traffic
Slow-drip HTTP connections that remain open for extended periods while transmitting minimal data

Detection Strategies

Monitor web server logs for HTTP POST requests with Content-Length values exceeding reasonable thresholds
Implement network-level detection for HTTP requests containing Content-Length headers above 10MB (10485760 bytes)
Configure intrusion detection systems (IDS) to alert on memory exhaustion patterns targeting web server processes
Deploy application performance monitoring to detect abnormal memory allocation patterns

Monitoring Recommendations

Set up real-time alerting for TinyWeb process memory usage exceeding baseline thresholds
Monitor for connection patterns characteristic of slowloris-style attacks (long-lived connections with minimal data transfer)
Track server crash events and correlate with incoming HTTP traffic patterns
Implement logging for rejected requests that exceed configured body size limits after patching

How to Mitigate CVE-2026-27633

Immediate Actions Required

Upgrade TinyWeb to version 2.02 or later immediately
If immediate upgrade is not possible, deploy a Web Application Firewall (WAF) or reverse proxy in front of TinyWeb
Configure upstream proxies to enforce strict maximum request body size limits
Review and restrict network access to TinyWeb servers where possible

Patch Information

The fix is available in TinyWeb version 2.02. The patch introduces a new CMaxEntityBodySize constant set to 10485760 bytes (10MB) in SRC/SrvMain.pas, which enforces a hard limit on the maximum size of accepted request payloads. For complete details on the security fix, refer to the GitHub Security Advisory GHSA-992w and the patch commit.

Workarounds

Place TinyWeb behind nginx with client_max_body_size directive configured to a reasonable limit
Deploy Cloudflare or similar CDN/WAF services with request body size restrictions
Use Apache HTTP Server as a reverse proxy with LimitRequestBody directive
Implement network-level rate limiting to slow potential attack traffic

bash

# Configuration example for nginx reverse proxy
# Add to nginx server block to limit request body size
server {
    listen 80;
    server_name your-tinyweb-server.com;
    
    # Limit maximum request body size to 10MB
    client_max_body_size 10M;
    
    location / {
        proxy_pass http://127.0.0.1:8080;  # TinyWeb backend
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}