CVE-2026-48959: Perl IO::Uncompress::Unzip DOS Vulnerability

CVE-2026-48959 Overview

CVE-2026-48959 is a CPU exhaustion vulnerability in the Perl IO::Uncompress::Unzip module in versions before 2.220. The flaw lives in the fastForward() function, which compares the string length of $offset (1 to 19 digits) against the chunk size $c instead of comparing $offset itself. As a result, $c collapses from 16 KiB to between 1 and 19 bytes per iteration, forcing a per-byte read loop. An attacker who supplies a crafted ZIP archive that is then opened with IO::Uncompress::Unzip->new($zip, Name =\\u003e $target) can drive read amplification scaling with the entry's compressed size, up to the non-Zip64 4 GiB cap [CWE-407].

Critical Impact

Processing an attacker-supplied ZIP entry by name forces a per-byte read loop that exhausts CPU and can stall Perl services handling untrusted archives.

Affected Products

• Perl module IO::Uncompress::Unzip versions before 2.220
• Perl distribution IO-Compress (CPAN, maintainer PMQS) prior to release 2.220
• Applications and services invoking IO::Uncompress::Unzip->new($zip, Name =\\u003e $target) on untrusted ZIP input

Discovery Timeline

• 2026-05-27 - CVE-2026-48959 published to NVD
• 2026-05-27 - Disclosure posted to the OpenWall OSS Security list
• 2026-05-27 - Fix released in IO-Compress 2.220 (MetaCPAN Change Log)
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-48959

Vulnerability Analysis

The vulnerability is an algorithmic complexity flaw [CWE-407] in the fastForward() routine of IO::Uncompress::Unzip. The function is intended to skip ahead by $offset bytes within a ZIP stream using chunked reads of up to 16 KiB. Instead of comparing the numeric offset to the chunk size, the code compares length $offset, which is the digit count of the offset value and therefore always between 1 and 19. The chunk size is clamped to that tiny value, so the routine reads the archive one to nineteen bytes at a time. For a multi-gigabyte compressed entry, this transforms a routine seek into hundreds of millions of read calls.

Root Cause

The defect is a misuse of Perl's length operator. length $offset returns the number of characters in the offset's stringified form, not the offset itself. Because $c is then bounded by that string length, the loop variable shrinks to a near-constant tiny value regardless of how far the function must skip. The remediation in the GitHub commit patch replaces the comparison so that the chunk size is bounded by $offset itself, restoring 16 KiB reads.

Attack Vector

Exploitation requires that a target application accept an attacker-controlled ZIP file and extract a named entry using IO::Uncompress::Unzip->new($zip, Name =\\u003e $target). The attacker crafts an archive whose target entry has a large compressed size up to the non-Zip64 4 GiB ceiling. When the victim opens the entry by name, fastForward() enters the degraded per-byte loop, saturating a CPU core for the duration of the read. Repeated submissions can deny service to mail filters, file processors, build pipelines, and any other Perl tooling that ingests untrusted ZIPs.

No verified public proof-of-concept code is referenced in the advisory. See the OpenWall OSS Security post and the GitHub commit patch for the technical fix details.

Detection Methods for CVE-2026-48959

Indicators of Compromise

• Perl processes consuming sustained 100% of a CPU core while a single ZIP archive is being read.
• File handles held open against large ZIP files with extremely slow read progression and minimal disk I/O throughput.
• Application logs showing long-running calls into IO::Uncompress::Unzip->new(...) that fail to return within expected timeouts.

Detection Strategies

• Inventory installed Perl modules and flag any IO-Compress distribution earlier than 2.220 using cpan -D IO::Compress or package manager queries.
• Add timing instrumentation around code paths that invoke IO::Uncompress::Unzip with the Name option and alert on outliers.
• Inspect uploaded ZIP archives for entries whose compressed size approaches the 4 GiB non-Zip64 ceiling before passing them to Perl unzip code.

Monitoring Recommendations

• Monitor per-process CPU time and read() syscall rates on hosts running Perl-based archive handlers.
• Track wall-clock duration of archive extraction jobs and trigger on jobs exceeding a baseline threshold.
• Centralize Perl application logs and alert on repeated submissions of the same large archive from a single source.

How to Mitigate CVE-2026-48959

Immediate Actions Required

• Upgrade IO-Compress to version 2.220 or later on all systems running Perl code that processes untrusted archives.
• Audit application source for calls to IO::Uncompress::Unzip->new($zip, Name =\\u003e ...) against attacker-controlled input.
• Enforce CPU time and wall-clock limits on processes that handle uploaded ZIP files, using ulimit -t or systemd CPUQuota.

Patch Information

The issue is fixed in IO-Compress 2.220. The upstream commit is available as a GitHub commit patch, and release notes are documented in the MetaCPAN Change Log. Install via cpan IO::Compress or through your distribution's Perl package once it ships the updated version.

Workarounds

• Reject ZIP archives whose compressed entry sizes exceed an application-defined limit well below 4 GiB before invoking IO::Uncompress::Unzip.
• Extract entries sequentially using the streaming API rather than seeking to a named entry, which avoids the fastForward() path.
• Run archive processing in sandboxed workers with strict CPU and memory limits so a single malicious file cannot exhaust the host.

# Configuration example: upgrade IO-Compress and enforce CPU limits on the worker
cpan -i IO::Compress
perl -MIO::Compress -e 'print $IO::Compress::VERSION, "\n"'

# systemd unit hardening for a Perl archive worker
# /etc/systemd/system/perl-unzip-worker.service.d/limits.conf
# [Service]
# CPUQuota=50%
# MemoryMax=512M
# TimeoutStartSec=30