CVE-2025-67724

What it actually does

The vulnerability is an output-sanitization flaw in Tornado where an unsafe value supplied as the HTTP response reason phrase can allow carriage-return/line-feed header injection and reflected cross-site scripting. If an application passes attacker-controlled data into the response reason argument, the attacker may be able to manipulate HTTP response metadata, inject additional headers, or cause script-capable content to be reflected to a browser. The impact is application-dependent because exploitation requires a code path that exposes user-controllable input to Tornado's reason handling.

Why it matters to the business

Successful exploitation could let an attacker tamper with web responses, poison client-side behavior, mislead users, or run malicious JavaScript in a victim's browser in the context of the affected application. This can lead to session theft, credential phishing, unauthorized actions performed as a user, or reputational damage if users are redirected or shown attacker-controlled content. The CVSS score is moderate, EPSS is currently low, it is not in CISA KEV, and no mature public exploitation is indicated, but the issue has been public for 240 days, so internet-facing applications using affected Tornado code should still be remediated during normal patch cycles.

How an attack unfolds

An attacker first identifies a Tornado-based endpoint that reflects or incorporates user-controlled input into the HTTP response reason phrase, commonly through custom error handling, redirects, API error messages, or status-setting logic. The attacker then submits a crafted value containing encoded CRLF sequences to break out of the reason phrase and inject additional response headers, or submits HTML/JavaScript content that is rendered by a browser in a context where it can execute. If the application or an intermediary preserves the manipulated response, the attacker can influence browser behavior, set or overwrite headers, trigger script execution, or deliver a malicious link to a victim. Exploitation is most likely to be targeted and application-specific rather than broad unauthenticated scanning against every Tornado deployment.

How to fix it

Upgrade Tornado source deployments to a version that includes commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or later. If Tornado is consumed through a package manager, update to the first released package version that contains that commit once available from the upstream project or distribution maintainer. Review application code for any use of response status-setting APIs where the reason phrase is derived from request parameters, headers, path components, form fields, JSON bodies, database content, or other untrusted sources. Do not pass untrusted data into HTTP reason phrases; use static reason strings and place user-visible error detail in properly encoded response bodies. As defense in depth, validate or reject CR, LF, and other control characters in any value that may be used in HTTP headers or response metadata, and ensure HTML output is contextually encoded.

How to confirm the fix worked

Confirm the deployed Tornado code includes commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or a downstream release containing that fix. Use software composition analysis, dependency lockfiles, container image manifests, and runtime package inspection to verify that all deployed services use a fixed Tornado build. Review source code for calls that set custom HTTP status reasons and verify none use unsanitized user-controlled input. In a safe test environment, send benign encoded CRLF and HTML/script test strings to endpoints suspected of influencing status reason text and confirm the response does not contain injected headers, split responses, or executable reflected markup. Validate through automated tests that CR, LF, and HTML metacharacters are rejected, normalized, or safely encoded before reaching response metadata.

Typical attack path

1. Reconnaissance identifies a web application or API using Tornado and endpoints that return custom status messages or error reason text.
2. The attacker tests whether user-controlled input is reflected into the HTTP status reason phrase or related response output.
3. The attacker submits payloads containing CRLF sequences, encoded CRLF sequences, or script/HTML metacharacters.
4. If the response is not properly sanitized, the attacker injects additional HTTP headers or causes attacker-controlled script content to be reflected to the victim browser.
5. The attacker delivers the crafted URL or request flow to a victim, or abuses the vulnerable endpoint directly if the response affects API clients, proxies, or caches.
6. The attacker attempts follow-on impact such as session theft, phishing, unauthorized user actions, response manipulation, or cache/client-side poisoning.

How to detect it

To determine whether exploitation has already been attempted, review web server, reverse proxy, WAF, CDN, and application logs for requests containing carriage-return/line-feed payloads, encoded newline sequences, or script/HTML payloads in parameters, paths, headers, or request bodies that are later used in custom status or error messages. Focus on endpoints that return nonstandard HTTP status text, custom error pages, redirect responses, or API error responses. Look for response anomalies such as unexpected Set-Cookie, Location, Content-Type, Content-Length, Refresh, Access-Control-Allow-Origin, or X-* headers in error responses; malformed HTTP responses; unusual 3xx/4xx/5xx reason phrases; and browser reports of reflected script execution. If full response logging, proxy captures, or EDR network telemetry are available, search for HTTP responses where attacker-supplied strings appear in the status line or where one request appears to create extra response headers. Correlate suspicious requests with subsequent authentication anomalies, session reuse from unusual IP addresses, unexpected user-agent changes, or user reports of redirects/popups after following application links.

• %0d%0a
• %0D%0A
• %0a%0d
• %0A%0D
• \r\nSet-Cookie:
• %0D%0ASet-Cookie:
• %0d%0aSet-Cookie%3a
• %0D%0ALocation:
• %0d%0aLocation%3a
• %0D%0AContent-Type:
• %0d%0aContent-Type%3a
• %0D%0AContent-Length:
• %0d%0aContent-Length%3a
• %0D%0ARefresh:
• %0d%0aRefresh%3a
• %0D%0AAccess-Control-Allow-Origin:
• %0d%0aAccess-Control-Allow-Origin%3a
• <script
• %3Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• reason=%0d%0a
• reason=%0D%0A
• reason=<script
• reason=%3Cscript

What your security team should do

• Inventory applications, containers, and source repositories that use Tornado, especially Git-based or vendored copies rather than pinned package releases.
• Prioritize internet-facing Tornado applications and services with custom error handling, custom status messages, or API logic that returns user-derived reason text.
• Upgrade to Tornado code containing commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or the equivalent fixed downstream release.
• Search application code for status-setting calls using dynamic reason values and replace them with static strings or safely encoded response bodies.
• Add regression tests for CRLF injection and reflected XSS in error/status handling paths.
• Review web access logs and application logs for CRLF, encoded newline, and script-tag payloads targeting parameters that influence error messages or status responses.
• Tune WAF or reverse-proxy controls to detect and block CRLF sequences and obvious script payloads in inputs that should never contain them, while treating this as a compensating control rather than a fix.