EUVD-2026-41541
GHSA-q2wj-rfvr-wf9p
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Over-read bytes are never exposed (C:N, I:N); only realistic effect is a bounded read that can abort the process under a hardened allocator (A:L); reachable network via a consuming app that passes untrusted prefixes, so AV:N/AC:L/PR:N.
Primary rating from Vendor (9b29abf9-4ab0-4765-b253-1875cd9b441e).
CVSS VectorVendor: 9b29abf9-4ab0-4765-b253-1875cd9b441e
Lifecycle Timeline
3DescriptionCVE.org
Net::IP::LPM versions through 1.10 for Perl allow a heap out-of-bounds read via an unbounded prefix length.
add() passes the prefix string to the trie builder addPrefixToTrie() without checking it against the address width.
addPrefixToTrie() then walks the prefix buffer by prefix_length bits, reading prefix[byte] for byte up to prefix_len/8, where prefix is the 4-byte (IPv4) or 16-byte (IPv6) packed address. A prefix length greater than 32 for IPv4 or 128 for IPv6, for example add("1.2.3.4/255", $v) or add("2001:db8::/255", $v), reads past the end of the packed address.
The out-of-bounds read happens during trie construction and is bounded: the prefix length is stored as an unsigned char, so the bit walk reads at most 32 bytes from the start of the packed address, a short distance past the end of the 4-byte or 16-byte buffer. It is detectable under AddressSanitizer, valgrind, or a hardened allocator, where it can abort the process. Lookups and dump() format only the valid address width, so the out-of-bounds bytes are not exposed through the module's API.
AnalysisAI
Out-of-bounds heap read in the Net::IP::LPM Perl module (all versions through 1.10) is triggered when an application passes an oversized CIDR prefix length (e.g. add("1.2.3.4/255") or a /255 IPv6 prefix) to the trie builder, which walks the packed address buffer by the attacker-supplied bit count without validating it against the 32-bit/128-bit address width. The read runs at most ~32 bytes past a 4- or 16-byte buffer and its contents are never returned through the module's API, so real-world impact is limited to a possible process abort under AddressSanitizer, valgrind, or a hardened allocator. No public exploit identified at time of analysis; EPSS is low (0.23%, 13th percentile) and SSVC lists exploitation status as none.
Technical ContextAI
Net::IP::LPM is a CPAN XS/C module implementing Longest Prefix Match lookups over IPv4/IPv6 routing-style prefixes using a bit-trie. The root cause is CWE-125 (Out-of-bounds Read): add() forwards the user-supplied prefix string to the internal addPrefixToTrie(), which iterates prefix_length bits and dereferences prefix[byte] for byte up to prefix_len/8. Because prefix_length is stored as an unsigned char and never bounded to the address family width (32 for IPv4, 128 for IPv6), a value above the width causes the trie walk to index beyond the 4-byte or 16-byte packed address, reading adjacent heap memory during trie construction. The over-read is bounded to at most 32 bytes past the buffer start and the out-of-range bytes influence trie shape only - lookups and dump() format only the valid address width, so leaked bytes are not surfaced.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply the official patch published at https://security.metacpan.org/patches/N/Net-IP-LPM/1.10/CVE-2026-56015-r2.patch, or upgrade to the next Net::IP::LPM release incorporating it once published on CPAN (track the CPAN RT ticket https://rt.cpan.org/Ticket/Display.html?id=179856 and the oss-security thread https://seclists.org/oss-sec/2026/q3/16 for the tagged version). As a compensating control until patched, validate prefix length in your own code before calling add(): reject or clamp any prefix whose numeric suffix exceeds 32 for IPv4 or 128 for IPv6, which fully prevents the over-read with no functional side effects since such prefixes are invalid anyway. Additionally, avoid passing untrusted or user-supplied CIDR strings directly into add(); restrict that path to validated operator-controlled configuration. Running production Perl with a hardened allocator would turn the benign over-read into a crash, so it is not a mitigation here - it converts an info-safe read into a denial-of-service and should not be relied on as a fix.
Same weakness CWE-125 – Out-of-bounds Read
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today