Executive Summary

CVE-2026-27633 is a high-severity Denial of Service (DoS) vulnerability in TinyWeb HTTP Server versions prior to 2.02. The issue arises because the server does not enforce any maximum limit on the size of the HTTP request body when processing POST requests with a Content-Length header. An unauthenticated remote attacker can send a POST request with an excessively large Content-Length value (for example, 2,147,483,647), causing the server to continuously allocate memory for the request body without limit. This unbounded memory allocation leads to resource exhaustion and ultimately crashes the server.

The vulnerable code resizes the internal buffer for the request body without validating the total size, enabling memory exhaustion. The vulnerability is classified as Uncontrolled Resource Consumption (CWE-400).

The issue was fixed in TinyWeb version 2.02 by introducing a maximum payload size limit (CMaxEntityBodySize) set to 10MB. Requests exceeding this limit are rejected immediately with an HTTP 413 Payload Too Large response.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause a complete Denial of Service (DoS) on any server hosting TinyWeb versions prior to 2.02. An attacker can remotely and unauthenticatedly crash the server by sending a specially crafted HTTP POST request with an excessively large Content-Length header.

The impact is high because the server consumes all available memory while processing the request, leading to a crash and service unavailability.

If you rely on TinyWeb for hosting services, this vulnerability can cause downtime and disrupt availability of your web services.

Mitigations include upgrading to TinyWeb version 2.02 or later, or placing the server behind a Web Application Firewall (WAF) or reverse proxy (such as nginx or Cloudflare) configured to limit the maximum allowed HTTP request body size.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring HTTP POST requests sent to the TinyWeb server that contain an unusually large Content-Length header value, such as 2147483647 or other excessively large numbers.'}, {'type': 'paragraph', 'content': 'You can detect potential exploitation attempts by capturing and analyzing network traffic for HTTP POST requests with abnormally large Content-Length headers.'}, {'type': 'list_item', 'content': 'Use tcpdump or Wireshark to capture HTTP traffic and filter for large Content-Length headers.'}, {'type': 'list_item', 'content': 'Example tcpdump command to capture HTTP POST requests with large Content-Length headers:'}, {'type': 'list_item', 'content': "tcpdump -i <interface> -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i 'Content-Length: '"}, {'type': 'list_item', 'content': 'Alternatively, use tools like curl or custom scripts to send test POST requests with large Content-Length headers to see if the server crashes or behaves abnormally.'}] [1, 3]

Useful 0 Not Useful 0

Mitigation Strategies

The primary and recommended mitigation is to upgrade TinyWeb to version 2.02 or later, which includes a fix that enforces a maximum allowed HTTP request body size of 10MB.

If upgrading immediately is not possible, place the TinyWeb server behind a Web Application Firewall (WAF) or a reverse proxy such as nginx or Cloudflare.

Configure the WAF or reverse proxy to explicitly limit the maximum allowed HTTP request body size to prevent memory exhaustion attacks.

• For nginx, set the directive: client_max_body_size 10M;
• This configuration will reject requests with bodies larger than 10MB, mitigating the risk of the DoS vulnerability.

Useful 0 Not Useful 0