CVE-2026-59280

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. Its spring-context-support module integrates the FreeMarker template engine, and when an application configures a FreeMarker template path that cannot be resolved to a plain file-system directory, the framework loads templates through its own SpringTemplateLoader, which looks each template name up through a Spring resource loader.

A path traversal vulnerability (CVE-2026-59280) has been identified in that template loader, which allows attackers to read files outside the configured template directory when an application returns a view name derived from untrusted input. A template name containing backslash sequences is passed through to resource resolution without being rejected, so a name such as ..\other.txt can escape the template directory. Deriving view names from request data is an application-level anti-pattern that the Spring documentation warns against, and applications that do not do so are not affected.

Per OWASP: A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with "dot-dot-slash (../)" sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.

The advisory rates this vulnerability Medium severity with the CVSS v3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, which corresponds to a base score of 5.9. The attack vector is Network because the template name arrives in an HTTP request, attack complexity is High because the application must both use the Spring resource-based template loader and expose an attacker-influenced view name, no privileges or user interaction are required, and the impact is Confidentiality-only because the consequence is disclosure of files the resource loader can reach.

This issue affects Spring Framework <=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, and >=7.0.0 <=7.0.8, 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-context-support
• 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-context-support
• 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-context-support package in multiple versions of Spring Framework. The FreeMarker integration chooses a template loader from the configured template loader path in FreeMarkerConfigurationFactory. A path that resolves to a real directory is handed to FreeMarker's own file-based loader, but any other path, such as a classpath or servlet-context location, is served by org.springframework.ui.freemarker.SpringTemplateLoader, whose findTemplateSource method builds the resource location by plain string concatenation:

public Object findTemplateSource(String name) throws IOException {
    if (logger.isDebugEnabled()) {
        logger.debug("Looking for FreeMarker template with name [" + name + "]");
    }
    Resource resource = this.resourceLoader.getResource(this.templateLoaderPath + name);
    return (resource.exists() ? resource : null);
}

FreeMarker normalizes template names before it asks a loader for them, and its default template name format rejects names that climb above the template root with forward-slash .. segments. It does not treat a backslash as a path separator, so a name such as ..\..\secret passes FreeMarker's normalization untouched and reaches findTemplateSource as-is. The loader appends that name to the template loader path and asks the Spring ResourceLoader for the result, and at that stage the backslashes are interpreted by the underlying resource and file handling, which can resolve them as directory separators. The lookup therefore returns a resource outside the configured template directory, and the application renders it as if it were a template.

The flaw is reachable only when a controller returns a view name that incorporates untrusted request data, so that the attacker controls the template name that reaches the loader. An attacker who can do so on an affected version can disclose arbitrary files the resource loader can reach, including application configuration and other templates. Applications that use FreeMarker's own file-based loader (because the template path resolves to a file-system directory), or that opt into FreeMarker's stricter DEFAULT_2_4_0 template name format, which rejects backslashes itself, are not reachable through this path.

This vulnerability was introduced in 2004 with Spring Framework 1.0.

Steps to Reproduce

1. Create a temporary directory containing a templates subdirectory with a file hello.ftl, and place a second file other.txt next to the templates directory (outside it).

2. Build a SpringTemplateLoader over that directory using a file: resource location and an affected version of spring-context-support, for example 6.2.19:

ResourceLoader resourceLoader = new DefaultResourceLoader();
SpringTemplateLoader loader = new SpringTemplateLoader(
        resourceLoader, "file:" + tempDir.resolve("templates").toAbsolutePath() + "/");

Object inside = loader.findTemplateSource("hello.ftl");
Object escaped = loader.findTemplateSource("..\\other.txt");
System.out.println(inside);
System.out.println(escaped);

3. Observe that hello.ftl resolves as expected, and that ..\other.txt also resolves to a non-null resource pointing at the file outside the templates directory: the backslash sequence was appended to the template path and accepted by resource resolution.

4. Repeat the same call on a patched version, for example 7.0.9, and observe that the lookup for ..\other.txt returns null while hello.ftl still resolves.

‍

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 can reduce exposure by never deriving view or template names from request data; when the view name is chosen by application code alone, the template name that reaches the loader is not attacker-controlled and the issue is not reachable.

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 security 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

• No public finder credit is listed in the advisory sources checked for this entry.