CVE-2026-59311
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Spring Integration is the Spring portfolio project that brings the Enterprise Integration Patterns to Spring applications. It provides a lightweight messaging framework of channels, endpoints, transformers and routers, together with channel adapters for protocols and technologies such as files, FTP, HTTP, JDBC, JMS, AMQP, SMB and ZeroMQ.
A Path Traversal vulnerability (CVE-2026-59311) has been identified in AbstractZipTransformer, the base class of the Zip and UnZip transformers, which allows an unprivileged local user to redirect every file the transformers write into a directory of their choosing, under the identity of the application.
MITRE's CWE-59: Improper Link Resolution Before File Access ('Link Following') describes this weakness as one where the product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
This issue affects the Zip transformers of Spring Integration.
Details
Module Info
- Product: Spring Integration
- Affected packages:
org.springframework.integration:spring-integration-zip - Affected versions: >=7.1.0 <7.1.1, >=7.0.0 <7.0.6, >=6.1.0 <=6.5.10
- GitHub repository: https://github.com/spring-projects/spring-integration
- Published packages: https://central.sonatype.com/artifact/org.springframework.integration/spring-integration-zip
- Package manager: Maven
- Fixed in:
- NES for Spring Integration: nes-v6.2.21, nes-v6.3.16, nes-v6.4.15, and nes-v6.5.12
Vulnerability Info
This Medium-severity vulnerability is found in the org.springframework.integration:spring-integration-zip package in the Zip transformer support of Spring Integration.
AbstractZipTransformer defaults its work directory to a fixed, world-known path in the shared system temporary directory, and its initialization callback only asks whether the path exists before creating it:
protected File workDirectory =
new File(System.getProperty("java.io.tmpdir") + File.separator + "ziptransformer");
@Override
protected void onInit() {
super.onInit();
if (!this.workDirectory.exists()) {
logger.info(() -> "Creating work directory: " + this.workDirectory);
Assert.isTrue(this.workDirectory.mkdirs(), () -> "Can't create the 'workDirectory': " + this.workDirectory);
}
}
File.exists() follows symbolic links, so if a local user creates /tmp/ziptransformer as a link to a directory of their choice before the application starts, the check passes, no directory is created, and every result the ZipTransformer and UnZipTransformer produce is written through the link. The files land in the attacker's target directory owned by the application's user, which turns ordinary archive processing into local file planting, or into disclosure of the extracted contents when the target is a location the attacker can read.
Mitigation
Only recent versions of Spring Integration receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.
Users of the affected components should apply one of the following mitigations:
- Configure the work directory of the Zip transformers explicitly, with
setWorkDirectory()onZipTransformerandUnZipTransformer, pointing it at an existing directory that the application owns and that no other local user can create or write to, rather than leaving it in the shared system temporary directory. - Leverage a commercial support partner like HeroDevs for post-EOL security support.