RUSTSEC-2026-0312 (GHSA-39MM-4Q6X-3VRX)

Vulnerability from osv_rustsec – Published: 2026-09-24 12:00 – Updated: 2026-09-28 09:30 – Source website
VLAI
Summary
Excluded iPAddress name constraints with an all-zero mask are not applied
Details

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.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
References
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "crypto-failure"
        ],
        "cvss": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "x509-validator",
        "purl": "pkg:cargo/x509-validator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "0.3.1"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-39mm-4q6x-3vrx"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "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 \u00a77.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.",
  "id": "RUSTSEC-2026-0312",
  "modified": "2026-09-28T09:30:11Z",
  "published": "2026-09-24T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/x509-validator"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0312.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987"
    }
  ],
  "related": [],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Excluded iPAddress name constraints with an all-zero mask are not applied"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.