CVE-2026-59274

Overview

Spring Integration extends the Spring programming model to support the well-known Enterprise Integration Patterns, providing message channels, endpoints, transformers, and channel adapters that let Spring applications exchange data with external systems over protocols such as HTTP, JMS, AMQP, TCP/UDP, syslog, and the file system.

A Denial of Service (DoS) vulnerability (CVE-2026-59274) has been identified in the UnZipTransformer component of Spring Integration, which allows attackers to submit a small crafted archive whose expansion exhausts the disk space of the transformer work directory in the default configuration, or the JVM heap when the transformer is set to return byte arrays, and takes the application out of service.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects the zip transformer support of Spring Integration.

Details

Module Info

• Product: Spring Integration
• Affected packages: org.springframework.integration:spring-integration-zip
• Affected versions: >= 6.1.0 <= 6.4.12, >= 6.5.0 <= 6.5.10, >= 7.0.0 < 7.0.6, >= 7.1.0 < 7.1.1
• 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 lines 6.2.x, 6.3.x, 6.4.x and 6.5.x
  • OSS Spring Integration 7.0.6 and 7.1.1

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.

The transformer iterates every entry in the supplied archive and extracts it in full, either to disk or into a byte array held in memory, without limiting the number of entries, the size of an individual entry, or the ratio between compressed and uncompressed bytes:

ZipUtil.iterate(inputStream, new ZipEntryCallback() {

    @Override
    public void process(InputStream zipEntryInputStream, ZipEntry zipEntry) throws IOException {
        ...
        if (ZipResultType.FILE.equals(zipResultType)) {
            final File destinationFile = checkPath(messageId, zipEntryName);

            if (zipEntry.isDirectory()) {
                destinationFile.mkdirs(); //NOSONAR false positive
            }
            else {
                mkDirOfAncestorDirectories(destinationFile);
                SpringZipUtils.copy(zipEntryInputStream, destinationFile);
                uncompressedData.put(zipEntryName, destinationFile);
            }
        }
        else if (ZipResultType.BYTE_ARRAY.equals(zipResultType)) {
            if (!zipEntry.isDirectory()) {
                checkPath(messageId, zipEntryName);
                byte[] data = IOUtils.toByteArray(zipEntryInputStream);
                uncompressedData.put(zipEntryName, data);
            }
        }
        ...
    }
    ...
});

The existing checkPath() guard only constrains where an entry lands, not how large it is. In the default file-based mode every entry is streamed straight into the transformer work directory, which sits under the JVM temporary directory unless configured otherwise, so a crafted archive expands onto the filesystem. When the transformer is configured to return byte arrays instead, IOUtils.toByteArray() buffers each entry entirely in memory, and every extracted result is accumulated in the uncompressedData map for the lifetime of the transformation, so a highly compressible or deeply padded archive of a few kilobytes expands into gigabytes. Any flow that unzips content arriving from an untrusted source can be pushed into filesystem or heap exhaustion by a single message.

This vulnerability was introduced in 2023 with Spring Integration 6.1.0.

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:

• Upgrade to a currently supported version of Spring Integration.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Yu Bao from PayPal Cybersecurity Team (finder)