CVE-2026-40987

Path Traversal
Affects
Spring Integration
in
Spring
No items found.
Versions
>=5.5.0 <=5.5.20, >=6.2.0 <=6.2.11, >=6.3.0 <=6.3.14, >=6.4.0 <=6.4.11, >=6.5.0 <=6.5.8, >=7.0.0 <=7.0.4
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring Integration is an extension of the Spring programming model that implements the Enterprise Integration Patterns, letting Spring applications build messaging-based integration flows over channels, endpoints, and adapters. Its file support modules include inbound channel adapters and gateways that synchronize files from remote FTP, SFTP, and SMB servers into a configured local directory.

A high-severity vulnerability (CVE-2026-40987) has been identified in Spring Integration's remote file synchronization. The remote file synchronizer and the remote file outbound gateway write files under the configured local directory using the filename supplied by the remote server, without canonicalizing the resulting path. A malicious or compromised FTP, SFTP, or SMB server can return filenames containing traversal sequences or absolute paths, causing the client application to write arbitrary files anywhere on the client filesystem, outside the configured local directory, with attacker-controlled content.

This is a path traversal weakness. 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. In this case the traversal happens on the consuming client's filesystem, so a hostile remote file server can plant or overwrite files such as startup scripts or configuration anywhere the client process can write.

This issue affects versions >=5.5.0 <=5.5.20, >=6.2.0 <=6.2.11, >=6.3.0 <=6.3.14, >=6.4.0 <=6.4.11, >=6.5.0 <=6.5.8, and >=7.0.0 <=7.0.4 of Spring Integration.

Details

Module Info

Vulnerability Info

The vulnerability is in the spring-integration-file module, which provides the shared base classes for the FTP, SFTP, and SMB adapters. When an inbound channel adapter synchronizes a remote directory, AbstractInboundFileSynchronizer in the org.springframework.integration.file.remote.synchronizer package builds the local destination directly from the filename the remote server reports:

File localFile = new File(localDirectory, localFileName);

localFileName is derived from the server-supplied remote filename, and the resulting path was never canonicalized or checked against localDirectory. A remote server that lists an entry whose name walks up several parent directories and points at a user's shell startup file causes the synchronizer to resolve a path outside the local directory and write the downloaded content there. The same unvalidated pattern exists in AbstractRemoteFileOutboundGateway, which builds the local file for get and mget operations from the remote filename, and in FileWritingMessageHandler, which builds its temporary and destination files from the generated filename, a value that is frequently taken from message headers.

Because the affected classes are the common base of the FTP, SFTP, and SMB inbound adapters and outbound gateways, any application that synchronizes files from a remote server it does not fully control is exposed. A malicious or compromised server can create or overwrite arbitrary files with attacker-controlled content under the permissions of the client process, which can lead to code execution, for example by planting scheduled-task entries, shell profiles, or application configuration.

The remediation introduces a validation step when constructing the local file. The filename is rejected if it is an absolute path, and the resolved file's canonical path must equal its absolute path, which rejects any name that navigates outside the target directory regardless of the characters used. Invalid names fail the message flow with an exception instead of writing the file. The synchronizer also now moves its temporary download file into place atomically, eliminating a time-of-check to time-of-use window in which a local attacker could redirect the validated destination with a symlink.

This vulnerability was introduced in 2010 with Spring Integration 2.0.

Mitigation

Spring Integration 5.5.x, 6.0.x, 6.1.x, 6.2.x, 6.3.x, and 6.4.x are End-of-Life open source lines and have no publicly available fix for this vulnerability.

Users of the affected components should apply one of the following mitigations:

  1. Upgrade to a currently supported version of Spring Integration that contains the fix. The OSS fix ships in Spring Integration 7.0.5 (7.0.x line) and 6.5.9 (6.5.x line).
  2. Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Integration, which delivers the fix on the 5.5.x, 6.2.x, 6.3.x, and 6.4.x lines.

Credits

  • M0untainShley (finder)
  • SharlongWen (finder)
  • daehyuh (finder)
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
High
ID
CVE-2026-40987
PROJECT Affected
Spring Integration
Versions Affected
>=5.5.0 <=5.5.20, >=6.2.0 <=6.2.11, >=6.3.0 <=6.3.14, >=6.4.0 <=6.4.11, >=6.5.0 <=6.5.8, >=7.0.0 <=7.0.4
NES Versions Affected
Published date
June 11, 2026
≈ Fix date
June 10, 2026
Category
Path Traversal
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By clicking “submit” I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.