CWE-299

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.0-rc.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/notaryproject/notation-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.0-beta.1"
            },
            {
              "fixed": "1.3.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-56138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-13T16:14:07Z",
    "nvd_published_at": "2025-01-13T22:15:14Z",
    "severity": "MODERATE"
  },
  "details": "This issue was identified during Quarkslab\u0027s audit of the timestamp feature.\n\n### Summary\nDuring the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified.\n\n### Details\nDuring timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by `notation`.\n\n### Impact\nThis could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations.\n",
  "id": "GHSA-45v3-38pc-874v",
  "modified": "2025-01-14T21:05:54Z",
  "published": "2025-01-13T16:14:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/notaryproject/notation-go/security/advisories/GHSA-45v3-38pc-874v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56138"
    },
    {
      "type": "WEB",
      "url": "https://github.com/notaryproject/notation-go/commit/e7005a6d13e5ba472d4e166fbb085152f909e102"
    },
    {
      "type": "WEB",
      "url": "https://github.com/notaryproject/notation-go/commit/e99be1954a15673020150c5f8800b8174cd7428d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/notaryproject/notation-go"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3381"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "notation-go\u0027s timestamp signature generation lacks certificate revocation check"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-36057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-21T19:15:28Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics Mobile (iOS) 1.1.0 through 1.1.22 \n\nis vulnerable to authentication bypass by using the Local Authentication Framework library which is not needed as biometric authentication is not used in the application.",
  "id": "GHSA-5j2h-pwp3-258r",
  "modified": "2025-07-21T21:31:37Z",
  "published": "2025-07-21T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36057"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7239635"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-11955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-27T12:15:32Z",
    "severity": "HIGH"
  },
  "details": "Incorrect validation of OCSP certificates vulnerability in TheGreenBow VPN, versions 7.5 and 7.6. During the IKEv2 authentication step, the OCSP-enabled VPN client establishes the tunnel even if it does not receive an OCSP response or if the OCSP response signature is invalid.",
  "id": "GHSA-8cw5-pxrw-vqhc",
  "modified": "2025-10-27T12:32:52Z",
  "published": "2025-10-27T12:32:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11955"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/incorrect-validation-ocsp-certificates-thegreenbow-vpn-client-windows"
    },
    {
      "type": "WEB",
      "url": "https://www.thegreenbow.com/en/support/security-alerts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "app-store-server-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-299"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T23:49:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n`SignedDataVerifier` attempts to perform online revocation checking when `enable_online_checks=True`, but its OCSP validation logic accepts stale `GOOD` responses as valid indefinitely. In `appstoreserverlibrary/signed_data_verifier.py`, `_ChainVerifier.check_ocsp_status()` verifies the OCSP response signature and CertID match, but never validates the freshness window carried by `producedAt`, `thisUpdate`, or `nextUpdate`.\n\nAs a result, a previously valid signed OCSP `GOOD` response can be replayed after it is expired, and the library will still treat the certificate as good. If an App Store signing certificate or intermediate is ever revoked, applications using this library with online checks enabled can continue accepting JWS objects signed with the revoked key as long as a stale signed OCSP response is replayed.",
  "id": "GHSA-8f6j-263m-g72x",
  "modified": "2026-07-13T23:49:14Z",
  "published": "2026-07-13T23:49:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apple/app-store-server-library-python/security/advisories/GHSA-8f6j-263m-g72x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apple/app-store-server-library-python"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apple App Store Server Python Library: SignedDataVerifier accepts stale OCSP GOOD responses and can bypass certificate revocation checks"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/forgekeep/nebula-mesh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:28:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nnebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack\u0027s Nebula enforces certificate revocation ONLY through the `pki.blocklist` list in `config.yml` (no CRL/OCSP). The project\u0027s own code states this: `internal/pki/durations.go:15` \u2014 \"Revocation via the blocklist remains the immediate security control.\"\n\nThe server side is fully implemented (computes per-CA blocklist via `GetBlocklistForCA`, returns it in the agent-updates response, sets `has_updates=true` when non-empty). The agent side was never implemented:\n\n1. The agent decodes the `blocklist` JSON field into `UpdatesResponse.Blocklist` (`internal/agent/poller.go:33`) and then DISCARDS it \u2014 `poll()` applies `CertificatePEM`, `CACertPEM`, `ConfigYAML`, but never references `updates.Blocklist` (`internal/agent/poller.go:300-339`).\n2. The config generator has NO field to emit `pki.blocklist` \u2014 `pkiSection` is only `ca`/`cert`/`key` (`internal/configgen/marshal.go:42-46`) and `GeneratorInput` carries no blocklist (`internal/configgen/generator.go:23-52`). So even the server-rendered `config.yml` shipped via `ConfigYAML` cannot carry it.\n\nResult: a blocked/offboarded/compromised host\u0027s certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime \u2014 up to 30 days for agent hosts (`DefaultAgentCertDuration`) and 365 days for mobile hosts (`DefaultMobileCertDuration`). Blocking a host in the UI/API has no effect on the data plane.\n\n### Affected components\n\n- Agent drops the blocklist: `internal/agent/poller.go:33` (decode target), `internal/agent/poller.go:300-339` (poll() applies cert/CA/config, never the blocklist).\n- Generator cannot emit it: `internal/configgen/marshal.go:42-46` (`pkiSection{CA,Cert,Key}`), `internal/configgen/generator.go:23-52` (`GeneratorInput` has no blocklist), `internal/api/enroll.go:255-330` (`renderHostConfig`, source of shipped ConfigYAML).\n- Server correctly produces/ships it (proves intent): `internal/store/sqlite.go:2034` (`GetBlocklistForCA`), `internal/api/updates.go:182-191` (`resp.Blocklist`), `internal/api/updates.go:277` (`has_updates` set on blocklist change).\n- Dead helper: `internal/pki/blocklist.go` (`Blocklist` type) is never used in non-test code \u2014 no server-side enforcement either.\n\n### Reachability (hop by hop)\n\n1. Operator clicks Block on host B (or B is compromised/offboarded). B\u0027s fingerprint enters the per-CA `blocklist` table.\n2. Every other host A under the same CA polls `GET /api/v1/agent/updates`; server returns `blocklist: [\u003cB-fp\u003e, ...]` and `has_updates=true`.\n3. A\u0027s agent decodes `Blocklist` then discards it; `poll()` has no blocklist branch.\n4. Even on a config re-render, `configgen.Generate` emits `pki: {ca,cert,key}` with no `blocklist` key (proven by PoC).\n5. A\u0027s Nebula daemon has an empty blocklist and accepts handshakes from B\u0027s still-valid cert. B keeps full mesh access.\n\n### Impact\n\nRevocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer\u0027s config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates `host.key`+`host.crt` can run stock slackhq/nebula directly, ignore the agent\u0027s 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.\n\n### Proof of Concept (benign)\n\n`internal/configgen/blocklist_poc_test.go` renders a fully-populated host config and asserts the output contains the `pki` section but NO `blocklist` key:\n\n```\n$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v\n=== RUN   TestPoC_NMESH001_GeneratedConfigOmitsBlocklist\n    CONFIRMED: generated config has a pki section but no blocklist key\n    pki:\n      ca: /etc/nebula/ca.crt\n      cert: /etc/nebula/host.crt\n      key: /etc/nebula/host.key\n    ...\n--- PASS\n```\n\nThe agent half is verifiable by inspection: `poll()` has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.\n\n### Distinctness\n\nNOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix `CheckIssuanceAllowed` is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers \u2014 the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or `pki.blocklist` generation.\n\n### Remediation\n\n1. Add `Blocklist []safeString` to `pkiSection` (yaml `blocklist,omitempty`) and `GeneratorInput`; consider also `pki.disconnect_invalid: true`.\n2. Have the agent apply `updates.Blocklist` by re-rendering/rewriting `config.yml` + SIGHUP (same path as `ConfigYAML`). Simplest: fold the blocklist into the server-rendered `ConfigYAML` so it flows through the existing write path.\n3. Add a regression test asserting a non-empty server blocklist yields a `pki.blocklist` entry in the agent\u0027s written config.yml.",
  "id": "GHSA-cm26-5974-52h8",
  "modified": "2026-07-14T20:28:18Z",
  "published": "2026-07-14T20:28:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-cm26-5974-52h8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/commit/0426e2f224a9b1e2029029bf923c93ed39d21cdb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/forgekeep/nebula-mesh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nebula-mesh: Certificate revocation is never enforced at the mesh"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-9636"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T16:17:05Z",
    "severity": "HIGH"
  },
  "details": "A security issue exists within CompactLogix\u00ae 5380, ControlLogix\u00ae 5580, and EN4 communication modules related to CIP Security certificate revocation handling. The security issue stems from the controller failing to properly reject certificates signed by an intermediate certificate that has been revoked via a Certificate Revocation List (CRL). This could allow a network-based attacker to establish a connection using a certificate that should be untrusted, potentially bypassing CIP Security protections.",
  "id": "GHSA-fvq9-7g3p-r5g2",
  "modified": "2026-07-14T18:31:56Z",
  "published": "2026-07-14T18:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9636"
    },
    {
      "type": "WEB",
      "url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1788.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-16228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-11T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a compromised certificate.",
  "id": "GHSA-g25m-mg72-9v2w",
  "modified": "2023-12-12T21:31:06Z",
  "published": "2022-05-24T17:28:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16228"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
    },
    {
      "type": "WEB",
      "url": "https://www.philips.com/productsecurity"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "sequoia-git"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:28:50Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Before `sq-git` checks if a commit can be authenticated, it first looks for hard revocations.  Because parsing a policy is expensive\nand a project\u0027s policy rarely changes, `sq-git` has an optimization to only check a policy if it hasn\u0027t checked it before.  It does this by maintaining a set of policies that it had already seen keyed on the policy\u0027s hash.  Unfortunately, due to a bug the hash was truncated to be 0 bytes and thus only hard revocations in the target commit were considered.  Normally this is not a problem as hard revocations are not removed from the signing policy.\n\nAn attacker could nevertheless exploit this flaw as follows. Consider Alice and Bob who maintain a project together.  If Bob\u0027s\ncertificate is compromised and Bob issues a hard revocation, Alice can add it to the project\u0027s signing policy.  An attacker who has\naccess to Bob\u0027s key can then create a merge request that strips the hard revocation.  If Alice merges Bob\u0027s merge request, then\nthe latest commit will not carry the hard revocation, and `sq-git` will not see the hard revocation when authenticating that commit or any following commits.\n\nNote: for this attack to be successful, Alice needs to be tricked into merging the malicious MR.  If Alice is reviewing MRs, then she is likely to notice changes to the signing policy.\n\nReported-by: Hassan Sheet",
  "id": "GHSA-g27r-r6ph-vf5r",
  "modified": "2026-05-04T22:28:50Z",
  "published": "2026-05-04T22:28:50Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://gitlab.com/sequoia-pgp/sequoia-git"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/sequoia-pgp/sequoia-git/-/commit/f9c9074bd80023456221f09c3c4ff19957ee9c58"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0109.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "sequoia-git has broken hard revocation handling"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-6899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T09:16:30Z",
    "severity": "MODERATE"
  },
  "details": "Check for certificate revocation only considers the first matching CRL and ignores other valid CRLs of the same CA in the CycloneCrypto cryptographic wrapper of S2OPC library. It might allow connection between an OPC UA client and server using a revoked certificate.",
  "id": "GHSA-j893-vcpr-rgfc",
  "modified": "2026-06-09T09:32:07Z",
  "published": "2026-06-09T09:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6899"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/systerel/S2OPC/-/work_items/1739"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rustls-webpki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.102.0-alpha.0"
            },
            {
              "fixed": "0.103.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rustls-webpki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.104.0-alpha.1"
            },
            {
              "fixed": "0.104.0-alpha.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-299"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T21:51:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL\u0027s `IssuingDistributionPoint` `distributionPoint`, and then the certificate\u0027s subsequent `distributionPoint`s would be ignored.\n\nThe impact was that correct provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.\n\nThis vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)\n\nMore likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.",
  "id": "GHSA-pwjx-qhcg-rvj4",
  "modified": "2026-03-25T19:56:38Z",
  "published": "2026-03-20T21:51:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rustls/webpki"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0049.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webpki: CRLs not considered authoritative by Distribution Point due to faulty matching logic"
}