What is the CVSS score of CVE-2026-49942?

CVE-2026-49942 has a CVSS 3.1 base score of 7.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. EPSS exploitation probability: 0.1%.

Which versions of Net::CIDR::Set are affected by CVE-2026-49942?

A flaw in Net::CIDR::Set (Perl module) could allow attackers to bypass IP-based access controls by submitting specially formatted addresses.

How to fix or mitigate CVE-2026-49942?

24 hours: Audit all systems running Net::CIDR::Set version 0.20 and earlier; identify those using it for access control enforcement. 7 days: Deploy compensating controls including strict input validation to reject non-standard IP formats (Unicode digits, zero-padded notation) at application layer before module processing, and secondary validation against approved network ranges. 30 days: Establish monitoring of vendor advisories; prepare upgrade path for patched versions upon release.

Net::CIDR::Set CVE-2026-49942

EUVD-2026-34299 HIGH

Improper Validation of Unsafe Equivalence in Input (CWE-1289)

2026-06-04 CPANSec

GHSA-fff7-gx98-vr3g

Information Disclosure Suse

7.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.3 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

SUSE

HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Analysis Generated

Jun 04, 2026 - 19:24 vuln.today

CVSS changed

Jun 04, 2026 - 19:22 NVD

7.3 (HIGH)

CVE Published

Jun 04, 2026 - 16:07 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Net::CIDR::Set versions through 0.20 for Perl did not validate network masks.

The mask portion of a network mask could contain Unicode digits such as the Arabic-Indic One (U+0661), or non-digits, which were ignored. This could allow network masks to accept larger networks.

Leading zeros were also accepted, but treated as decimal instead of octal. This could lead to confusion about what networks are acceptable.

AnalysisAI

Improper input validation in the Perl module Net::CIDR::Set through version 0.20 allows attackers to bypass network access controls by submitting network masks containing Unicode digits (e.g., Arabic-Indic numerals like U+0661) or leading zeros that are silently ignored or misinterpreted. The CVSS 7.3 score reflects low-impact compromise across confidentiality, integrity, and availability via the network, with no public exploit identified at time of analysis. Applications using this module for ACL or firewall-like decisions may grant access to wider IP ranges than intended.

Technical ContextAI

Net::CIDR::Set is a Perl CPAN module (distributed by author RRWO, CPE cpe:2.3:a:rrwo:net::cidr::set) that represents and manipulates sets of CIDR network ranges, commonly used in Perl applications for access control, IP allow/deny lists, and routing logic. The flaw maps to CWE-1289 (Improper Validation of Unsafe Equivalence in Input): the module's parser accepted mask portions containing non-ASCII Unicode digit characters or non-digit characters (silently ignoring them), and treated leading-zero masks as decimal rather than octal - both behaviors diverging from RFC and POSIX expectations for IP/CIDR notation. Because the parsed value differs from what a developer or operator visually reads, the canonical set may represent a larger or different network than intended.

RemediationAI

Vendor-released patch: Net::CIDR::Set 0.21 - upgrade via cpanm Net::CIDR::Set@0.21 or equivalent and rebuild any vendored/packaged distributions; see the release changelog at https://metacpan.org/release/RRWO/Net-CIDR-Set-0.21/changes and the oss-security advisory at https://seclists.org/oss-sec/2026/q2/816. Until the upgrade is rolled out, applications that accept user-supplied CIDR strings should pre-validate input with a strict ASCII regex such as /^\d{1,3}(\.\d{1,3}){3}\/\d{1,2}$/ (or the IPv6 equivalent) and reject any string containing non-ASCII codepoints or leading zeros - the trade-off is rejecting legitimate-but-unusual notations like octal-form addresses some legacy tooling emits. Operators should also review existing rule sets generated by vulnerable versions for unintentionally broadened ranges, since stored rulesets remain incorrect even after the library is patched.