CVE-2026-6019

What it actually does

The flaw is a cross-site scripting condition in Python's standard-library cookie rendering helper, http.cookies.Morsel.js_output(). The function generates an inline <script> block and escapes double quotes for JavaScript string context, but it does not neutralize HTML parser control sequences such as </script>. If an attacker-controlled cookie value is passed to js_output() and embedded in an HTML response, the browser can terminate the intended script block early and interpret attacker-supplied markup or JavaScript as part of the page. This can allow execution of script in the origin of the affected web application. The reported mitigation is to encode the cookie value, such as with base64, so it cannot break out of the generated script element.

Why it matters to the business

Applications that use Python's http.cookies.Morsel.js_output() to emit cookies into HTML may expose users to browser-side compromise. Successful exploitation can lead to account impersonation within the affected application, theft of session-adjacent data accessible to JavaScript, unauthorized actions performed as the victim, content tampering, and reputational damage. The issue is not listed in CISA KEV, is not reported as ransomware-associated, and has low current EPSS, but it is easy to trigger where the vulnerable pattern exists and should be addressed during normal patching and secure-code remediation cycles.

How an attack unfolds

An attacker first identifies a Python-backed web application that uses http.cookies.Morsel.js_output() and reflects a cookie value into an inline script response. The attacker then finds a way to control the cookie value that will be passed into the Morsel object, such as through application functionality that stores user-controlled cookie content, a crafted request that sets or influences a cookie, or a privileged/admin workflow depending on the application's design. The attacker supplies a value containing an HTML script terminator such as </script> followed by attacker-controlled script markup. Because js_output() only escapes for part of the JavaScript string context and does not neutralize the HTML parser-sensitive closing script sequence, the browser closes the legitimate script element and parses the attacker's payload as executable page content. Once executed in the victim's browser under the application's origin, the payload can read accessible page data, issue authenticated requests, alter page content, or redirect the user.

How to fix it

Upgrade Python to a version that includes the vendor fix once available for the deployed runtime branch. No exact fixed version was provided in the input, so track the official Python security advisory and distribution package updates for the affected Python releases. As an immediate mitigation, stop using http.cookies.Morsel.js_output() for rendering untrusted or user-influenced cookie values into inline scripts. Prefer setting cookies with HTTP Set-Cookie headers rather than generating JavaScript snippets. If legacy behavior must remain, encode cookie values before insertion into script contexts, such as base64 or another safe encoding that prevents literal </script> from appearing in the generated script element, and decode only where appropriate. Also apply defense-in-depth controls: HTML/JavaScript context-aware output encoding, strict Content Security Policy that avoids unsafe inline scripts, HttpOnly and Secure cookie attributes where applicable, and input validation that rejects HTML/script delimiters in values that should never contain markup.

How to confirm the fix worked

Confirm exposure by reviewing application code and dependencies for direct or indirect calls to http.cookies.Morsel.js_output(). Test representative pages by setting a benign proof string such as </script><script>console.log('xss-test')</script> in any cookie value that may be rendered through js_output(), then verify in a safe test environment whether the string is encoded or executed. After remediation, the generated HTML should not contain a literal attacker-controlled </script> sequence inside an inline script block, and the browser should not execute injected test script. Validate that the deployed Python runtime or OS package level includes the vendor security fix when one is available. Also verify that CSP blocks unexpected inline script execution and that cookies not needed by JavaScript are marked HttpOnly.

Typical attack path

1. Identify a web endpoint that returns HTML containing output generated by Python http.cookies.Morsel.js_output().
2. Determine whether any cookie value passed to js_output() can be influenced by an attacker or by a privileged user-controlled workflow.
3. Submit a cookie value containing a closing script tag sequence, commonly </script>, followed by attacker-controlled JavaScript or HTML.
4. Cause the affected page to render the generated inline script in a browser.
5. The browser terminates the intended script block and executes the injected attacker script in the application's origin.
6. Use the executed script to perform unauthorized actions, access browser-visible sensitive data, manipulate content, or stage further phishing/session abuse.

How to detect it

To determine whether exploitation has already occurred, search HTTP access logs, reverse proxy logs, CDN/WAF logs, application request logs, and error logs for script-closing sequences in Cookie headers or other request fields that can influence cookie values. Pay special attention to requests containing literal or URL-encoded </script>, followed by <script>, event handlers, JavaScript URLs, or external script loaders. Review application logs for pages that generate cookies through Morsel.js_output() and correlate suspicious input with successful 200 responses serving HTML. Examine WAF alerts categorized as XSS, HTML injection, script tag injection, or cookie-based injection. If Content Security Policy reporting is enabled, search CSP violation reports for blocked inline script execution, blocked script-src events, or payload samples containing </script>. For confirmed suspicious hits, preserve the raw request, response body, headers, authenticated user context where available, and browser-side telemetry such as CSP reports; then assess whether the payload would have been rendered in an affected page and whether follow-on authenticated actions occurred from the same session shortly afterward.

• http.cookies.Morsel.js_output
• Morsel.js_output(
• js_output()
• </script>
• %3C/script%3E
• %3c%2fscript%3e
• \u003c/script\u003e
• &lt;/script&gt;
• </script><script
• %3C%2Fscript%3E%3Cscript%3E
• </script><img
• onerror=
• onload=
• javascript:
• document.cookie
• <script src=
• script-src
• violated-directive

What your security team should do

• Inventory Python web applications and shared libraries for use of http.cookies.Morsel.js_output().
• Prioritize remediation for internet-facing applications, administrative portals, identity-adjacent services, and applications handling sensitive user data.
• Replace js_output() usage with HTTP Set-Cookie header handling or a safe, context-aware rendering approach.
• Apply Python or operating-system package updates as soon as fixed versions are released for the affected runtime branch.
• Add code-scanning rules to flag Morsel.js_output(), inline <script> cookie generation, and unencoded cookie values rendered into HTML.
• Search web, WAF, CDN, and application logs for attempts to inject </script> or encoded equivalents into Cookie headers, query strings, form fields, and JSON bodies.
• Review CSP violation reports for blocked inline script execution containing script-closing payloads.
• Harden cookie attributes, especially HttpOnly for cookies that do not need client-side JavaScript access, Secure, SameSite, and appropriate path/domain scoping.