CVE-2023-42503

What it actually does

Apache Commons Compress versions 1.22 through versions before 1.24.0 can consume excessive CPU while parsing malicious TAR/PAX metadata. The vulnerable code parses high-precision timestamp fields such as atime, ctime, mtime, and LIBARCHIVE.creationtime using Java BigDecimal without sufficient validation. An attacker can place extremely large fractional timestamp values or exponent notation such as 9e9999999 in TAR extended headers, causing parsing operations that should complete quickly to run for minutes or hours. The impact is denial of service through CPU exhaustion in applications that parse attacker-supplied TAR archives using CompressorStreamFactory auto-detection, TarArchiveInputStream, or TarFile.

Why it matters to the business

Systems that accept, scan, import, unpack, or process TAR archives can become slow or unavailable if they process a crafted file. This can disrupt file upload workflows, package ingestion, backup processing, document pipelines, malware scanning, CI/CD artifact handling, or any service that automatically inspects archives. The issue is not known to be in CISA KEV, has low EPSS, and has no listed mature public exploitation, but it remains relevant because Apache Commons Compress is commonly embedded as a dependency inside Java applications and may be present indirectly through other software.

How an attack unfolds

An attacker first identifies an application or service that accepts TAR archives or archive formats auto-detected by Apache Commons Compress. The attacker creates a TAR file containing PAX extended headers with malformed timestamp metadata, for example an atime, ctime, mtime, or LIBARCHIVE.creationtime value with a very long fractional component or an extreme exponent. When the target application parses the archive using affected Apache Commons Compress classes, the library passes the malformed value into BigDecimal. Due to algorithmic complexity in BigDecimal handling of these inputs, parsing consumes excessive CPU for an extended period. Repeated uploads or submissions can tie up worker threads and CPU cores, causing degraded performance or denial of service for legitimate users.

How to fix it

Upgrade Apache Commons Compress to version 1.24.0 or later. For source builds, ensure the fix corresponding to commit e52eabe9c0eb47b436e873ad7cb83fe737164dec is present. Review dependency trees because Commons Compress is often included transitively by other Java components. If immediate upgrade is not possible, mitigate by rejecting untrusted TAR files, disabling archive auto-detection for untrusted inputs, applying strict upload size and processing time limits, isolating archive parsing in a resource-constrained worker, limiting concurrent archive-processing jobs, and validating PAX timestamp headers before parsing. Specifically reject atime, ctime, mtime, and LIBARCHIVE.creationtime values with excessive length, excessive decimal precision, exponent notation, or nonconforming timestamp format.

How to confirm the fix worked

Confirm that deployed applications resolve Apache Commons Compress to version 1.24.0 or later by inspecting Maven, Gradle, SBT, Bazel, vendor, container, and application package dependency outputs. Search for vulnerable versions 1.22 and 1.23.x in software composition analysis results and runtime classpaths. Validate that applications handling TAR files no longer exhibit abnormal CPU usage when processing test archives containing oversized PAX timestamp fields. Confirm that file upload, archive scanning, and ingestion services enforce file size, processing timeout, concurrency, and input validation limits. Where vendor products bundle Commons Compress, verify the vendor advisory or updated package includes the fixed library version or the referenced fix commit.

Typical attack path

1. Find an application, API, scanner, build system, or ingestion workflow that accepts TAR archives or auto-detects archive formats.
2. Create a TAR archive with PAX extended timestamp headers containing extremely large numeric values, long fractional timestamp values, or exponent notation.
3. Submit or upload the crafted archive to the target service.
4. The application parses the TAR file using vulnerable Apache Commons Compress code paths such as CompressorStreamFactory, TarArchiveInputStream, or TarFile.
5. The timestamp field is parsed with Java BigDecimal, causing excessive CPU consumption.
6. Repeat submissions if needed to exhaust worker threads, increase queue latency, or make the service unavailable.

How to detect it

To determine whether this was already exploited, focus on systems that accept or process TAR archives. Review web access logs, API gateway logs, file upload logs, object storage events, archive scanner logs, application logs, and job queue telemetry for TAR submissions followed by unusually long processing times, request timeouts, worker restarts, or CPU spikes. Look for uploaded or quarantined TAR files containing PAX extended headers with timestamp fields atime, ctime, mtime, or LIBARCHIVE.creationtime that contain extremely long decimal fractions or exponent notation. On Java services, review thread dumps and APM traces for threads spending excessive time in java.math.BigDecimal or Apache Commons Compress TAR parsing classes. Correlate repeated archive submissions from the same source, abnormal queue backlogs, and CPU saturation without corresponding increases in normal traffic. If available, inspect retained upload samples using safe offline tooling and avoid opening suspicious archives in production services.

• org.apache.commons.compress.archivers.tar.TarArchiveInputStream
• org.apache.commons.compress.archivers.tar.TarFile
• org.apache.commons.compress.archivers.ArchiveStreamFactory
• org.apache.commons.compress.compressors.CompressorStreamFactory
• java.math.BigDecimal
• LIBARCHIVE.creationtime
• LIBARCHIVE.creationtime=
• atime=
• ctime=
• mtime=
• 9e9999999
• e9999999
• pax_global_header
• PaxHeaders
• ustar

What your security team should do

• Inventory Java applications and vendor products that include Apache Commons Compress, prioritizing internet-facing file upload services, artifact repositories, CI/CD systems, malware scanners, document processing services, and backup/import pipelines.
• Upgrade all affected deployments using Apache Commons Compress 1.22 through pre-1.24.0 releases to version 1.24.0 or later.
• Review transitive dependencies and packaged JARs rather than relying only on direct dependency declarations.
• Add defensive limits around archive processing, including CPU timeouts, worker isolation, queue limits, upload limits, and maximum archive metadata length.
• Add validation or detection for suspicious PAX timestamp headers using atime, ctime, mtime, or LIBARCHIVE.creationtime with extreme numeric length or exponent notation.
• Monitor archive-processing services for sudden CPU saturation, long-running Java threads, request timeouts, and repeated failed or slow TAR parsing events.
• If exploitation is suspected, preserve submitted archive samples, application logs, thread dumps, access logs, and resource utilization telemetry for forensic review.