CVE-2026-45190

What it actually does

Net::CIDR::Lite for Perl before version 0.24 improperly validates IP address and CIDR mask strings before parsing them. Inputs with trailing newlines or non-ASCII digit characters can pass validation but be interpreted as a different address or network when parsed. Code that relies on Net::CIDR::Lite find() or bin_find() for allowlist, denylist, routing, tenancy, proxy, or access-control decisions may therefore make incorrect match decisions, allowing an IP address that should be blocked or blocking/missing an address that should be recognized.

Why it matters to the business

Applications that use vulnerable Net::CIDR::Lite versions for IP-based access control may make incorrect authorization decisions. The most important consequence is potential bypass of network-based ACLs, such as administrative interface restrictions, API allowlists, fraud controls, tenant isolation checks, or internal-only protections. Availability and integrity impacts are possible where malformed CIDR entries cause legitimate traffic to be denied or security filtering to behave unpredictably. The vulnerability is not currently in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so remediation should be prioritized based on whether the library is used in security-sensitive IP matching paths.

How an attack unfolds

An attacker first identifies an application or service that uses Net::CIDR::Lite before 0.24 to evaluate IP address or CIDR membership. The attacker then supplies, influences, or benefits from malformed IP/CIDR input that contains parser-confusing characters, such as a trailing newline or non-ASCII digits. Because validation and parsing disagree, the value accepted by the application may be normalized or re-encoded into a different address than the original string represented. When the application calls find() or bin_find(), the malformed value may incorrectly match an allowed range or fail to match a blocked range. If the affected check protects a restricted function, the attacker can reach functionality, routes, or data that should have been denied by the IP ACL.

How to fix it

Upgrade Net::CIDR::Lite to version 0.24 or later wherever it is used. If package-specific fixed versions are not centrally enumerated, inventory Perl dependencies through CPAN metadata, cpanfile, Carton, local::lib, vendor bundles, container images, and OS packaging to identify versions before 0.24. After upgrading, rebuild and redeploy applications or images that vendor the module. As defense in depth, canonicalize and strictly validate IP addresses before passing them to ACL logic: reject embedded control characters, trailing whitespace, non-ASCII digits, Unicode-normalized alternatives, and any value that does not round-trip through a trusted IP parser. Avoid using untrusted headers such as X-Forwarded-For for access control unless they are set and sanitized by a trusted reverse proxy. Where immediate upgrade is not possible, add pre-validation that accepts only expected ASCII IPv4/IPv6 and CIDR syntax and explicitly rejects newline characters and non-ASCII input.

How to confirm the fix worked

Confirm the deployed Net::CIDR::Lite version is 0.24 or later in every runtime and packaged artifact, not only in source repositories. For Perl environments, check installed module versions with commands such as `perl -MNet::CIDR::Lite -e 'print $Net::CIDR::Lite::VERSION, "\n"'` in the same runtime context used by the application. Review dependency lockfiles and container/SBOM outputs for Net::CIDR::Lite versions below 0.24. Add regression tests covering malformed inputs, including CIDR strings with trailing newline characters and IP strings containing non-ASCII digits, and assert that they are rejected or do not produce incorrect find()/bin_find() results. Validate that access-control behavior still works for legitimate IPv4, IPv6, and CIDR entries after the upgrade or mitigation.

Typical attack path

1. Identify a Perl application, proxy component, API gateway, administrative tool, or access-control layer that depends on Net::CIDR::Lite for IP/CIDR matching.
2. Determine whether user-controlled, header-derived, configuration-derived, or upstream-supplied IP/CIDR values are passed into Net::CIDR::Lite validation and matching routines.
3. Craft IP or CIDR strings containing ambiguous characters, especially trailing newline characters or non-ASCII digit characters.
4. Submit the crafted value through the exposed input path or cause it to be stored in an ACL configuration source consumed by the application.
5. Trigger the authorization or filtering decision that calls find() or bin_find().
6. Use the incorrect match or miss result to bypass an IP allowlist, evade an IP blocklist, or cause unintended denial of legitimate traffic.

How to detect it

Detection should focus on evidence that malformed IP or CIDR strings reached access-control code paths before patching. Review application logs, reverse proxy logs, API gateway logs, WAF logs, and authentication/authorization decision logs for IP, CIDR, allowlist, denylist, or ACL fields containing embedded newlines, percent-encoded line breaks, carriage returns, Unicode or non-ASCII digits, unusual whitespace, or strings that differ before and after normalization. Pay particular attention to denied-then-allowed transitions, successful access to IP-restricted administrative or internal endpoints, and requests where the apparent client IP is supplied through forwarding headers rather than the network peer address. If ACL configurations are user-managed or API-driven, audit configuration change history for CIDR entries containing control characters or Unicode characters. Source-code and dependency telemetry can identify exposure but not exploitation; exploitation evidence is most likely to appear as anomalous request parameters, headers, ACL update payloads, or application errors involving IP parsing and matching.

• Net::CIDR::Lite version < 0.24
• Net::CIDR::Lite->new
• ->add("::1\n/128")
• ->find("::1a")
• ->bin_find(
• %0a/
• %0A/
• %0d%0a
• \n/128
• \r/128
• X-Forwarded-For: .*%0a
• X-Real-IP: .*%0a
• Forwarded: .*%0a
• client_ip=.*%0a
• cidr=.*%0a
• allowlist=.*%0a
• denylist=.*%0a

What your security team should do

• Prioritize systems where Net::CIDR::Lite is used for authorization, allowlists, denylist enforcement, administrative interface protection, API access restrictions, fraud controls, or tenant/network isolation.
• Upgrade all uses of Net::CIDR::Lite to version 0.24 or later and redeploy any applications, containers, or packaged appliances that vendor older copies.
• Search source code for Net::CIDR::Lite usage, especially calls to add(), find(), and bin_find(), and determine whether any input can be attacker-controlled or header-derived.
• Add input hardening before IP ACL evaluation: reject control characters, trailing whitespace, Unicode digits, and non-canonical IP/CIDR strings.
• Add automated tests for parser-confusion cases such as trailing newlines in CIDR values and non-ASCII digits in IP addresses.
• Review logs and historical requests for malformed IP/CIDR values if the affected code protected sensitive routes or administrative functions.
• Treat exploitation likelihood as currently low based on the provided EPSS and lack of KEV status, but raise priority for internet-facing or security-control use cases.