CVE-2024-26308

What it actually does

Apache Commons Compress versions 1.21 through 1.25 allocate resources without sufficient limits while processing certain compressed or archive inputs. When an application uses the vulnerable library to parse attacker-supplied archives, a crafted file can force excessive memory, CPU, or other resource consumption, causing the Java process to become unresponsive, throw OutOfMemoryError, restart, or terminate. The impact is availability-only: the flaw does not directly provide code execution, data theft, or privilege escalation.

Why it matters to the business

Applications, build pipelines, content ingestion services, document processing workflows, and any Java-based systems that accept or process compressed files may be disrupted by a malicious or malformed archive. Successful exploitation can cause service outages, failed uploads or imports, job backlogs, degraded performance, and increased operational load from restarts or incident response. Although this is not listed in CISA KEV and EPSS is low, it has been public for a long time, so exposed archive-processing paths should be treated as a routine but important dependency remediation item.

How an attack unfolds

An attacker first identifies an application feature that processes compressed files using Apache Commons Compress, such as upload, import, backup restore, package scanning, attachment parsing, or CI artifact handling. The attacker then submits a specially crafted archive designed to trigger unbounded resource allocation in vulnerable Commons Compress versions. When the application opens or inspects the archive, the library consumes excessive resources. Depending on service configuration, this can exhaust heap memory, saturate CPU, stall worker threads, crash the Java process, or repeatedly trigger container or service restarts. If the feature is reachable repeatedly, the attacker can sustain denial of service by sending multiple crafted files or resubmitting the same file after the service recovers.

How to fix it

Upgrade Apache Commons Compress to version 1.26 or later. For source builds, ensure the fix containing commit acaf5642b1e16d872870a4dc4618e46ccd349493 is present. Rebuild and redeploy all applications that bundle the vulnerable library, including shaded JARs, fat JARs, application servers, plugins, and container images. If using operating-system packages, apply the vendor-fixed package; for Ubuntu 16.04 LTS wordpress packaging, the listed fixed version is 4.3+dfsg-1. Where immediate upgrade is not possible, reduce exposure by rejecting untrusted archive uploads, enforcing strict file size and decompressed-size limits, using timeouts and memory limits around archive parsing, isolating archive processing in separate worker processes or containers, and rate-limiting upload or import endpoints.

How to confirm the fix worked

Confirm dependency resolution shows Apache Commons Compress 1.26 or later and no vulnerable 1.21-1.25 copies remain. Inspect packaged artifacts for embedded copies, including WEB-INF/lib, BOOT-INF/lib, shaded JARs, container layers, plugin directories, and build caches. Use software composition analysis, Maven or Gradle dependency trees, SBOMs, and runtime classpath inspection to verify the effective version. After remediation, test archive-processing workflows with normal files and controlled malformed inputs to confirm the service rejects or safely handles them without excessive memory growth, worker exhaustion, or process crashes. Validate operational controls such as upload size limits, decompression limits, request timeouts, and container memory limits are active.

Typical attack path

1. Find an application endpoint, job, or workflow that accepts or processes compressed archive files.
2. Confirm or infer that the application uses Apache Commons Compress 1.21 through 1.25, directly or through a dependency.
3. Create or obtain a malformed archive that triggers excessive resource allocation during parsing.
4. Submit the archive through an upload, import, scanning, or processing path that invokes Commons Compress.
5. Cause the Java process or worker handling the archive to consume excessive memory, CPU, or threads.
6. Repeat submissions as needed to maintain application degradation or outage.

How to detect it

Look for signs of denial-of-service attempts against archive-processing workflows rather than data compromise. Relevant sources include application logs, Java exception logs, web access logs for upload/import endpoints, reverse proxy logs, container or orchestration events, JVM metrics, garbage-collection logs, EDR process telemetry, and job queue or worker logs. Focus on time windows with unexplained Java heap exhaustion, repeated service restarts, worker crashes, long-running archive parsing jobs, upload/import failures, or unusually large numbers of compressed-file submissions. Correlate client IPs, user agents, accounts, file names, request paths, and timestamps around events such as OutOfMemoryError, GC overhead limit exceeded, container OOMKilled events, HTTP 500 responses, request timeouts, or sudden drops in worker availability. Because this vulnerability is in a library and exploitation depends on the hosting application, there is no universal network signature; detection should be based on abnormal archive-processing behavior combined with evidence that a vulnerable Commons Compress version was present at the time.

• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• org.apache.commons.compress
• commons-compress-1.21.jar
• commons-compress-1.22.jar
• commons-compress-1.23.jar
• commons-compress-1.24.jar
• commons-compress-1.25.jar
• OOMKilled
• Killed process java
• Container killed due to memory usage
• Exit code 137
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Inventory applications and services that process user-supplied archives or compressed files and identify any use of Apache Commons Compress 1.21 through 1.25.
• Prioritize remediation for internet-facing upload/import features, multi-tenant processing services, CI/CD artifact scanning, email or attachment processing, and automated file ingestion pipelines.
• Upgrade Apache Commons Compress to 1.26 or later, rebuild affected applications, and redeploy container images or packaged artifacts.
• Search for embedded or transitive vulnerable copies in shaded JARs, vendor plugins, and legacy application bundles, not only direct package declarations.
• Implement defense-in-depth limits for archive handling, including maximum upload size, maximum extracted size, entry count limits, processing timeouts, worker isolation, and rate limits.
• Review logs and monitoring for unexplained Java memory exhaustion, process restarts, failed archive processing, and spikes in upload or import errors.
• Add regression tests for malformed archive handling so future dependency or parser changes do not reintroduce unsafe resource consumption.