CVE-2026-47862 in Spring Integration
Summary
by MITRE • 08/27/2026
An attacker who can set the file_name header on a message reaching a ZipTransformer with ZipResultType.FILE (the default) can cause the resulting .zip archive to be written to an arbitrary filesystem path outside the configured workDirectory. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability described constitutes a critical path traversal and arbitrary file write flaw within the ZipTransformer component of the Spring Integration framework, specifically affecting versions ranging from 6.4.0 through 7.1.0 depending on the specific release branch. This security issue arises when an attacker is able to manipulate or inject content into the file_name header of a message that is processed by a ZipTransformer configured with the default ZipResultType.FILE setting. Under normal operational parameters, this transformer is designed to create zip archives and write them to a designated work directory defined in the application configuration. However, due to insufficient validation of the filename provided via the message header, the underlying Java Archive API fails to sanitize path separators or resolve relative paths correctly before writing the file. This allows an attacker to specify absolute paths or sequences such as dot-dot-slash that escape the intended sandboxed work directory and write files to arbitrary locations on the host filesystem where the application is running.
From a technical perspective, this flaw represents a classic case of insecure direct object reference combined with path traversal vulnerabilities. The root cause lies in the lack of rigorous input validation for user-supplied or externally influenced metadata fields that dictate file system operations. When the ZipTransformer processes the message, it directly uses the value from the file_name header to construct the output file path without checking if the resulting path remains within the boundaries of the configured workDirectory. This behavior violates fundamental security principles regarding the separation of data and code execution contexts as well as strict adherence to expected resource locations. The vulnerability is particularly severe because zip files can contain executable scripts or malicious payloads, meaning that writing a crafted archive to an arbitrary location could facilitate further exploitation vectors such as web shell deployment if the path points to a publicly accessible directory, or privilege escalation if it targets system configuration directories.
The operational impact of this vulnerability is significant and varies based on the context in which Spring Integration is deployed. If the application runs with elevated privileges, writing files outside the intended scope can lead to complete compromise of the underlying operating system. Attackers could overwrite critical system binaries, inject malicious code into startup scripts, or disrupt service availability by corrupting essential configuration files. Even if direct execution is not immediately possible, the ability to write arbitrary files allows for data exfiltration preparation, log tampering, or establishing persistence mechanisms on the host machine. In cloud-native environments where multiple tenants might share underlying infrastructure, this vulnerability could potentially lead to cross-tenant contamination if proper isolation boundaries are breached through filesystem manipulation.
This issue aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-436 Interpretation Conflict, as the application fails to properly restrict file operations to the intended directory structure. In terms of attack taxonomy, this vulnerability facilitates actions categorized under MITRE ATT&CK technique T1059 Command and Scripting Interpreter if the written files are executable scripts, or T1105 Ingress Tool Transfer if used to stage additional payloads on the target system. The exploitation requires network-accessible input that influences message headers, placing it within the scope of remote code execution prerequisites depending on the broader application architecture.
To mitigate this vulnerability, organizations must immediately upgrade Spring Integration to a version where this issue has been patched, ensuring they are running 7.1.1 or later for the 7.x branch, and equivalent patch releases for earlier major versions as provided by the project maintainers. For applications that cannot be upgraded instantly, implementing strict input validation on all message headers before they reach the ZipTransformer is essential. Developers should enforce allow-listing of characters permitted in filenames and ensure that any path construction logic explicitly resolves paths to their canonical forms and verifies that the resulting absolute path starts with the configured workDirectory prefix. Additionally, applying principle of least privilege by running Spring Integration processes under restricted user accounts can limit the damage potential if an attacker successfully exploits this flaw. Regular security audits focusing on file system operations and externalized configuration handling are recommended to prevent similar issues in other components of the integration layer.