CVE-2026-103261

Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest.init, allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.

Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest.init, allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.

Summary

HTTPServerRequest.__init__ in tornado/httputil.py parses the URL query string via parse_qs_bytes() with no field-count limit — while the sibling POST-body parsing path (parse_body_arguments) received a max_num_fields=1000 cap added earlier in this exact same release (v6.5.8, commit 8d6363ed), explicitly to bound parsing cost for the identical underlying primitive. This leaves the query-string path with the resource-exhaustion exposure the body-path fix was meant to close.

File: tornado/httputil.py, line 553 (HTTPServerRequest.__init__)

Root Cause

# tornado/httputil.py:553 (before fix)
self.arguments = parse_qs_bytes(self.query, keep_blank_values=True)

Compare with the POST-body path fixed one commit earlier in the same release:

# tornado/httputil.py:1038-1041
uri_arguments = parse_qs_bytes(
    body,
    keep_blank_values=True,
    max_num_fields=config.urlencoded.max_arguments,  # default 1000
)

Both call sites funnel through the same tornado.escape.parse_qs_bytes (a thin wrapper over urllib.parse.parse_qs), which is exactly why max_num_fields was added to urllib.parse.parse_qsl upstream — to let frameworks bound field count. The fix was applied only to the body path; the query-string path was missed.

The request line + headers together are capped at max_header_size (default 65536 bytes), so this is not literally unbounded, but a single ~64KB request line can carry thousands of short key=value pairs — far beyond the 1000-field limit the maintainer judged appropriate for the structurally identical body case.

Attack Scenario

1. Attacker sends a GET request whose query string is packed with thousands of short fields (e.g. k0=1&k1=1&...&k7799=1, ~61KB), fitting comfortably under max_header_size. No authentication, cookies, or prior state required.
2. Tornado accepts and parses this with no field-count cap, unlike the equivalent POST-body request (which is correctly rejected with 400 once >1000 fields are present).
3. Parsing thousands of fields is CPU work performed synchronously inside Tornado's single-threaded IOLoop. Several such requests in flight concurrently stall the event loop, delaying processing of all other connections on that loop — not just the attacker's own request.

Verification (dynamic, local reproduction against v6.5.8)

Ran the unmodified v6.5.8 source directly (no external dependencies needed) with a minimal tornado.web.Application on 127.0.0.1:8888.

• Identical 7800-field/~61KB payload sent as GET query string → 200 OK; sent as POST body (application/x-www-form-urlencoded) → 400 Bad Request (correctly rejected by the existing max_num_fields body-path limit). This confirms the asymmetry directly.
• Per-request parse cost: baseline (/?a=1) averaged 1.86ms; the 7800-field query string averaged 25.1ms (~13x).
• Event-loop-blocking amplification (raw-socket test, isolating server-side stall from client overhead): with 10 sequential baseline probe requests fired with no load, average latency was 1.47ms (max 5.9ms). With 5 concurrent 61KB/7800-field requests in flight, the same baseline probes averaged 13.0ms (max 118.1ms) — an 8.9x average slowdown for unrelated clients, produced by ~305KB of unauthenticated attacker traffic.

Impact

All Tornado servers/applications are affected — this triggers on every request with a query string, independent of application/handler logic. An unauthenticated, unprivileged remote attacker can measurably degrade response times for all other clients sharing the same IOLoop, using a small amount of bandwidth and no special conditions. This is an availability/DoS concern; no confidentiality or integrity impact.

Recommended Fix

# tornado/httputil.py — HTTPServerRequest.__init__
if uri is not None:
    self.path, sep, self.query = uri.partition("?")
try:
    self.arguments = parse_qs_bytes(
    …

Summary

StaticFileHandler allows an unauthenticated attacker to read arbitrary files from the server's filesystem by requesting a path that resolves to a symbolic link placed inside the static root directory. Any application that serves user-uploadable content, or whose static directory is populated by a build/deploy pipeline that creates symlinks (e.g. npm link, webpack, Docker volume mounts, CDN sync tools), is affected. An attacker who can trigger the creation of a symlink pointing outside the static root—or exploit one that already exists—can retrieve sensitive files such as /etc/passwd, private keys, configuration files, or application secrets.

Details

The vulnerability is in tornado.web.StaticFileHandler, specifically in the interaction between two methods in tornado/web.py:

• get_absolute_path uses os.path.abspath() to resolve the requested path:
• validate_absolute_path uses the same os.path.abspath() on the root, then performs a string prefix check:

os.path.abspath() normalises . and .. segments but does not resolve symbolic links. As a result, a path like /var/www/static/link passes the startswith("/var/www/static/") check regardless of where link actually points.

Immediately after, os.path.exists() and os.path.isfile() do follow symlinks, so the file they ultimately open is the symlink's target. The fix would be to replace os.path.abspath() with os.path.realpath() in both methods, so the resolved real path of the symlink target is validated against the root, not just its string representation inside the static directory.

PoC

Complete instructions, including specific configuration details, to reproduce the vulnerability. Prerequisites: Python 3.x, Tornado installed.

1. Create the environment

mkdir -p /tmp/static
echo "DB_PASSWORD=s3cr3t" > /tmp/secret.conf   
ln -s /tmp/secret.conf /tmp/static/config.conf 

2. Minimal vulnerable server (server.py):

import tornado.web, tornado.ioloop

app = tornado.web.Application([
    (r"/static/(.*)", tornado.web.StaticFileHandler, {"path": "/tmp/static"}),
])
app.listen(8888)
tornado.ioloop.IOLoop.current().start()

3. Exploit: curl http://localhost:8888/static/config.conf

Impact

Any application using StaticFileHandler is potentially affected if:

• the static directory contains symlinks pointing outside it (common with build tooling), or
• the application allows file uploads into the static directory without stripping symlinks.

An unauthenticated remote attacker can read any file readable by the process user: application secrets, private TLS keys, database credentials, /etc/shadow, SSH keys, or source code (depending on the process's filesystem permissions).

Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest.init, allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.

Tornado before 6.5.9 fails to limit the number of query string fields in HTTPServerRequest.init, allowing remote attackers to cause event-loop stalling by sending requests with thousands of query parameters. Attackers can send unauthenticated GET requests with unbounded query-string field counts to degrade response times for all clients sharing the same IOLoop.

TuxCare rebuilt tornado to address 2 CVEs. Fixed in 6.1.0.post9+tuxcare.

TuxCare rebuilt tornado to address 2 CVEs. Fixed in 5.1.1.post5+tuxcare.

Root has patched GHSA-c2m8-h5v5-343r in the tornado package for Root:PyPI. Multiple fixed versions available.