CVE-2026-47884: Spring XsltView SSRF and RCE Exposure Explained

CVE-2026-47884 does not make every Spring MVC application remotely exploitable. The published Spring advisory describes a specific chain involving XsltView, a broad /** mapping that reaches view rendering, and a view name that the application does not explicitly set. When those conditions align, request-controlled path information can influence XSLT view resolution and create server-side request forgery or remote code execution risk. See Spring security advisory.

The immediate defensive task is therefore two-dimensional: update the affected Spring Framework branch and determine whether the application exposes the required configuration. A dependency scanner can establish that a vulnerable framework version is present. It cannot establish that XsltView is selected, that a catch-all route renders a view, or that view names are implicit. Treat those as separate evidence questions.

Required exposure conditions

Spring’s public description identifies three conditions that matter together: See Spring security advisory.

1. The application uses XsltView or an XSLT-oriented view resolver.
2. A /** mapping, or an equivalent catch-all path, can complete through view rendering.
3. The handler does not explicitly select a safe view name.

If an application does not use XSLT views, the published XsltView path is absent even if the Spring dependency falls in an affected range. If it uses XSLT only behind tightly defined routes with constant view names, the specific implicit-name condition is absent. Those observations reduce exposure to this CVE; they do not prove that the application has no other path traversal, SSRF, template, or XML-processing weakness.

Conversely, a broad route should not be declared safe merely because developers intended it to return an error page. Inspect the effective handler, resolver order, exception handling, and fallback behavior. Framework configuration, annotations, XML application context, and programmatic bean registration can all affect the result.

Affected and fixed Spring Framework releases

Version reference: Spring security advisory.

Use the fixed version appropriate to a supported application and framework line. The vendor lists 7.0.9 as an OSS fix and also lists 7.0.8.1 plus the 6.x and 5.x corrections under Enterprise Support. The table is a CVE boundary, not a recommendation to remain on an obsolete branch. Spring Boot applications should normally move through a supported Boot release or BOM that selects a corrected Framework version, then confirm the resolved dependency rather than assuming that changing one property updated the deployable artifact. See Spring security advisory.

Why implicit view names change the boundary

Spring MVC handlers can return a view name explicitly, return a model while allowing the framework to derive the name, or rely on resolver and convention behavior. Implicit view naming is convenient, but it makes route-to-view transformation part of the security boundary. A request path that was expected to choose only a controller can also influence which view resource is resolved.

XSLT views are especially sensitive because a stylesheet is executable transformation logic rather than a passive text template. XSLT processors may interact with local or remote resources depending on implementation, configuration, and security controls. The official advisory therefore describes both SSRF and RCE as possible outcomes under the vulnerable configuration. It does not publish a universal endpoint or payload, and defenders should not invent one for production testing. See Spring security advisory.

Safe repository audit

Start with source and effective dependency evidence. The following commands are read-only examples for a repository you administer. Adapt paths and build profiles to the actual project.

rg -n "XsltView|XsltViewResolver|ViewNameTranslator|setViewName" src
rg -n "@RequestMapping|@GetMapping|@PostMapping" src | rg '(/\*\*|\*\*)'

# Maven
./mvnw dependency:tree -Dincludes=org.springframework:spring-webmvc

# Gradle
./gradlew dependencyInsight \
  --dependency spring-webmvc \
  --configuration runtimeClasspath

Do not stop at a zero-result search. Configuration can arrive through an internal library, an auto-configuration module, a shared parent, or an imported XML context. Inspect the deployable module and the runtime classpath. Record the Spring Framework version, Spring Boot version where applicable, resolver beans, catch-all mappings, returned view names, and the build identifier that produced the deployed artifact.

Explore Penligent for authorized security testing and evidence review.

Configuration decision table

Version reference: Spring security advisory.

Temporary controls when an update cannot be deployed immediately

The strongest correction is a supported fixed Spring release. Temporary risk reduction should target the stated prerequisites: remove or narrow catch-all mappings that render views, set view names explicitly from a closed allowlist, and disable unused XSLT view resolution. Test the change because resolver order and error handling can affect unrelated routes.

Network egress restrictions can reduce SSRF consequences, and hardened XML/XSLT processor settings can reduce external-resource behavior. These controls are defense in depth. They should not be recorded as proof that vulnerable framework code has been removed.

Patch verification without exploit traffic

1. Capture the pre-change effective dependency tree and deployment digest.
2. Update through the supported dependency-management path.
3. Rebuild from trusted sources and confirm that the corrected spring-webmvc version is packaged.
4. Deploy to a controlled environment and exercise legitimate XSLT routes.
5. Test unknown and nested routes to confirm that they produce the intended error or constant view.
6. Confirm that the running artifact matches the approved build and retain the evidence.

A useful regression suite should validate route selection, resolver output, and external-resource restrictions. It does not need a weaponized stylesheet or a production callback server. The acceptance condition is that untrusted paths cannot select arbitrary XSLT resources and that the running application contains the corrected framework.

Detection and incident review

Review requests reaching broad mappings, unexpected XSLT view-resolution errors, attempts to reference unusual schemes or external hosts, and outbound connections from the application that do not match its expected service dependencies. These are investigation leads, not a reliable universal exploit signature. Normal application errors and legitimate transformations can produce similar events.

If exposure conditions were present on an internet-facing application, preserve web access logs, application logs, egress telemetry, deployment history, and relevant XSLT resources before destructive cleanup. Patch the framework and configuration first, then decide whether the evidence supports credential rotation, host rebuild, or a broader incident response.

الخاتمة

CVE-2026-47884 is rated Medium by Spring and has a narrow but important configuration boundary. The correct response is not to label every application using Spring as remotely exploitable. Identify XsltView, the route that reaches it, and how the view name is chosen; update to the fixed branch; verify the running artifact; and retain configuration and regression evidence. That process removes both false reassurance from version-only patching and false alarms from dependency-only scanning.