CVE-2026-22737

What it actually does

CVE-2026-22737 is a path traversal vulnerability in Spring Framework applications that use script-based template views with Java scripting engines such as JRuby or Jython in Spring MVC or Spring WebFlux. Under affected versions, template resolution can allow content to be read from files outside the configured script template locations. The issue primarily impacts confidentiality: an unauthenticated remote attacker may be able to cause the application to disclose local file contents if the application exposes a reachable code path where template/view selection can be influenced. Integrity and availability are not directly affected by the vulnerability as described. The high attack complexity reflects that exploitation depends on a specific application configuration and request flow, not merely the presence of Spring Framework.

Why it matters to the business

Successful exploitation could expose sensitive application files such as configuration files, credentials, API keys, templates, source files, or deployment metadata. That information can enable follow-on compromise, including credential theft, cloud or database access, lateral movement, or targeted attacks against the application stack. Risk is highest for externally reachable Spring MVC or WebFlux applications using JRuby, Jython, or other Java scripting-engine-backed template views. The vulnerability is not currently listed in CISA KEV, has no reported public exploit maturity in the provided data, and has a low EPSS score, but organizations with the affected configuration should still prioritize remediation because file disclosure bugs can expose secrets that materially increase breach impact.

How an attack unfolds

An attacker first identifies a Spring MVC or Spring WebFlux application that uses script template views backed by a Java scripting engine such as JRuby or Jython. They then look for endpoints where request parameters, path segments, locale/theme values, or routing behavior influence the selected view or template path. If the application runs an affected Spring Framework version, the attacker submits crafted traversal sequences or encoded traversal sequences intended to escape the configured template directory. When the vulnerable template resolver processes the request, it may read a file outside the intended script-template location and include the file contents in the HTTP response or error path. The attacker repeats this process to retrieve high-value files such as application configuration, dependency metadata, environment-specific secrets, credentials, or source templates, then uses the disclosed information for subsequent intrusion or privilege escalation.

How to fix it

Upgrade Spring Framework to a version not affected by the vulnerable ranges. The affected ranges provided are 7.0.0 through 7.0.5, 6.2.0 through 6.2.16, 6.1.0 through 6.1.25, and 5.3.0 through 5.3.46; use the vendor-recommended fixed release for the maintained branch in use. If an immediate upgrade is not possible, disable Java scripting-engine template views where they are not required, remove JRuby/Jython script template dependencies if unused, and ensure view/template names are never directly derived from untrusted input. Restrict template resolution to explicit allowlisted view names, canonicalize and validate paths before use, reject traversal sequences and encoded traversal variants, and avoid exposing detailed template-resolution errors to clients. Review application secrets and rotate any credentials that may have been exposed if suspicious access is found.

How to confirm the fix worked

Confirm the application is no longer running an affected Spring Framework version by inspecting build manifests, dependency lockfiles, SBOMs, container images, and runtime classpath contents. For Maven, review resolved versions of org.springframework:spring-webmvc, org.springframework:spring-webflux, org.springframework:spring-context, and related Spring Framework artifacts; for Gradle, review the dependency tree and dependency locks. Confirm whether script template support is enabled by searching configuration and code for ScriptTemplateView, ScriptTemplateViewResolver, ScriptTemplateConfigurer, JRuby, Jython, and Java Scripting API usage. Perform safe validation in a non-production environment by exercising routes that select script templates and verifying traversal payloads are rejected or resolved only within the intended template directory. Verify that WAF or application-layer controls block encoded and double-encoded traversal attempts, but do not treat WAF blocking as a substitute for upgrading.

Typical attack path

1. Fingerprint the target as a Spring MVC or Spring WebFlux application and identify whether script-based template rendering is likely in use.
2. Find endpoints where the rendered view or template name can be influenced by URL path, query parameter, form field, header, locale, theme, or routing behavior.
3. Send path traversal payloads such as dot-dot-slash sequences or encoded equivalents targeting files outside the configured template directory.
4. Observe HTTP responses, error messages, or rendered output for evidence that unintended local file contents were returned.
5. Retrieve sensitive files such as application configuration, secrets, deployment descriptors, source templates, or runtime metadata.
6. Use disclosed credentials or implementation details to support follow-on attacks against the application, infrastructure, or connected services.

How to detect it

To determine whether exploitation has already been attempted or succeeded, review HTTP access logs, reverse proxy logs, WAF events, application logs, and error traces for traversal payloads targeting routes that render views or templates. Focus on requests containing ../, ..\, URL-encoded traversal, double-encoded traversal, or attempts to retrieve configuration and secret-bearing files. Correlate suspicious requests with unusually large 200 responses, responses containing configuration-like content, template-rendering errors, or repeated probing of different file paths. Application logs may include Spring script template classes, view-resolution failures, Java scripting errors, or stack traces involving ScriptTemplateView, ScriptTemplateViewResolver, or script engine execution. Because the vulnerability is file disclosure rather than code execution, host-level artifacts may be minimal; prioritize log review and credential exposure assessment. If suspicious disclosure is found, identify which files may have been exposed, rotate any affected secrets, and investigate subsequent authentication or API activity using those credentials.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• %252e%252e%252f
• %c0%ae%c0%ae%c0%af
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /WEB-INF/web.xml
• WEB-INF/web.xml
• application.properties
• application.yml
• bootstrap.properties
• bootstrap.yml
• .env
• pom.xml
• build.gradle
• settings.gradle
• logback.xml
• log4j2.xml
• ScriptTemplateView
• ScriptTemplateViewResolver
• ScriptTemplateConfigurer
• org.springframework.web.servlet.view.script
• org.springframework.web.reactive.result.view.script
• javax.script.ScriptException
• NoSuchFileException
• FileNotFoundException

What your security team should do

• Inventory externally reachable Spring MVC and Spring WebFlux applications and prioritize those using script-based template views or Java scripting engines such as JRuby or Jython.
• Upgrade affected Spring Framework deployments to vendor-fixed versions outside the listed vulnerable ranges as soon as practical.
• Search source code, configuration, and dependency manifests for script template view usage and remove it where unnecessary.
• Review endpoints for user-controllable view or template selection and replace dynamic resolution with strict allowlists.
• Enable or tune WAF rules for path traversal attempts, including encoded and double-encoded dot-dot-slash payloads, while patching is underway.
• Review web access logs and application logs for attempted traversal against template-rendering routes and for suspicious file disclosure responses.
• Rotate secrets if logs suggest sensitive files such as application properties, environment files, keys, or credentials may have been returned.
• Add regression tests that ensure template resolution cannot escape configured template directories.