CVE-2026-41845

What it actually does

CVE-2026-41845 is a cross-site scripting vulnerability in Spring Framework caused by incorrect escaping in JavaScriptUtils.javaScriptEscape(). Applications that use this utility to place untrusted data into a JavaScript execution context may produce output that fails to neutralize attacker-controlled characters or sequences. If a vulnerable application reflects or stores that escaped value in a page viewed by a user, attacker-supplied JavaScript can execute in the browser under the affected application's origin. The CVSS vector indicates network exploitability, low attack complexity, no privileges required, and required user interaction, with potentially high confidentiality impact and limited integrity impact.

Why it matters to the business

Successful exploitation can let an attacker run code in a user's browser as if it came from the trusted application. This can lead to theft of session data or sensitive page content, unauthorized actions performed through the user's active session, phishing overlays, account manipulation, or data exposure from business workflows handled by the application. The vulnerability is not currently listed in CISA KEV, has no known exploit maturity in the provided data, and has a low, flat EPSS score, which suggests broad exploitation is not currently expected; however, Spring Framework is widely used in enterprise applications, so affected code paths should still be identified and remediated during normal patch cycles or sooner for internet-facing applications handling sensitive data.

How an attack unfolds

An attacker first identifies an application page or endpoint that accepts user-controllable input and later embeds that value into JavaScript using Spring Framework's JavaScriptUtils.javaScriptEscape(). Because the escaping is incomplete, the attacker crafts input that survives the escaping process and changes the intended JavaScript syntax, such as breaking out of a string or injecting executable browser code. The attacker then delivers the payload through a URL, form field, stored profile/content field, message, or other application workflow. When a victim opens the affected page, the browser executes the injected script in the security context of the legitimate application. The script can read accessible page data, perform same-origin requests, alter displayed content, capture tokens exposed to JavaScript, or perform actions using the victim's authenticated session. Exploitation requires the victim to interact with or visit the vulnerable page, but does not require the attacker to authenticate if the vulnerable input path is reachable anonymously.

How to fix it

Upgrade Spring Framework beyond the affected version ranges. Based on the affected ranges, target patched releases newer than 7.0.7, 6.2.18, 6.1.27, and 5.3.48 respectively, following the vendor's advisory and supported release lines. If immediate upgrade is not possible, avoid using JavaScriptUtils.javaScriptEscape() for untrusted data in executable JavaScript contexts; instead, redesign templates so untrusted data is emitted as data, not code, and use context-aware output encoding appropriate for the exact HTML, JavaScript, URL, or attribute context. Prefer safe JSON serialization for values consumed by JavaScript. Add or tighten a Content Security Policy that blocks inline script where feasible, use nonces or hashes for approved scripts, and avoid exposing session tokens or sensitive secrets to JavaScript-accessible storage. Review custom templates and view rendering code for places where user input is embedded inside script blocks, JavaScript string literals, event handler attributes, or dynamically constructed script.

How to confirm the fix worked

Confirm dependency versions using build manifests, software composition analysis, dependency lockfiles, container image scans, and runtime artifact inspection. Verify that no deployed application uses Spring Framework versions in the affected ranges: 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, or 5.3.0 through 5.3.48. Search source code and templates for JavaScriptUtils.javaScriptEscape() and inspect each usage to confirm untrusted input is not placed into executable JavaScript contexts. Add regression tests with representative XSS payloads for every rendering path that previously used this helper. Use dynamic application security testing against affected pages to verify payloads are rendered inert. In browsers, validate that injected characters remain data-only, cannot break out of JavaScript strings, and do not trigger script execution. Confirm CSP reporting shows no unexpected inline script execution after remediation.

Typical attack path

1. Find an application using affected Spring Framework versions: 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48.
2. Identify a page, API response, template, or stored content path where untrusted input is escaped with JavaScriptUtils.javaScriptEscape() and inserted into JavaScript.
3. Craft a payload that bypasses the flawed JavaScript escaping and results in executable script in the rendered page.
4. Deliver the payload through a reflected parameter, stored content field, link, form submission, or social engineering lure.
5. Wait for a victim to view the vulnerable page or click the crafted link.
6. Execute JavaScript in the victim's browser under the legitimate application's origin.
7. Use the script to read accessible data, issue same-origin requests, perform unauthorized actions, or redirect the victim to attacker-controlled infrastructure.

How to detect it

To determine whether exploitation already occurred, review web server, reverse proxy, WAF, CDN, and application logs for requests containing common JavaScript injection characters and payloads in query strings, form bodies, path parameters, headers, and referrers. Focus on endpoints that render user-supplied values into pages, especially pages known to call JavaScriptUtils.javaScriptEscape(). Review stored user-generated content for embedded script-breaking payloads that may execute when viewed by other users. Correlate suspicious payload submissions with subsequent victim page views, CSP violation reports, browser telemetry, and unusual same-origin API activity from victim sessions. Look for post-exploitation signs such as unexpected profile changes, new administrative actions, unusual exports or data reads, abnormal password or MFA changes, unauthorized transactions, suspicious redirects, or requests to unfamiliar external domains immediately after viewing vulnerable pages. If CSP reporting is enabled, search reports for blocked inline script, eval, event-handler execution, or connections to untrusted domains around the time suspicious input was submitted. Because XSS often leaves limited server-side artifacts, combine log analysis with application audit trails, identity provider logs, endpoint/browser telemetry, and forensic review of stored content.

• JavaScriptUtils.javaScriptEscape(
• </script
• %3C/script
• <script
• %3Cscript
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• alert(
• confirm(
• prompt(
• document.cookie
• document.domain
• localStorage
• sessionStorage
• eval(
• Function(
• setTimeout(
• setInterval(
• fetch(
• XMLHttpRequest
• new Image().src
• String.fromCharCode
• fromCharCode(
• atob(
• btoa(
• \x3cscript
• \u003cscript
• ';alert(
• \";alert(
• </SCRIPT
• %253Cscript
• CSP violation
• violated-directive
• script-src
• blocked-uri

What your security team should do

• Inventory applications and services using Spring Framework and identify deployments running affected versions.
• Prioritize internet-facing applications, authenticated portals, administrative consoles, and applications handling sensitive personal, financial, or operational data.
• Upgrade affected Spring Framework release lines to vendor-patched versions newer than the affected ranges as soon as practical.
• Search code repositories for JavaScriptUtils.javaScriptEscape() and review each usage for unsafe JavaScript-context output.
• Add application-level tests for reflected and stored XSS around affected views, parameters, and content fields.
• Enable or strengthen Content Security Policy with script-src restrictions, nonces or hashes, and CSP report collection where feasible.
• Review WAF, reverse proxy, application, and CSP violation logs for suspicious XSS payloads submitted before patching.
• Educate development teams to use context-aware encoding and safe JSON serialization rather than manually escaping strings for JavaScript execution contexts.