RUSTSEC-2026-0312: Excluded iPAddress name constraints with an all-zero mask are not applied

What to do

1. See which version you have: cargo tree -i x509-validator (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p x509-validator. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example x509-validator = "0.3.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

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.

References

• Package: crates.io/crates/x509-validator
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0312.html
• Web: github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.