TinyWeb is a lightweight HTTP/HTTPS server written in Delphi for Win32 platforms. Versions before 2.02 contain a critical vulnerability (CVE-2026-27633) classified under CWE-400 (Uncontrolled Resource Consumption). The issue stems from the server's failure to enforce any maximum limit on the size of the HTTP request body during POST requests. An attacker can send a POST request with an extremely large Content-Length header value (for example, 2,147,483,647 bytes), causing the server to allocate memory continuously as it attempts to read the request body. Since the server streams the payload without checks, this leads to memory exhaustion, resulting in a crash and denial of service. The vulnerability requires no authentication or user interaction and can be triggered remotely over the network. The patch in version 2.02 introduces a configurable limit (CMaxEntityBodySize) set to 10MB, preventing excessive memory allocation. As an interim mitigation, deploying a Web Application Firewall or reverse proxy such as nginx or Cloudflare configured to limit the maximum allowed HTTP request body size (e.g., nginx’s client_max_body_size directive) can effectively block malicious requests. Although no exploits have been reported in the wild, the vulnerability’s characteristics make it a serious threat to availability for any service relying on vulnerable TinyWeb versions.

The primary impact of CVE-2026-27633 is a Denial of Service condition caused by memory exhaustion on servers running vulnerable versions of TinyWeb. This can lead to service outages, disrupting availability for legitimate users and potentially causing cascading failures in dependent systems. Organizations hosting critical web services on TinyWeb are at risk of downtime, which can affect business operations, customer trust, and revenue. Since exploitation requires no authentication and can be performed remotely, attackers can easily target exposed servers. The vulnerability could be leveraged in large-scale DoS campaigns or combined with other attacks to amplify impact. Additionally, repeated crashes may lead to system instability or require manual intervention to restore service. The lack of known exploits in the wild currently limits immediate widespread impact, but the vulnerability’s simplicity and severity make it a high-priority patch for affected organizations.

1. Upgrade TinyWeb to version 2.02 or later immediately, as this version includes a fix that enforces a maximum request body size (10MB by default). 2. If upgrading is not feasible in the short term, deploy a Web Application Firewall (WAF) or reverse proxy (e.g., nginx, Cloudflare) in front of the TinyWeb server. Configure it to explicitly limit the maximum allowed HTTP request body size (for example, set nginx’s client_max_body_size directive to a safe threshold such as 10MB or less). 3. Monitor 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 the web server. 5. Regularly audit and inventory all instances of TinyWeb in the environment to ensure none remain vulnerable. 6. Establish incident response procedures to quickly recover from potential DoS attacks, including automated service restarts and resource monitoring. 7. Educate system administrators about this vulnerability and the importance of patch management for third-party web servers.