GHSA-39mm-4q6x-3vrx json
Excluded iPAddress name constraints with an all-zero mask are not applied
published last mo. modified last mo. also RUSTSEC-2026-0312
- cvss
- 7.4
- version 3.1, OSV
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
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](https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987)). Users should upgrade to 0.3.1 or later.
Patch / fix
Is GHSA-39mm-4q6x-3vrx in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| OSV | 3.1 | 7.4 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | x509-validator | >=0.0.0-0, <0.3.1 |
0.3.1 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.