TinyWeb is a lightweight web server written in Delphi targeting Win32 platforms. Versions before 2.02 are vulnerable to a Denial of Service (DoS) attack classified under CWE-400 (Uncontrolled Resource Consumption). The vulnerability arises because TinyWeb spawns a new operating system thread for every incoming connection without enforcing a maximum concurrency limit or an appropriate request timeout. An attacker can exploit this by opening numerous connections and sending data extremely slowly (e.g., one byte every few minutes), a technique known as Slowloris. This behavior causes the server to consume excessive memory and thread resources, eventually exhausting its capacity and denying service to legitimate users. The vulnerability does not require authentication or user interaction, making it remotely exploitable over the network. The patch in version 2.02 introduces a maximum connection limit (CMaxConnections set to 512) and an idle connection timeout (CConnectionTimeoutSecs set to 30 seconds), effectively mitigating the attack vector. Until upgrading, deploying TinyWeb behind robust reverse proxies or Web Application Firewalls (WAFs) such as nginx, HAProxy, or Cloudflare is recommended. These intermediaries can buffer incomplete requests and enforce aggressive connection limits and timeouts, preventing resource exhaustion on the backend server.

The primary impact of this vulnerability is a Denial of Service condition, where the TinyWeb server becomes unresponsive due to resource exhaustion caused by numerous slow connections. This can disrupt web services, leading to downtime, loss of availability, and potential reputational damage for organizations relying on TinyWeb. Since the attack requires no authentication and can be launched remotely, it poses a significant risk to any exposed TinyWeb server. The exhaustion of OS threads and memory can also impact other services on the same host, potentially causing broader system instability. Organizations hosting critical applications or services on TinyWeb are particularly vulnerable, as prolonged outages could affect business continuity, customer trust, and compliance with service-level agreements. Although no known exploits are reported in the wild yet, the simplicity and effectiveness of the attack technique suggest a high likelihood of exploitation attempts once widely known.

1. Upgrade TinyWeb to version 2.02 or later immediately to apply the built-in fix introducing connection limits and timeouts. 2. If immediate upgrade is not feasible, deploy TinyWeb behind a robust reverse proxy or Web Application Firewall (WAF) such as nginx, HAProxy, or Cloudflare. Configure these intermediaries to buffer incomplete HTTP requests, enforce strict maximum connection limits, and apply aggressive idle connection timeouts (e.g., 30 seconds or less). 3. Monitor server metrics closely for unusual connection patterns or resource usage spikes indicative of Slowloris-style attacks. 4. Implement network-level rate limiting and anomaly detection to identify and block suspicious slow connection attempts. 5. Consider disabling or restricting access to TinyWeb services from untrusted networks or IP ranges to reduce exposure. 6. Regularly audit and update all web-facing infrastructure to ensure timely application of security patches and mitigations.