CVE-2026-59281

A flaw was found in Spring MVC and WebFlux applications. When these applications are configured to obtain a data-binding Errors instance with HTML escaping enabled and then render field errors using the no-argument Errors.getFieldErrors() or Errors.getFieldError() accessors, they become vulnerable. This vulnerability allows for arbitrary HTML or JavaScript code injection, potentially leading to a reflected cross-site scripting (XSS) attack where an attacker could execute malicious scripts in a user's web browser.

A cross-site scripting (XSS) vulnerability was found in the Spring Framework EscapedErrors wrapper. In versions 7.0.0 through 7.0.8, 6.2.0 through 6.2.19, 6.1.0 through 6.1.28, 6.0.0 through 6.0.30, 5.3.0 through 5.3.49, and 5.2.25.RELEASE and earlier, Spring MVC and WebFlux applications that obtain a data-binding Errors instance with HTML escaping enabled and then render field errors using the no-argument Errors.getFieldErrors() or Errors.getFieldError() accessors are vulnerable to arbitrary HTML and JavaScript code injection. The EscapedErrors wrapper's no argument accessors return the underlying field errors without escaping them, allowing attackers to inject malicious content that executes when the page is rendered, potentially resulting in reflected cross-site scripting attacks. This vulnerability was introduced in 2006 with Spring Framework 2.0. Red Hat ships Spring Framework version 2.x in Fedora, a community-supported distribution, which is affected by this vulnerability but is out of Red Hat's commercial support scope.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

Red Hat does not provide fixes for Spring Framework in Fedora, as it is a community-supported product outside of Red Hat's commercial support scope. Fedora users should monitor upstream Spring Framework releases and community package updates.

For customers using Spring Framework in custom applications or third-party software, the following mitigations are available:

1. Upgrade to Spring Framework 7.0.9 or later if using the 7.0.x line. Note that Spring Framework versions 4.3.x, 5.3.x, 6.1.x, and 6.2.x have reached end-of-life and will not receive public security updates.

2. If immediate upgrade is not possible, reduce exposure by rendering field errors through the per-field getFieldErrors(String field) and getFieldError(String field) accessors, or through getAllErrors(), which are escaped correctly.

3. Alternatively, explicitly HTML-escape the rejectedValue and defaultMessage of each field error in the template rather than relying on the wrapper to perform escaping.

4. Implement Content Security Policy (CSP) headers to provide an additional layer of defense against XSS attacks.

5. Review application code to identify uses of the no-argument Errors.getFieldErrors() or Errors.getFieldError() methods and replace them with the safer per-field accessors.