CVE-2026-19566 in Net::CIDR::Set
Summary
by MITRE • 08/12/2026
Net::CIDR::Set versions before 0.23 for Perl allow memory exhaustion and malformed set ranges via unbounded IPv6 prefix lengths.
The _encode method accepts any prefix length matching `(0|[1-9][0-9]*)` and passes it to _width2bits(), which builds the mask as `'1' x ($width + 8)`, one character per bit. The _inc() method then unpacks the packed mask into a Perl array of one scalar per byte, so the prefix length alone sets the allocation size: `::/100000000` builds a 100 MB string and a 12.5 million element array. The value being tested is parsed, not just the configured ranges: contains() builds a set from its argument, and _guess_coder() tries the IPv4 coder and then the IPv6 coder, so an IPv4-only set expands an oversized IPv6 prefix length before the mixed address width check rejects it.
Any caller that passes untrusted input to contains() or add() can exhaust process memory. A prefix length above 128 is also stored as a range that does not match the requested block: 2001:db8::/129 stringifies back unchanged, contains() of its own base address returns false, and removing it from a set drops the base address while the set still prints as covering it.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability in Net::CIDR::Set versions prior to 0.23 represents a critical memory exhaustion flaw that stems from improper handling of IPv6 prefix lengths within the _encode method. This vulnerability operates through a regex pattern `(0|[1-9][0-9]*)` that accepts arbitrary numeric values for prefix lengths without proper bounds checking, allowing attackers to specify extremely large prefix values that directly translate into massive memory allocations. The technical implementation flaw occurs when _width2bits() constructs a bitmask string using string repetition where `'1' x ($width + 8)` creates exponentially growing memory structures. When combined with the _inc() method's unpacking process that converts these packed masks into Perl arrays with one scalar per byte, even modest prefix lengths can trigger massive memory consumption patterns.
The operational impact of this vulnerability extends beyond simple denial-of-service conditions to include potential system instability and resource exhaustion across multiple processes. The issue affects any caller that accepts untrusted input through contains() or add() methods, making it particularly dangerous in applications that process user-supplied network address data or configuration files containing CIDR notation. Attackers can leverage this vulnerability by providing malformed prefix lengths such as ::/100000000 which generates a 100 megabyte string and a 12.5 million element array, effectively consuming excessive system resources that can crash applications or render systems unresponsive. This memory exhaustion occurs during the parsing phase rather than runtime execution, making detection more challenging as the malicious input doesn't necessarily trigger immediate errors but instead consumes resources progressively.
The vulnerability demonstrates characteristics consistent with CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-129 (Improper Validation of Array Index) while also exhibiting behaviors aligned with ATT&CK technique T1499.1 (Network Denial of Service - Resource Exhaustion) where attackers can exhaust system resources through carefully crafted inputs. The root cause involves inadequate input validation in the _encode method combined with exponential memory growth patterns that bypass normal resource constraints. Additionally, the vulnerability presents a secondary issue where prefix lengths exceeding 128 bits are stored as ranges that don't match their intended blocks, creating logical inconsistencies where 2001:db8::/129 returns false when checking containment of its own base address while still appearing to cover that range in string representations. This inconsistency can lead to security logic failures in applications that depend on accurate CIDR range matching and validation.
Mitigation strategies must focus on implementing strict input validation at the application level by sanitizing prefix length values before they reach the vulnerable methods, establishing maximum allowed prefix lengths for both IPv4 and IPv6 addresses, and ensuring proper bounds checking during parsing operations. System administrators should upgrade to Net::CIDR::Set version 0.23 or later where these issues have been addressed through proper validation of prefix lengths and implementation of reasonable memory allocation limits. Applications processing untrusted CIDR data should also implement rate limiting and resource monitoring to detect unusual memory consumption patterns that might indicate exploitation attempts, while developers should consider implementing defensive programming practices such as maximum string length checks and memory usage thresholds for array operations. The fix implemented in version 0.23 involves proper validation of prefix lengths to prevent unbounded growth in memory allocation while maintaining compatibility with legitimate CIDR notation usage patterns.