TinyWeb Thread/Connection Exhaustion (Slowloris)

Security Advisory. Published: February 25, 2026. Fixed in TinyWeb v2.02 (February 22, 2026).

Summary

TinyWeb HTTP Server version 2.01 and earlier are vulnerable to a Denial of Service (DoS) attack known as Slowloris. TinyWeb uses a one-thread-per-connection concurrency model, instantiating a new THTTPServerThread for every accepted socket without enforcing a maximum concurrency limit or appropriate idle timeouts. An unauthenticated remote attacker can exhaust the server's thread limit or memory by opening numerous connections and sending data exceptionally slowly, preventing legitimate clients from connecting.

Severity: High (CVSS 4.0 Base Score: 8.7)

Vulnerability Details

CVE ID CVE-2026-27630
Vulnerability Type Uncontrolled Resource Consumption (CWE-400), Slowloris
Attack Type Remote
Attack Vector Network (unauthenticated HTTP requests)
Vendor/Maintainer Maxim Masiutin
Product TinyWeb HTTP Server
Affected Versions Version 2.01 and below
Fixed Version 2.02 (February 22, 2026)
Impact Denial of Service (Thread/Resource Exhaustion)

CVSS Score

CVSS Version Score Severity Vector String
CVSS 4.0 8.7 High AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Technical Details

Mechanism

The vulnerability exists in the connection acceptance loop in SrvMain.pas. Every incoming connection triggers the creation of a dedicated operating system thread. Without limits, an attacker can hold connections open indefinitely while sending minimal data (e.g., 1 byte every few minutes), staying below inactive thresholds but keeping the thread and its stack space (default 1MB) locked.

Affected Code (SrvMain.pas - MainLoop)

repeat
  NewSocketHandle := Accept(ServerSocketHandle, Addr, j);
  if NewSocketHandle = INVALID_SOCKET then Break;
  
  // Create socket and thread wrapper without checking concurrent limits
  NewSocket := TSocket.Create;
  // ...
  NewThread := THTTPServerThread.Create;
  NewThread.Socket := NewSocket;
  NewThread.Resume;
until False;

Fix Applied in Version 2.02

The problem has been patched in version 2.02 by implementing explicit resource bounds:

  • CMaxConnections: Introduces a limit on the maximum number of concurrent threads/connections (default set to 512). (Commit 23268c8)
  • CConnectionTimeoutSecs: Enforces an idle timeout (default 30 seconds) to aggressively purge stalled or inactive connections.

Workarounds

If upgrading to v2.02 is not immediately possible, consider the following mitigations:

  • Place the server behind a robust reverse proxy or Web Application Firewall (WAF) such as nginx, HAProxy, or Cloudflare.
  • Ensure the proxy is configured to buffer incomplete requests and enforce strict connection limits and timeouts.

References