CVE-2026-48959

What it actually does

The flaw is an algorithmic denial-of-service issue in Perl's IO::Uncompress::Unzip module before version 2.220. When extracting a named entry from an attacker-supplied ZIP archive, fastForward() incorrectly compares the digit length of an offset rather than the offset value itself. This causes the read chunk size to collapse from 16 KiB to 1-19 bytes per iteration, creating a per-byte read loop that scales with the compressed size of the skipped data. A crafted archive can therefore force excessive CPU consumption, potentially up to the non-Zip64 4 GiB archive limit, without requiring authentication or user interaction if the vulnerable processing path is exposed to remote input.

Why it matters to the business

Systems that accept or process ZIP files using vulnerable Perl code can be made slow or unavailable by a single malicious archive. This may disrupt file ingestion pipelines, email or attachment processing, backup/import workflows, malware scanning, document conversion, or any service that extracts specific entries from ZIP files. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is low, it is not listed in CISA KEV, it is not associated with ransomware, and no mature exploit is reported. Organizations should still prioritize remediation where ZIP processing is internet-facing, automated, or part of a business-critical queue because repeated submissions can cause operational backlogs and service degradation.

How an attack unfolds

An attacker identifies an application or service that accepts ZIP archives and uses IO::Uncompress::Unzip to extract a named member via the Name option. The attacker creates a ZIP archive whose structure requires the library to fast-forward over a large compressed region before reaching the requested entry. Because vulnerable versions reduce the effective read size to only a few bytes per loop iteration, the service spends disproportionate CPU time walking through the archive. If the application processes uploads synchronously or with a limited worker pool, repeated malicious submissions can exhaust CPU, tie up workers, delay legitimate jobs, and cause a denial of service. Exploitation does not require code execution, credentials, or a valid archive payload beyond triggering the vulnerable extraction path.

How to fix it

Upgrade IO::Uncompress::Unzip to version 2.220 or later. In Perl distributions this functionality is commonly provided through the IO-Compress package family, so update the relevant Perl module/package from CPAN, the operating system package manager, or the application vendor distribution. Where immediate upgrade is not possible, mitigate by rejecting untrusted ZIP files, limiting archive size and compressed-size ratios, enforcing request and job CPU timeouts, processing archives in isolated worker pools, rate-limiting uploads, disabling named-entry extraction from untrusted archives, and placing file-processing workloads behind queue controls with bounded concurrency. Prefer fail-closed handling for archives that exceed size, time, or member-count thresholds.

How to confirm the fix worked

Confirm that the deployed Perl runtime loads IO::Uncompress::Unzip version 2.220 or later, for example by checking the module version in the same runtime/container used by the application. Review dependency lockfiles, container images, OS packages, and vendored Perl libraries to ensure no older copy is still present. Exercise a representative ZIP extraction workflow after patching and confirm normal processing succeeds. If safe test tooling is available, run a controlled regression test using a large archive that previously caused excessive CPU and verify that processing time no longer scales abnormally. Also validate that upload size limits, job timeouts, queue limits, and rate limits are enforced for untrusted archive processing paths.

Typical attack path

1. Find a web application, API, mail gateway, file processor, or automation workflow that accepts ZIP archives.
2. Determine or assume that the backend extracts a specific named file from the archive using Perl IO::Uncompress::Unzip.
3. Craft a ZIP file that forces a large fast-forward operation before the targeted entry is reached.
4. Submit the archive to the vulnerable service.
5. The vulnerable library enters an inefficient per-byte read loop and consumes excessive CPU.
6. Repeat submissions or parallelize requests to exhaust workers, increase queue latency, or make the service unavailable.

How to detect it

Look for evidence of abnormal resource consumption during ZIP processing rather than reliable payload signatures. Useful sources include web/API upload logs, file-ingestion service logs, batch worker logs, job queue metrics, endpoint process telemetry, container CPU metrics, and application performance monitoring. Investigate spikes in CPU usage by Perl processes or archive-processing workers that correlate with ZIP uploads, long-running extraction jobs, repeated timeouts, worker restarts, or queue buildup. Review recent ZIP submissions around the time of CPU saturation, especially repeated uploads from the same source, unusually large compressed files, archives that target a specific named member, or jobs that spend excessive time before extracting the requested entry. On endpoints, correlate high CPU perl processes with open file handles to temporary uploaded ZIP files. In web environments, search for bursts of POST or multipart upload requests followed by 5xx responses, gateway timeouts, or application-level timeout messages. There are no broadly reliable network or file-content indicators unique to this issue, so detection should focus on behavioral correlation between untrusted ZIP ingestion and CPU/worker exhaustion.

What your security team should do

• Inventory services, batch jobs, containers, and appliances that process ZIP files with Perl or bundled Perl dependencies.
• Prioritize upgrade to IO::Uncompress::Unzip 2.220 or later for internet-facing, unauthenticated, automated, or business-critical ZIP-processing workflows.
• Ask application owners to identify code paths using IO::Uncompress::Unzip->new with the Name option on untrusted archives.
• Add operational guardrails: archive size limits, CPU and wall-clock timeouts, bounded worker concurrency, upload rate limits, and queue backpressure.
• Monitor CPU saturation, worker exhaustion, archive-processing latency, and repeated ZIP upload failures after public disclosure, especially on externally reachable services.
• If patching must be delayed, isolate ZIP processing in low-privilege sandboxed workers so denial of service is contained to a controlled pool.
• Because the vulnerability is not currently in KEV and EPSS is low, use risk-based prioritization, but do not defer remediation for exposed upload or ingestion services.