CVE-2024-25710

What it actually does

CVE-2024-25710 is an infinite-loop denial-of-service flaw in Apache Commons Compress versions 1.3 through 1.25.0. When vulnerable code attempts to parse a specially crafted compressed archive or archive stream, the parser can enter a loop with no reachable exit condition. This can pin a CPU thread, exhaust worker capacity, and cause the calling application or service to become slow, unresponsive, or unavailable. The flaw does not provide confidentiality or integrity impact by itself; the primary effect is availability loss in software that uses Apache Commons Compress to process untrusted or user-supplied archive content.

Why it matters to the business

Organizations using Apache Commons Compress in applications, build pipelines, document-processing services, malware sandboxes, attachment scanners, or upload workflows may experience service degradation or outages if malformed archives are processed. Although this issue is not listed in CISA KEV, has low EPSS, and has no known mature public exploit signal in the provided data, the library is commonly embedded as a direct or transitive dependency, so exposure can be broader than obvious application inventories indicate.

How an attack unfolds

An attacker identifies an application or workflow that processes archive files using a vulnerable version of Apache Commons Compress. The attacker then submits or causes the system to ingest a malformed archive designed to trigger the infinite-loop condition. Once the vulnerable parser reaches the problematic code path, the processing thread may spin indefinitely or for an excessive period, consuming CPU and tying up application workers. Repeated submissions can amplify the impact, leading to backlog growth, failed requests, degraded upload or scanning functionality, and potential denial of service for dependent systems.

How to fix it

Upgrade Apache Commons Compress to version 1.26.0 or later. For source builds, ensure the dependency includes the upstream fix at commit acaf5642b1e16d872870a4dc4618e46ccd349493 or a later release. Review transitive dependencies in Maven, Gradle, SBT, Ivy, shaded JARs, vendor bundles, and container images because Commons Compress is often embedded indirectly. If using Ubuntu 14.04 LTS packages that include the listed Botan package, apply the fixed package version 1.10.5-1+deb7u1ubuntu0.14.04.1 where relevant, but treat the primary remediation for this CVE as upgrading Apache Commons Compress. If immediate upgrade is not possible, mitigate by restricting archive uploads to trusted users, enforcing strict file size and extraction time limits, isolating archive processing in a resource-constrained worker, applying CPU and wall-clock timeouts, limiting concurrent archive-processing jobs, and rejecting unsupported archive formats.

How to confirm the fix worked

Confirm no deployed application, library bundle, container image, or build artifact contains Apache Commons Compress versions 1.3 through 1.25.0. Validate with dependency tooling such as Maven dependency:tree, Gradle dependencies, SBOM scanners, SCA tools, container image scanners, and direct inspection of packaged JARs for commons-compress version metadata. After upgrading, test archive-processing workflows with normal archives and malformed test cases to verify that processing terminates cleanly, returns controlled errors, and does not produce sustained CPU usage or stuck worker threads. Confirm runtime artifacts load the upgraded library rather than an older shaded or bundled copy.

Typical attack path

1. Find an application, API, background job, CI/CD task, scanner, or ingestion pipeline that accepts compressed archive input.
2. Confirm or infer that the target uses Apache Commons Compress versions 1.3 through 1.25.0 directly or through a bundled dependency.
3. Submit a malformed archive or archive stream that exercises the vulnerable parsing path.
4. Cause one or more worker threads to enter an infinite or effectively unbounded loop while processing the archive.
5. Repeat submissions or target high-volume workflows to consume CPU and worker capacity, resulting in service slowdown or denial of service.

How to detect it

To assess possible prior exploitation, review logs and telemetry for symptoms of archive-processing denial of service rather than relying on a unique exploit signature. Examine application logs, upload/API access logs, web server logs, job queue logs, file-ingestion service logs, EDR process telemetry, JVM metrics, thread dumps, and infrastructure CPU metrics. Look for bursts of archive uploads followed by request timeouts, worker starvation, high sustained CPU, queue backlogs, repeated processing of the same archive, or Java threads stuck inside Apache Commons Compress parsing code. Correlate suspicious archive submissions by source IP, user agent, account, file name, MIME type, file hash, request path, and timestamp. If thread dumps are available from the incident window, search for long-running threads whose stack traces reference org.apache.commons.compress classes. Since no specific public exploitation artifacts or payload signatures are derivable from the provided information, detection should focus on behavioral indicators and affected dependency presence.

What your security team should do

• Prioritize identifying all direct and transitive uses of Apache Commons Compress across applications, build systems, scanning tools, and container images.
• Upgrade Apache Commons Compress to 1.26.0 or later and redeploy affected applications.
• Pay special attention to internet-facing upload, attachment-processing, archive-extraction, and file-ingestion services because local library flaws can become remotely triggerable through server-side parsing.
• Add resource controls around archive processing, including maximum input size, maximum decompressed size, processing timeout, concurrency limits, and worker isolation.
• Search for shaded or repackaged copies of Commons Compress that may not appear in standard dependency manifests.
• Monitor for abnormal CPU saturation, stuck archive-processing threads, request timeouts, and repeated malformed archive submissions.
• Because the issue is not KEV-listed and has low EPSS, treat it as a controlled remediation item unless the vulnerable library is used in exposed upload or ingestion paths, where it should be handled with higher urgency.