Net::CIDR::Lite CVE-2026-45190

The vulnerability is exploitable only when an application directly accepts untrusted CIDR input (IP address or CIDR mask strings) and passes it to Net::CIDR::Lite's add() method or constructor without prior validation. The input must contain either a trailing newline character (\n) or a non-ASCII digit character that the original regex anchors (^/$) fail to reject. The subsequent find() or bin_find() queries must then use an address that differs from the original malformed input but matches the re-encoded version stored internally. No authentication, special privilege level, or non-default configuration is required - the module operates with default settings. However, exploitation is limited to scenarios where the attacker can control input to CIDR functions and where the application trusts the CIDR matching result for an access control decision. Applications that validate input before passing it to the module, or that use Net::CIDR::Lite for non-security-critical address grouping, are not affected. The vulnerability does not exist in patched version 0.24 and later because the \A and \z anchors correctly reject any input with trailing or embedded whitespace.

The CVSS v3.1 score of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L) indicates network-accessible, unauthenticated exploitation with low attack complexity, resulting in integrity (ACL bypass) and availability (incorrect matching) impact but no confidentiality loss. However, the EPSS score of 0.03% (10th percentile) signals very low real-world exploitation probability, which contradicts the CVSS severity. The SSVC framework (Exploitation: none, Automatable: yes, Technical Impact: partial) corroborates this assessment - no active exploitation is known, the attack is automatable, but the technical impact is partial (limited to ACL bypass scope, not full system compromise). The discrepancy between CVSS and EPSS likely reflects that CIDR validation bugs require knowledge of the specific implementation to exploit effectively, and most deployments use this library in non-security-critical contexts or behind other defenses. Organizations using Net::CIDR::Lite as a primary trust boundary for IP filtering (e.g., in firewalls or proxy ACLs) face moderate risk; those using it as a secondary check face minimal risk. The patch is available, and the exploit requires no special conditions beyond an unpatched version. Real priority should be MEDIUM for direct exposure, LOW-MEDIUM for layered environments. The absence of any KEV listing or public POC further reduces urgency despite the CVSS score.

An attacker with the ability to influence CIDR input to a Perl application (e.g., via API parameters, configuration files, or network data) supplies a malformed IPv6 address such as '::1\n/128' (with an embedded newline). The Net::CIDR::Lite validator incorrectly approves this input, but the parser's re-encoding logic converts it to a different address (e.g., '::1a'). The attacker then queries the CIDR list for the re-encoded address using find('::1a'), which unexpectedly returns true, allowing traffic that should be blocked by an IP ACL to pass through.