CVE-2026-47884 in Spring
Summary
by MITRE • 08/27/2026
Use of XsltView in a Spring MVC application can result in SSRF and RCE attack if the application has an "/**" mapping that results in view rendering, and where the view name is not explicitly specified. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability described involves a critical security flaw within the Spring MVC framework, specifically related to the handling of XsltView when combined with broad URL path mappings. This issue arises in applications that utilize an "/**" mapping pattern which triggers view resolution without explicitly defining or validating the target view name. When such conditions are met, an attacker can manipulate the input used for view rendering to inject malicious payloads. The core technical flaw lies in how the framework processes the view name passed through these mappings. If the application logic allows user-controlled data to influence the selection of the XsltView component without sufficient sanitization or validation, it creates a pathway for server-side request forgery and remote code execution attacks.
Server-Side Request Forgery occurs because the vulnerable implementation may allow an attacker to direct the internal XML processing engine to fetch resources from arbitrary locations on the network. By controlling the input that determines the view source or associated stylesheets, an adversary can force the application server to make HTTP requests to internal services, cloud metadata endpoints, or other sensitive infrastructure components that are not directly accessible from the external internet. This capability enables attackers to map out internal networks, steal credentials stored in instance metadata, or access private APIs, effectively bypassing network-level security controls designed to protect backend systems from unauthorized external access.
The risk escalates significantly when this SSRF vector is leveraged for Remote Code Execution. If the application processes XML data that includes external entity references or if the XSLT transformation itself can be manipulated to execute system commands through specific extension functions available in certain Java-based XSLT processors, an attacker gains the ability to run arbitrary code on the server hosting the Spring MVC application. This transition from SSRF to RCE represents a severe compromise of confidentiality, integrity, and availability. It allows for complete control over the underlying operating system, leading to potential data exfiltration, lateral movement within the network, and persistent backdoor installation.
This vulnerability affects multiple versions of the Spring Framework, including releases 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, and the legacy branches 5.3.0 through 5.3.49 as well as version 5.2.25.RELEASE and earlier. The widespread nature of these affected versions underscores the importance of timely patching across diverse enterprise environments that rely on Spring MVC for web application development. Organizations must audit their codebases to identify any usage patterns involving XsltView combined with wildcard mappings or dynamic view name resolution, as this specific configuration is the primary trigger for the exploit chain described above.
Mitigation strategies should prioritize upgrading to a patched version of the Spring Framework that addresses these security flaws immediately after verification against application compatibility requirements. In cases where immediate patching is not feasible, developers must implement strict input validation and sanitization on all parameters that influence view resolution. It is crucial to avoid using wildcard mappings like "/**" for general request handling unless absolutely necessary, and instead use more specific path patterns. Additionally, applications should explicitly specify the intended view name rather than allowing it to be inferred from user-supplied data. Disabling XSLT extensions that allow system command execution can also reduce the attack surface by preventing the RCE aspect of this vulnerability even if SSRF is attempted.
From a classification perspective, this issue aligns with CWE-918 Server-Side Request Forgery and CWE-77 Command Injection via External Control of Format String or similar mechanisms depending on the specific exploitation path taken. In terms of adversary tactics, it maps to ATT&CK technique T1557 Adversary-in-the-Middle for SSRF activities and potentially T1059 Command and Scripting Interpreter if RCE is achieved through script execution within the XSLT processor. Security teams should monitor logs for unusual outbound network connections from application servers and inspect XML parsing events for signs of external entity injection or unexpected transformation parameters to detect potential exploitation attempts in real-time.