TinyWeb is a lightweight HTTP/HTTPS server written in Delphi targeting Win32 platforms. Versions before 2.02 contain a critical resource exhaustion vulnerability (CWE-400) that leads to Denial of Service. The flaw arises because the server does not impose any upper bound on the size of the HTTP request body it accepts. An attacker can send a POST request with a very large Content-Length header (e.g., 2,147,483,647 bytes) causing the server to allocate memory continuously while streaming the request body. This unchecked memory allocation eventually consumes all available system memory, causing the server process to crash and resulting in service disruption. The vulnerability requires no authentication or user interaction, making it trivially exploitable remotely. The vendor fixed the issue in TinyWeb 2.02 by adding a configurable limit (CMaxEntityBodySize) set to 10MB on accepted payload sizes. No known exploits are reported in the wild yet. Temporary mitigations include deploying TinyWeb behind a Web Application Firewall or reverse proxy such as nginx or Cloudflare, configured to limit the maximum HTTP request body size (e.g., nginx’s client_max_body_size directive). This prevents oversized requests from reaching the vulnerable server. The CVSS 4.0 base score is 8.7 (high), reflecting the ease of exploitation, lack of authentication, and high impact on availability.

This vulnerability can cause complete denial of service on servers running vulnerable versions of TinyWeb by exhausting system memory and crashing the server process. Organizations relying on TinyWeb for web services risk service outages, potentially impacting business operations, customer access, and internal applications. The attack can be launched remotely and anonymously, increasing the risk of opportunistic or targeted disruption. In environments where TinyWeb hosts critical or customer-facing services, this could lead to reputational damage and financial losses. Additionally, repeated exploitation attempts could cause instability in hosting infrastructure. Since TinyWeb is a niche product, the overall global impact may be limited, but organizations using it without patching or mitigations remain vulnerable to straightforward DoS attacks.

1. Upgrade TinyWeb to version 2.02 or later immediately to apply the official patch that enforces a maximum request body size of 10MB. 2. If immediate upgrade is not feasible, deploy a Web Application Firewall (WAF) or reverse proxy (e.g., nginx, Cloudflare) in front of TinyWeb servers. Configure these intermediaries to explicitly limit the maximum allowed HTTP request body size (for example, set nginx’s client_max_body_size to 10MB or less). 3. Monitor web server logs for unusually large Content-Length headers or repeated POST requests that could indicate exploitation attempts. 4. Implement network-level rate limiting and anomaly detection to identify and block suspicious traffic patterns targeting TinyWeb servers. 5. Conduct regular vulnerability scanning and penetration testing to ensure no other resource exhaustion vectors exist. 6. Educate system administrators about this vulnerability and ensure patch management processes prioritize this update. 7. Consider isolating TinyWeb services in segmented network zones to limit potential impact of DoS attacks.