{"id":"GHSA-39mm-4q6x-3vrx","aliases":["RUSTSEC-2026-0312"],"status":"published","title":"Excluded iPAddress name constraints with an all-zero mask are not applied","description":"An `excluded_subtrees` iPAddress name constraint with an all-zero mask\n(`0.0.0.0/0` or `::/0`) does not restrict iPAddress SANs in certificates issued\nbeneath it. The mask check treated an all-zero mask as matching nothing, when a\n`/0` prefix matches every address of its family, so the exclusion was silently\nignored.\n\nCA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these\nexclusions on every technically constrained sub-CA that may not issue for IP\naddresses. As a result, anyone holding (or having compromised) the key of such\na sub-CA can issue a certificate for an arbitrary IP address, and `Validator`\nwith `RFC5280Policy` and `ServerIdentityPolicy` accepts it for that address. A\n`permitted_subtrees` dNSName entry on the same issuer does not prevent this,\nbecause iPAddress SANs are a different name form.\n\nAll users of `Validator` with `RFC5280Policy` are affected when a chain can\ncontain a name-constrained issuer with an all-zero iPAddress exclusion.\n\nThe issue is fixed in x509-validator 0.3.1 (commit\n[da661f8](https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987)).\nUsers should upgrade to 0.3.1 or later.","severity":{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"high","from":"osv"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2026-09-24T12:00:00Z","modified":"2026-09-28T09:45:02Z","fixes":[{"ecosystem":"crates.io","package":"x509-validator","fixed_in":["0.3.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"crates.io","package":"x509-validator","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.3.1"}]}]}],"references":[{"url":"https://crates.io/crates/x509-validator","tags":["package"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0312.html","tags":["advisory"]},{"url":"https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987","tags":["web"]}],"sources":{"osv":[{"id":"RUSTSEC-2026-0312","title":"Excluded iPAddress name constraints with an all-zero mask are not applied","description":"An `excluded_subtrees` iPAddress name constraint with an all-zero mask\n(`0.0.0.0/0` or `::/0`) does not restrict iPAddress SANs in certificates issued\nbeneath it. The mask check treated an all-zero mask as matching nothing, when a\n`/0` prefix matches every address of its family, so the exclusion was silently\nignored.\n\nCA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these\nexclusions on every technically constrained sub-CA that may not issue for IP\naddresses. As a result, anyone holding (or having compromised) the key of such\na sub-CA can issue a certificate for an arbitrary IP address, and `Validator`\nwith `RFC5280Policy` and `ServerIdentityPolicy` accepts it for that address. A\n`permitted_subtrees` dNSName entry on the same issuer does not prevent this,\nbecause iPAddress SANs are a different name form.\n\nAll users of `Validator` with `RFC5280Policy` are affected when a chain can\ncontain a name-constrained issuer with an all-zero iPAddress exclusion.\n\nThe issue is fixed in x509-validator 0.3.1 (commit\n[da661f8](https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987)).\nUsers should upgrade to 0.3.1 or later.","status":"published","published":"2026-09-24T12:00:00Z","modified":"2026-09-28T09:45:02.969451461Z","cvss":[{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:53:40.430679Z"}]}}