CVE-2026-41845
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Spring Framework is the foundational application framework for the Java platform, providing the core inversion-of-control container plus the web, data access, messaging, and integration modules that most Spring applications build on. Its spring-web module ships org.springframework.web.util.JavaScriptUtils, a small utility whose javaScriptEscape method is meant to make a server-side string safe to inline into a JavaScript context, for example the value rendered by the JSP form tag library when javaScriptEscape="true" is set, or any application code that injects server data into an inline script block.
A high-severity vulnerability (CVE-2026-41845) has been identified in JavaScriptUtils.javaScriptEscape. The method escapes the characters that are special inside single- or double-quoted JavaScript string literals (including the quote characters, the backslash, the forward slash, control characters, and the angle-bracket characters that were added to harden against an earlier XSS issue), but it does not escape the backtick or the dollar sign. Both characters are special inside an ECMAScript template literal: the backtick delimits the literal and the dollar-brace syntax interpolates an arbitrary JavaScript expression. When the escaped value is embedded inside a template literal rather than a quoted string, attacker-controlled input containing a backtick or an interpolation sequence can break out of the intended string context and execute arbitrary JavaScript in the victim's browser.
Per OWASP, Cross-Site Scripting (XSS) attacks are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites; they occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user, and the end user's browser executes the script because it has no way to know the script should not be trusted. Because the script runs in the victim's session, it can read cookies and other session data, perform actions as the victim, and rewrite page content.
The CVSS v3.1 base score for this vulnerability is 8.1 (High) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N. The attack vector is Network, complexity is Low, no privileges are required, and user interaction is required because the victim must render the page that embeds the unsafely escaped value. Confidentiality impact is High and Integrity impact is Low, consistent with cross-site scripting where session and data exposure is the primary impact.
This issue affects >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7 of Spring Framework. The method long predates these lines, so older releases that are past their open-source end-of-life, including the 4.3.x line, are affected as well.
Details
Module Info
- Product: Spring Framework
- Affected packages: spring-web
- Affected versions: >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7
- GitHub repository: https://github.com/spring-projects/spring-framework
- Published packages: https://central.sonatype.com/artifact/org.springframework/spring-web
- Package manager: Maven
- Fixed in:
- NES for Spring Framework 4.3.x, 5.3.x, 6.1.x
- Spring Framework 7.0.8, 6.2.19 (OSS)
Vulnerability Info
The vulnerability is in JavaScriptUtils.javaScriptEscape(String) in the spring-web module. The method walks the input character by character and appends an escape sequence for each character that is special in a JavaScript string. Before the fix, the escape chain covered quotes, the backslash, the forward slash, the standard control characters, the angle-bracket characters, and the U+2028 and U+2029 line separators, but it had no branch for the backtick or the dollar sign, so both passed through unescaped.
Inside a single- or double-quoted JavaScript string literal that is harmless, which is the context the method was originally designed for. Inside an ECMAScript template literal it is not: the template literal is delimited by backticks, and the dollar-brace syntax interpolates and evaluates a JavaScript expression. If an application uses javaScriptEscape to inline a server-side value into a template literal, for example:
<script>
const label = `Hello ${userControlledValue}`;
</script>
Then a value that contains an unescaped backtick (breaking out of the template literal) or an interpolation sequence such as ${maliciousExpression} (which is interpolated and evaluated directly) is rendered verbatim. In both cases the attacker's JavaScript executes in the victim's browser within the application's origin, which is the defining behavior of cross-site scripting.
The fix adds two branches to the escape chain so that the backtick is rewritten to its Unicode escape and the dollar sign to its Unicode escape, neutralizing both template-literal delimiters while leaving the rest of the method unchanged:
else if (c == '
') {
filtered.append("\\u2028");
}
else if (c == '
') {
filtered.append("\\u2029");
}
else {
filtered.append(c);
}
The change ships in upstream commit a1826b725c29fbb175fa7b4fc005aa3d78c32015 ("Refine JavaScriptUtils#javaScriptEscape", Closes gh-36795), authored by Sébastien Deleuze and committed by Brian Clozel. It is accompanied by two regression tests that assert the new escapes:
@Test
void escapeBacktick() {
assertThat(JavaScriptUtils.javaScriptEscape("`")).isEqualTo("\\u0060");
}
@Test
void escapeDollar() {
assertThat(JavaScriptUtils.javaScriptEscape("$")).isEqualTo("\\u0024");
}
This is the same method that was hardened once before, when angle-bracket escaping was added in response to CVE-2013-6430. The template-literal characters were not in scope then and are addressed by this fix. Because neither the backtick nor the dollar sign was ever escaped on any release line prior to this fix, every Spring Framework release from at least 4.3.0 through the pre-fix tips of the 5.3.x, 6.1.x, 6.2.x, and 7.0.x lines is affected.
Mitigation
Only recent versions of Spring Framework receive community support and updates. Older versions, including the 4.3.x, 5.3.x, and 6.1.x lines, have no publicly available open-source fix for this vulnerability; the patch for those lines is delivered only through commercial builds.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a currently supported open-source version of Spring Framework that contains the fix. The OSS fix ships in Spring Framework 7.0.8 (7.0.x line) and 6.2.19 (6.2.x line).
- Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework, which provides patched 4.3.x, 5.3.x, and 6.1.x builds.
