Spring Framework CVE-2026-47884

Exploitation requires three specific application-side prerequisites drawn directly from the description: (1) the Spring MVC application must use XsltView; (2) it must have a '/' handler mapping that results in view rendering; and (3) the view name must NOT be explicitly specified, so it is inferred from the request in a way the attacker can influence. When all three hold, exploitation is remote and unauthenticated (CVSS PR:N, UI:N). The principal limiting factor is that this is a non-default, developer-chosen configuration - the vast majority of Spring MVC applications do not expose XsltView under an implicit-view catch-all mapping - so an application that does not use XsltView, that sets explicit view names, or that has no view-rendering '/' mapping is not exploitable regardless of the 9.8 base score.

The signals conflict and must be weighed rather than taken at face value. The published CVSS is 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), which reads as trivially exploitable by any remote unauthenticated attacker, but the description makes clear that exploitation is gated on a specific, non-default application design: use of XsltView, a '/**' mapping that results in view rendering, and an unspecified view name. That is not a default Spring configuration, which is why treating this as a universal 9.8 overstates the real-world attack surface. Countervailing this, SSVC rates Automatable=yes and Technical Impact=total, so any application that does match the vulnerable pattern is at severe, scriptable risk. EPSS is low (0.16%, 5th percentile) and there is no KEV listing and no public exploit identified at time of analysis, which points to targeted or not-yet-widespread exploitation rather than mass scanning today. The practical takeaway is that prioritization should be driven by configuration triage: an organization that confirms it uses XsltView with catch-all view rendering - even a mid-sized municipal IT team in gdynia should treat that finding as urgent - must patch immediately, whereas an organization that can confirm it does not use this pattern can schedule the upgrade on a normal cadence. Because Spring Framework itself is enormously widespread, the population of potentially-affected deployments is large even if the vulnerable subset is small.

An attacker identifies a public Spring MVC application that maps '/**' to view rendering without an explicit view name, then sends a crafted request whose path steers view resolution into XsltView and references an attacker-controlled stylesheet/resource. The XSLT processor fetches the external resource (SSRF into internal networks or cloud metadata) and executes the supplied transformation logic, achieving remote code execution as the application process. No public exploit is identified at time of analysis, and the network attack vector with low attacker-side complexity means a working exploit would be highly automatable per SSVC.