Description

The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage. 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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-27T06:17:21.820Z",
  "pubdate": "2026-08-27T06:17:21.820Z",
  "executiveSummary": "The UnZipTransformer component in Spring Integration is susceptible to a denial-of-service (DoS) vulnerability due to improper input validation when processing zip archives.\nThe vulnerability stems from the absence of constraints on both the number of entries and the total size of data within an archive during the decompression process.\nAffected products include Spring Integration versions 7.1.0, 7.0.0 through 7.0.5, 6.5.0 through 6.5.10, and 6.4.0 through 6.4.12.\nAn unauthenticated attacker can exploit this by submitting a maliciously crafted zip archive designed to exhaust the JVM heap memory.\nSuccessful exploitation results in an application-level denial-of-service, rendering the affected service unresponsive or causing it to crash due to OutOfMemoryError exceptions.\nThis represents a significant availability risk for systems utilizing the UnZipTransformer to process untrusted or externally sourced zip files.",
  "technicalDetails": "The vulnerability resides in the UnZipTransformer class, which is responsible for expanding archived data within the Spring Integration framework. The root cause is the lack of resource bound enforcement during the ingestion and decompression phases. Specifically, the component does not implement logic to restrict the maximum number of entries contained within a zip file, nor does it monitor or limit the cumulative size of the decompressed data before or during memory allocation.\nThe exploitation flow begins when an application configured with UnZipTransformer accepts an archive from an external source, such as a file upload, network stream, or message queue. An attacker crafts a zip archive that exploits these missing controls. This can be achieved through 'Zip Bomb' techniques, where a small, highly compressed archive expands to a disproportionately large size, or through high-entry-count archives that force the JVM to instantiate a massive number of object representations in memory.\nWhen the UnZipTransformer processes the malicious payload, it attempts to decompress the contents into memory. Because there are no configurable limits to trigger an early termination of the processing task, the JVM heap memory is rapidly consumed. As the memory utilization approaches the maximum heap capacity, the Garbage Collector (GC) will struggle to reclaim space, leading to prolonged pauses and eventual resource exhaustion.\nThe component's inability to impose constraints acts as a vector for memory pressure. Because the decompression occurs within the context of the application's process, the resulting OutOfMemoryError may lead to the termination of the thread or the entire JVM instance, effectively denying service to all legitimate users of the application. This attack does not require prior authentication or elevated privileges, as it is triggered solely by the submission of the archive to the processing pipeline. The impact is primarily categorized as an availability failure, as the service becomes non-functional until the application is restarted or the malicious task is cleared from the resource queue."
}