CVE-2026-47884

Overview

Spring Framework is a widely used application framework for the Java platform that provides the core programming and configuration model for modern Java enterprise applications, including the Spring MVC servlet web stack. Spring MVC resolves the logical view name a controller returns into a concrete view, and when a handler finishes without naming a view, DispatcherServlet derives one from the request path. Among the view technologies shipped with Spring MVC is XsltView, which renders a response by running the model through an XSLT stylesheet whose location is given by the view's url property, typically composed by XsltViewResolver from a configured prefix, the view name, and a suffix.

A server-side request forgery vulnerability (CVE-2026-47884) has been identified in XsltView, which allows attackers to make the server load an XSLT stylesheet from a location of their choosing, including remote URLs and resources outside the intended stylesheet directory, because the view passes its stylesheet location to the application context's resource loader without any validation. Because the loaded document is executed as an XSLT stylesheet, an attacker who can supply the stylesheet can also escalate the issue to remote code execution. The vulnerability is only relevant when an application has a /** mapping that results in view rendering and the view name is not explicitly specified, so that 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.

The advisory rates this vulnerability Medium severity with the CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, which corresponds to a base score of 5.8. The attack vector is Network because the stylesheet location is influenced by an ordinary HTTP request, no privileges or user interaction are required, the scope is Changed because the server is made to reach systems beyond the vulnerable application, and the Confidentiality impact is Low because the direct outcome scored is the forged request itself rather than disclosure of the application's own data.

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, >=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 Medium-severity vulnerability is found in the spring-webmvc package in multiple versions of Spring Framework. org.springframework.web.servlet.view.xslt.XsltView is a View implementation that transforms the model with an XSLT stylesheet. The stylesheet is identified by the view's url property, and every time the view renders, getStylesheetSource() turns that string into a Source for the transformer 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.

This vulnerability was introduced in 2006 with Spring Framework 2.0.

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)