GHSA-39mm-4q6x-3vrx
Excluded iPAddress name constraints with an all-zero mask are not applied
GHSA-39mm-4q6x-3vrx is a high vulnerability (CVSS 7.4) in x509-validator, published September 24, 2026. No source lists public exploit code. Fixed in x509-validator 0.3.1.
- Severity
- 7.4 HighCVSS 3.1, OSV
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
0.3.1x509-validator
Description
An excluded_subtrees iPAddress name constraint with an all-zero mask
(0.0.0.0/0 or ::/0) does not restrict iPAddress SANs in certificates issued
beneath it. The mask check treated an all-zero mask as matching nothing, when a
/0 prefix matches every address of its family, so the exclusion was silently
ignored.
CA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these
exclusions on every technically constrained sub-CA that may not issue for IP
addresses. As a result, anyone holding (or having compromised) the key of such
a sub-CA can issue a certificate for an arbitrary IP address, and Validator
with RFC5280Policy and ServerIdentityPolicy accepts it for that address. A
permitted_subtrees dNSName entry on the same issuer does not prevent this,
because iPAddress SANs are a different name form.
All users of Validator with RFC5280Policy are affected when a chain can
contain a name-constrained issuer with an all-zero iPAddress exclusion.
The issue is fixed in x509-validator 0.3.1 (commit da661f8). Users should upgrade to 0.3.1 or later.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Affected packages
| Package | Affected | Fixed |
|---|---|---|
x509-validatorcrates.io | 0.0.0-0 up to 0.3.1 | 0.3.1 |
What each source reports
OSV Score usedRUSTSEC-2026-0312
Excluded iPAddress name constraints with an all-zero mask are not applied
An excluded_subtrees iPAddress name constraint with an all-zero mask
(0.0.0.0/0 or ::/0) does not restrict iPAddress SANs in certificates issued
beneath it. The mask check treated an all-zero mask as matching nothing, when a
/0 prefix matches every address of its family, so the exclusion was silently
ignored.
CA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these
exclusions on every technically constrained sub-CA that may not issue for IP
addresses. As a result, anyone holding (or having compromised) the key of such
a sub-CA can issue a certificate for an arbitrary IP address, and Validator
with RFC5280Policy and ServerIdentityPolicy accepts it for that address. A
permitted_subtrees dNSName entry on the same issuer does not prevent this,
because iPAddress SANs are a different name form.
All users of Validator with RFC5280Policy are affected when a chain can
contain a name-constrained issuer with an all-zero iPAddress exclusion.
The issue is fixed in x509-validator 0.3.1 (commit da661f8). Users should upgrade to 0.3.1 or later.
- Record
RUSTSEC-2026-0312- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.