CVE-2026-47884

Overview

Spring Framework is a widely used application framework for the Java platform, including the Spring MVC servlet web stack. When a handler finishes without naming a view, DispatcherServlet derives one from the request path. One of the view technologies shipped with Spring MVC is XsltView, which renders the model through an XSLT stylesheet whose location comes from the view's url property, typically composed by XsltViewResolver from a prefix, the view name, and a suffix.

A server-side request forgery vulnerability (CVE-2026-47884) has been identified in XsltView. The view passes its stylesheet location to the application context's resource loader without validation, so an attacker can make the server load a stylesheet from a location of their choosing, including remote URLs and files outside the intended directory. Because the loaded document is executed as a stylesheet, an attacker who supplies it can escalate to remote code execution. The issue is only reachable when a /** mapping renders a view whose name is not set explicitly, so the stylesheet location is derived from the request.

Per OWASP: In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.

NVD rates this vulnerability Critical with the CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (base score 9.8): an unauthenticated network request reaches arbitrary code execution because the loaded stylesheet is run by a transformer with secure processing disabled. The advisory classifies this under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-918 (Server-Side Request Forgery).

This issue affects multiple versions of Spring Framework, including the End-of-Life 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines supported by NES for Spring Framework.

Details

Module Info

• Product: Spring Framework
• Affected packages: org.springframework:spring-webmvc
• Affected versions: <=5.2.25.RELEASE, >=5.3.0 <=5.3.49, >=6.0.0 <=6.0.30, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
• GitHub repository: https://github.com/spring-projects/spring-framework
• Published packages: https://central.sonatype.com/artifact/org.springframework/spring-webmvc
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Framework nes-v4.3.40, nes-v5.3.54, nes-v6.1.30, and nes-v6.2.21
  • Spring Framework 7.0.9 (OSS)

Vulnerability Info

This vulnerability is found in the spring-webmvc package in multiple versions of Spring Framework. org.springframework.web.servlet.view.xslt.XsltView transforms the model with an XSLT stylesheet identified by its url property. Every render, getStylesheetSource() turns that string into a Source by asking the application context for the resource it names:

protected Source getStylesheetSource() {
    String url = getUrl();
    Assert.state(url != null, "'url' not set");

    if (logger.isDebugEnabled()) {
        logger.debug("Applying stylesheet [" + url + "]");
    }
    try {
        Resource resource = obtainApplicationContext().getResource(url);
        return new StreamSource(resource.getInputStream(), resource.getURI().toASCIIString());
    }
    catch (IOException ex) {
        throw new ApplicationContextException("Cannot load XSLT stylesheet from '" + url + "'", ex);
    }
}

ApplicationContext.getResource accepts any Spring resource location, not just a path inside the web application: a http: or https: URL is fetched from the network, a file: URL is read from the local file system, classpath: locations are read from the class path, and relative paths are resolved against the servlet context, including paths that climb out of the intended directory with parent segments. Nothing in getStylesheetSource() inspects the location before handing it over, so whoever controls the url string controls where the server goes to fetch the stylesheet.

In a typical configuration the url is not a hard-coded constant. XsltViewResolver builds it as prefix plus view name plus suffix, and the view name comes from the handler. When a handler mapped with a broad pattern such as /** completes without specifying a view name, DispatcherServlet asks its RequestToViewNameTranslator for one, and the default translator derives it from the request path. In that situation the request path flows into the view name, the view name flows into the stylesheet location, and the stylesheet location flows unchecked into getResource. An attacker can therefore craft a request whose path makes the application fetch a stylesheet from a location they name. The immediate result is server-side request forgery: the application issues a request to an internal or external address chosen by the attacker and processes the response. If the fetched document is an XSLT stylesheet the attacker authored, the JDK transformer executes it, and XSLT extension mechanisms available to the transformer can be used to run arbitrary code on the server, which is why the advisory describes the impact as both SSRF and remote code execution.

Applications that instantiate XsltView only with hard-coded stylesheet locations and always specify view names explicitly do not expose this path, but the class itself accepts unvalidated locations in every affected version.

Mitigation

Only recent versions of Spring Framework receive community support. The 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines are End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for those lines other than through a commercial support partner.

Applications that cannot upgrade immediately can reduce their exposure by always specifying the view name explicitly in handlers that render through XsltView, rather than relying on the default request-to-view-name translation, and by avoiding catch-all /** mappings that fall through to view rendering, since the issue requires the stylesheet location to be derived from the request.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Framework. The open-source fix ships in Spring Framework 7.0.9 on the 7.0.x line.
• Leverage a commercial support partner like HeroDevs for post-EOL Spring NES support, which provides the fix for the 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines in nes-v4.3.40, nes-v5.3.54, nes-v6.1.30, and nes-v6.2.21.

Credits

• tonghuaroot (finder)