Tornadoweb
Monthly
Unauthenticated local file disclosure in Tornado before 6.5.9 lets remote attackers read files outside a configured static root by requesting a symbolic link that lives inside that root but resolves elsewhere, exposing configuration files, private keys, and application secrets readable by the Tornado process user. Exploitation is a single GET request requiring no authentication and no user interaction (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), but it depends on a precondition rather than being turnkey: an out-of-root symlink must already exist inside the static directory, a situation the upstream advisory says arises in applications serving user-uploadable content or where build/deploy pipelines (npm link, webpack, Docker volume mounts, CDN sync tools) create symlinks. The issue is fixed in 6.5.9, public reproduction steps are published in the upstream GitHub Security Advisory, and there is no CISA KEV listing.
Denial of service in the Tornado web framework's CurlAsyncHTTPClient (all releases before 6.5.9) lets an unauthenticated remote server OOM-kill the application process by answering a fetch with a gzip decompression bomb: libcurl decompresses the body before invoking the client's write callback, and Tornado appends the decoded bytes to an unbounded BytesIO with no post-decompression size check, so a few megabytes on the wire expand to gigabytes of resident memory. Exposure is genuinely conditional - the application must be explicitly configured to use CurlAsyncHTTPClient (via AsyncHTTPClient.configure), must leave decompress_response at its default True, and must fetch a URL the attacker controls or has compromised; the default SimpleAsyncHTTPClient is not affected because the size gates added for CVE-2026-49855 live in code the curl client never executes. The upstream GHSA advisory documents a verified end-to-end reproduction on master (6.6.dev1) and v6.5.8 where a ~2.8 MB gzip payload grew client RSS from roughly 31 MB to about 1,032 MB in 3.18 seconds (exit 137, cgroup OOMKilled=true); the only incidental ceiling before the patch was the default 20-second request_timeout. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing applies.
Credential leakage in Tornado's CurlAsyncHTTPClient (all releases through 6.5.6) lets sensitive per-request state — client TLS certificates (SSLCERT/SSLKEY) and proxy basic-auth credentials (PROXYUSERPWD) — persist on pooled pycurl handles and be presented to a different, unintended host on a later request. The flaw affects applications that pass per-request credentials to the curl-backed client and reuse the same client instance across hosts; it is not reachable by an anonymous internet attacker against a default server deployment, and the vendor rates attack complexity as high with attack requirements present. No public exploit code has been identified at time of analysis and no active exploitation is reported; the vendor has fixed the issue in Tornado 6.5.7.
Memory amplification denial of service in the Tornado Python web framework before 6.5.8 lets unauthenticated remote attackers exhaust server memory with a single crafted multipart/form-data request containing tens of thousands of parts — roughly 600KB of body is enough to build a 100,000-element transient list. Tornado's parse_multipart_form_data splits the body on the boundary before it enforces the max_parts limit, so the safety check fires only after the expensive allocation has already happened. Publicly available exploit code exists (a gist with poc.py), patch status is 'available from vendor' with the fix shipped in 6.5.8, and no CISA KEV listing or EPSS score accompanied the supplied intelligence.
Denial-of-service in Tornado prior to 6.5.8 allows unauthenticated remote attackers to stall the entire server by sending a single POST request with millions of separator-delimited fields in an application/x-www-form-urlencoded body. Because Tornado's RequestHandler parses the body synchronously before handler dispatch using urllib.parse.parse_qs without a max_num_fields limit, a request body up to the 100 MB default max_buffer_size can consume all CPU on the single-threaded event loop and delay every concurrent connection. No public exploit or CISA KEV listing has been identified at time of analysis, but the low attack complexity (AV:N/AC:L/PR:N/UI:N) makes this trivially automatable against any exposed Tornado endpoint.
In versions of Tornado prior to 6.5.5, the only limit on the number of parts in `multipart/form-data` is the `max_body_size` setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts. Tornado 6.5.5 introduces new limits on the size and complexity of multipart bodies, including a default limit of 100 parts per request. These limits are configurable if needed; see `tornado.httputil.ParseMultipartConfig`. It is also now possible to disable `multipart/form-data` parsing entirely if it is not required for the application.
Event-loop starvation in the Tornado Python web framework and async networking library before 6.6.0 allows a remote, unauthenticated attacker to stall every connection handled by a worker process by submitting an HTTP/1.1 chunked request body made of millions of one-byte chunks to any handler that reads the body. Because the decoder processes already-arrived body bytes without yielding to the event loop, a body near the default 100 MB max_body_size can block the process for close to a minute, and for handlers without @stream_request_body each retained chunk costs roughly twenty times the received bytes in memory. The same behaviour affects SimpleAsyncHTTPClient when it reads a response from a malicious server; no public exploit identified at time of analysis, and the issue is addressed in the 6.6.0 release rather than treated as an emergency by available triage signals.
Unbounded query-string parsing in Tornado before 6.5.9 lets unauthenticated remote attackers stall the event loop of affected servers by sending GET requests whose query strings carry thousands of short parameters. Because HTTPServerRequest.__init__ parses the query string synchronously inside Tornado's single-threaded IOLoop with no field-count cap, a burst of such requests degrades response times for every client sharing that loop rather than triggering a clean crash - impact is availability degradation rated Low (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:L; vendor CVSS 4.0 base 6.9 with VA:L), and sustained concurrent high-field requests are needed to meaningfully starve other connections. A vendor-released patch exists in Tornado 6.5.9 (upstream PR 3719 / commit 03945136ea9746eccf61caf88edae39642e59c93), and no public exploit code has been identified at time of analysis.
Tornado 6.5.5 through 6.5.7 allows attackers to inject arbitrary Set-Cookie attributes because the fix for CVE-2026-35536 only validated the documented lowercase keyword arguments (name/domain/path/samesite). The deprecated and still-live **kwargs path in RequestHandler.set_cookie writes values straight into the Morsel without character validation, and because Morsel.__setitem__ is case-insensitive, a capitalized kwarg such as Domain=, Path=, SameSite= or Max-Age= routes to the same reserved attribute while bypassing the filter. Any application that passes attacker-influenced data into a capitalized/legacy kwarg can be made to emit cookies with attacker-controlled Domain, Path, Secure, HttpOnly or SameSite directives; no public exploit code or CISA KEV entry has been identified at time of analysis.
Cookie attribute injection in Tornado web framework versions before 6.5.5 allows unauthenticated remote attackers to manipulate cookie security attributes through crafted characters in domain, path, and samesite parameters of RequestHandler.set_cookie. With CVSS 7.2 and EPSS data unavailable, this represents a moderate integrity and confidentiality risk for web applications using affected Tornado versions. No public exploit identified at time of analysis, though the vulnerability mechanism is straightforward for exploitation.
Tornado is a Python web framework and asynchronous networking library. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
Tornado is a Python web framework and asynchronous networking library. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Open redirect vulnerability in Tornado versions 6.3.1 and earlier allows a remote unauthenticated attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having user. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
CRLF injection vulnerability in the tornado.web.RequestHandler.set_header function in Tornado before 2.2.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity.
py3-tornado (the Python Tornado web framework packaged for Alpine Linux) contains a vulnerability addressed in Alpine package version 6.5.4-r0. The nature of the flaw - including its impact class, affected component, and exploitability - is not disclosed in available intelligence. The only confirmed remediation signal is the Alpine Linux vendor advisory fixing the package at version 6.5.4-r0. EPSS exploitation probability is very low at 0.03% (11th percentile), and no active exploitation or public proof-of-concept has been identified at time of analysis.
Tornado Python web framework on Alpine Linux received a security fix in package version 6.5.4-r0, addressing an uncharacterized vulnerability. The nature of the flaw, affected attack surface, and exploitability conditions are not disclosed in available intelligence - only the patched Alpine package version is confirmed. EPSS scoring places exploitation probability at 0.21% (44th percentile), suggesting low-to-moderate automated exploitation likelihood at time of analysis, with no public exploit identified at time of analysis.
py3-tornado in Alpine Linux received a security fix packaged as version 6.5.4-r0, addressing an unspecified vulnerability in the Tornado asynchronous Python web framework. The nature, severity, and impact of the underlying flaw are not disclosed in available intelligence - no CVE description, CVSS vector, or CWE classification has been published. With an EPSS score of 0.04% (11th percentile) and no public exploit identified at time of analysis, the current exploitation signal is very low, though the absence of severity data prevents meaningful risk contextualization.
Unauthenticated local file disclosure in Tornado before 6.5.9 lets remote attackers read files outside a configured static root by requesting a symbolic link that lives inside that root but resolves elsewhere, exposing configuration files, private keys, and application secrets readable by the Tornado process user. Exploitation is a single GET request requiring no authentication and no user interaction (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), but it depends on a precondition rather than being turnkey: an out-of-root symlink must already exist inside the static directory, a situation the upstream advisory says arises in applications serving user-uploadable content or where build/deploy pipelines (npm link, webpack, Docker volume mounts, CDN sync tools) create symlinks. The issue is fixed in 6.5.9, public reproduction steps are published in the upstream GitHub Security Advisory, and there is no CISA KEV listing.
Denial of service in the Tornado web framework's CurlAsyncHTTPClient (all releases before 6.5.9) lets an unauthenticated remote server OOM-kill the application process by answering a fetch with a gzip decompression bomb: libcurl decompresses the body before invoking the client's write callback, and Tornado appends the decoded bytes to an unbounded BytesIO with no post-decompression size check, so a few megabytes on the wire expand to gigabytes of resident memory. Exposure is genuinely conditional - the application must be explicitly configured to use CurlAsyncHTTPClient (via AsyncHTTPClient.configure), must leave decompress_response at its default True, and must fetch a URL the attacker controls or has compromised; the default SimpleAsyncHTTPClient is not affected because the size gates added for CVE-2026-49855 live in code the curl client never executes. The upstream GHSA advisory documents a verified end-to-end reproduction on master (6.6.dev1) and v6.5.8 where a ~2.8 MB gzip payload grew client RSS from roughly 31 MB to about 1,032 MB in 3.18 seconds (exit 137, cgroup OOMKilled=true); the only incidental ceiling before the patch was the default 20-second request_timeout. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing applies.
Credential leakage in Tornado's CurlAsyncHTTPClient (all releases through 6.5.6) lets sensitive per-request state — client TLS certificates (SSLCERT/SSLKEY) and proxy basic-auth credentials (PROXYUSERPWD) — persist on pooled pycurl handles and be presented to a different, unintended host on a later request. The flaw affects applications that pass per-request credentials to the curl-backed client and reuse the same client instance across hosts; it is not reachable by an anonymous internet attacker against a default server deployment, and the vendor rates attack complexity as high with attack requirements present. No public exploit code has been identified at time of analysis and no active exploitation is reported; the vendor has fixed the issue in Tornado 6.5.7.
Memory amplification denial of service in the Tornado Python web framework before 6.5.8 lets unauthenticated remote attackers exhaust server memory with a single crafted multipart/form-data request containing tens of thousands of parts — roughly 600KB of body is enough to build a 100,000-element transient list. Tornado's parse_multipart_form_data splits the body on the boundary before it enforces the max_parts limit, so the safety check fires only after the expensive allocation has already happened. Publicly available exploit code exists (a gist with poc.py), patch status is 'available from vendor' with the fix shipped in 6.5.8, and no CISA KEV listing or EPSS score accompanied the supplied intelligence.
Denial-of-service in Tornado prior to 6.5.8 allows unauthenticated remote attackers to stall the entire server by sending a single POST request with millions of separator-delimited fields in an application/x-www-form-urlencoded body. Because Tornado's RequestHandler parses the body synchronously before handler dispatch using urllib.parse.parse_qs without a max_num_fields limit, a request body up to the 100 MB default max_buffer_size can consume all CPU on the single-threaded event loop and delay every concurrent connection. No public exploit or CISA KEV listing has been identified at time of analysis, but the low attack complexity (AV:N/AC:L/PR:N/UI:N) makes this trivially automatable against any exposed Tornado endpoint.
In versions of Tornado prior to 6.5.5, the only limit on the number of parts in `multipart/form-data` is the `max_body_size` setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts. Tornado 6.5.5 introduces new limits on the size and complexity of multipart bodies, including a default limit of 100 parts per request. These limits are configurable if needed; see `tornado.httputil.ParseMultipartConfig`. It is also now possible to disable `multipart/form-data` parsing entirely if it is not required for the application.
Event-loop starvation in the Tornado Python web framework and async networking library before 6.6.0 allows a remote, unauthenticated attacker to stall every connection handled by a worker process by submitting an HTTP/1.1 chunked request body made of millions of one-byte chunks to any handler that reads the body. Because the decoder processes already-arrived body bytes without yielding to the event loop, a body near the default 100 MB max_body_size can block the process for close to a minute, and for handlers without @stream_request_body each retained chunk costs roughly twenty times the received bytes in memory. The same behaviour affects SimpleAsyncHTTPClient when it reads a response from a malicious server; no public exploit identified at time of analysis, and the issue is addressed in the 6.6.0 release rather than treated as an emergency by available triage signals.
Unbounded query-string parsing in Tornado before 6.5.9 lets unauthenticated remote attackers stall the event loop of affected servers by sending GET requests whose query strings carry thousands of short parameters. Because HTTPServerRequest.__init__ parses the query string synchronously inside Tornado's single-threaded IOLoop with no field-count cap, a burst of such requests degrades response times for every client sharing that loop rather than triggering a clean crash - impact is availability degradation rated Low (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:L; vendor CVSS 4.0 base 6.9 with VA:L), and sustained concurrent high-field requests are needed to meaningfully starve other connections. A vendor-released patch exists in Tornado 6.5.9 (upstream PR 3719 / commit 03945136ea9746eccf61caf88edae39642e59c93), and no public exploit code has been identified at time of analysis.
Tornado 6.5.5 through 6.5.7 allows attackers to inject arbitrary Set-Cookie attributes because the fix for CVE-2026-35536 only validated the documented lowercase keyword arguments (name/domain/path/samesite). The deprecated and still-live **kwargs path in RequestHandler.set_cookie writes values straight into the Morsel without character validation, and because Morsel.__setitem__ is case-insensitive, a capitalized kwarg such as Domain=, Path=, SameSite= or Max-Age= routes to the same reserved attribute while bypassing the filter. Any application that passes attacker-influenced data into a capitalized/legacy kwarg can be made to emit cookies with attacker-controlled Domain, Path, Secure, HttpOnly or SameSite directives; no public exploit code or CISA KEV entry has been identified at time of analysis.
Cookie attribute injection in Tornado web framework versions before 6.5.5 allows unauthenticated remote attackers to manipulate cookie security attributes through crafted characters in domain, path, and samesite parameters of RequestHandler.set_cookie. With CVSS 7.2 and EPSS data unavailable, this represents a moderate integrity and confidentiality risk for web applications using affected Tornado versions. No public exploit identified at time of analysis, though the vulnerability mechanism is straightforward for exploitation.
Tornado is a Python web framework and asynchronous networking library. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
Tornado is a Python web framework and asynchronous networking library. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Open redirect vulnerability in Tornado versions 6.3.1 and earlier allows a remote unauthenticated attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having user. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
CRLF injection vulnerability in the tornado.web.RequestHandler.set_header function in Tornado before 2.2.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity.
py3-tornado (the Python Tornado web framework packaged for Alpine Linux) contains a vulnerability addressed in Alpine package version 6.5.4-r0. The nature of the flaw - including its impact class, affected component, and exploitability - is not disclosed in available intelligence. The only confirmed remediation signal is the Alpine Linux vendor advisory fixing the package at version 6.5.4-r0. EPSS exploitation probability is very low at 0.03% (11th percentile), and no active exploitation or public proof-of-concept has been identified at time of analysis.
Tornado Python web framework on Alpine Linux received a security fix in package version 6.5.4-r0, addressing an uncharacterized vulnerability. The nature of the flaw, affected attack surface, and exploitability conditions are not disclosed in available intelligence - only the patched Alpine package version is confirmed. EPSS scoring places exploitation probability at 0.21% (44th percentile), suggesting low-to-moderate automated exploitation likelihood at time of analysis, with no public exploit identified at time of analysis.
py3-tornado in Alpine Linux received a security fix packaged as version 6.5.4-r0, addressing an unspecified vulnerability in the Tornado asynchronous Python web framework. The nature, severity, and impact of the underlying flaw are not disclosed in available intelligence - no CVE description, CVSS vector, or CWE classification has been published. With an EPSS score of 0.04% (11th percentile) and no public exploit identified at time of analysis, the current exploitation signal is very low, though the absence of severity data prevents meaningful risk contextualization.