CVE-2026-41846

What it actually does

This is a reflected or stored cross-site scripting weakness in Spring MVC applications that bind user-controlled input into JSP form tag attributes named cssClass, cssErrorClass, or cssStyle. When an application passes untrusted data into these attributes without proper output encoding or allow-list validation, attacker-supplied HTML or JavaScript can be rendered into the page and executed in the victim’s browser. The issue affects Spring Framework 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48. The technical risk is highest where these attributes can be influenced by request parameters, stored profile/content fields, error messages, or other user-editable data that is later displayed to authenticated users.

Why it matters to the business

Successful exploitation can let an attacker run script in a user’s browser in the context of the vulnerable application. This can lead to session theft, unauthorized actions performed as the victim, phishing overlays, data exposure visible to the victim, or modification of page content. Because exploitation requires a victim to view or interact with a crafted page or link, the likelihood is lower than unauthenticated server compromise; however, the impact can still be meaningful for applications handling sensitive data, administrator workflows, financial actions, or customer-facing portals. The CVSS score is moderate at 5.9, EPSS is low at 0.0014 and flat over 30 days, it is not currently listed in CISA KEV, and no public exploit maturity is indicated, so remediation should be prioritized based on exposure and data sensitivity rather than treated as an emergency internet-wide exploitation event.

How an attack unfolds

An attacker first identifies a Spring MVC page using JSP form tags where the cssClass, cssErrorClass, or cssStyle attribute is populated from user-controllable input. The attacker then crafts a payload containing HTML or JavaScript, such as an event-handler attribute, script URL, malformed style value, or tag-breaking sequence. If the vulnerable application reflects that value immediately, the attacker sends a crafted link or form submission to a victim. If the value is stored, the attacker saves the payload in a field later rendered by the vulnerable JSP. When the victim opens the affected page, the application renders the attacker-controlled value into the HTML attribute context without sufficient encoding. The browser interprets the injected markup or script, allowing the attacker to execute code as the victim within the application’s origin. The attacker may then steal tokens accessible to JavaScript, perform actions using the victim’s session, alter displayed content, or redirect the victim to a phishing flow.

How to fix it

Upgrade Spring Framework to a vendor-fixed version outside the affected ranges. Applications on 7.0.x should move to a release newer than 7.0.7; applications on 6.2.x should move to a release newer than 6.2.18; applications on 6.1.x should move to a release newer than 6.1.27; and applications on 5.3.x should move to a release newer than 5.3.48, using the exact fixed version published for the relevant support line. If immediate upgrade is not possible, review JSPs and custom tags for use of cssClass, cssErrorClass, and cssStyle and ensure these attributes are never populated directly from request parameters or other untrusted data. Apply strict allow-list validation for CSS class names and style values, encode output for the correct HTML attribute context, and avoid allowing arbitrary inline CSS from users. Prefer mapping user choices to server-side predefined class names rather than rendering raw user input. Add or strengthen Content Security Policy to reduce exploitability, but do not rely on CSP as the only fix. Regression-test form rendering, validation error rendering, and pages that display user-controlled data after applying the framework update.

How to confirm the fix worked

Confirm all deployed Spring Framework artifacts are outside the affected version ranges by checking dependency manifests, lockfiles, build output, and runtime classpath contents. For Java builds, inspect Maven or Gradle dependency trees for org.springframework:spring-webmvc and related Spring Framework modules and verify versions are no longer 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. Search JSP source for cssClass, cssErrorClass, and cssStyle and verify that any dynamic values are either constants, server-side allow-listed values, or correctly encoded for HTML attribute context. Perform safe dynamic testing in non-production by submitting benign XSS probes such as attribute-breaking strings and verifying they are rendered as inert text rather than executable markup. Review generated HTML around Spring form tags to confirm attacker-controlled characters such as quotes, angle brackets, and event-handler fragments are encoded or rejected. Validate that a restrictive Content Security Policy is present where feasible and that automated security tests cover form tag rendering paths.

Typical attack path

1. Identify a Spring MVC application using JSP form tags and affected Spring Framework versions.
2. Find a request parameter, stored field, validation error path, or template variable that flows into cssClass, cssErrorClass, or cssStyle.
3. Craft an HTML or JavaScript payload suitable for an attribute or style context.
4. Deliver the payload through a crafted URL, form submission, stored profile/content field, or other application input.
5. Cause a victim, preferably an authenticated or privileged user, to view the affected page.
6. Browser executes the injected script in the vulnerable application’s origin.
7. Use the victim’s session context to read accessible data, perform unauthorized actions, modify page content, or capture credentials/tokens.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs, reverse proxy logs, WAF events, application request logs, and any audit logs capturing submitted form values. Focus on requests to Spring MVC form pages and endpoints that re-render forms after validation errors. Search query strings, POST bodies, referrers, and stored user-editable fields for HTML attribute injection patterns, script tags, JavaScript URLs, CSS expression-like payloads, event-handler attributes, encoded angle brackets, encoded quotes, and attempts to break out of class or style attributes. If application logs capture validation errors or model attributes, review values that may have been passed into cssClass, cssErrorClass, or cssStyle. For stored XSS scenarios, inspect recently created or modified user content, profile fields, templates, comments, names, labels, or configuration values for script-like content. Browser-side evidence is often limited, but security telemetry may show victims loading unexpected external JavaScript, image beacons, credential-harvesting domains, or unusual same-origin state-changing requests shortly after viewing affected pages. Because this CVE has low EPSS, no KEV listing, and no known mature public exploit in the provided intelligence, treat hits as suspicious and triage based on whether the payload was rendered unencoded in application responses.

• cssClass=
• cssErrorClass=
• cssStyle=
• <script
• %3Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• autofocus onfocus=
• "><script
• '><script
• "><img
• '><img
• <img src=x onerror=
• %22%3E%3Cscript
• %27%3E%3Cscript
• %22%3E%3Cimg
• %27%3E%3Cimg
• document.cookie
• document.domain
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• alert(
• prompt(
• confirm(
• String.fromCharCode
• &#x3c;script
• &lt;script
• expression(
• url(javascript:

What your security team should do

• Inventory applications using Spring MVC with JSP form tags and identify those running Spring Framework 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.
• Prioritize remediation for internet-facing applications, administrator consoles, applications containing sensitive data, and pages where authenticated users view untrusted content.
• Upgrade Spring Framework to a fixed release for the deployed support line and redeploy affected applications.
• Search source code for cssClass, cssErrorClass, and cssStyle usage and remove any direct flow from request parameters or user-editable fields.
• Implement allow-list validation for CSS classes and avoid rendering user-supplied inline style values.
• Add regression tests for XSS in JSP form tag attributes, especially validation error views and forms that re-render submitted values.
• Review web access logs and application logs for recent XSS payload attempts targeting form-related parameters or values.
• Deploy or tune WAF/SIEM detections for common HTML attribute injection patterns, while treating them as compensating controls rather than a substitute for patching.
• Use Content Security Policy, secure cookies, and HttpOnly session cookies to reduce post-exploitation impact where compatible with the application.