Skip to content
Heist/ feed
Back to feed
High

X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring

Type: advisorySources: OSV

X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-11310
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 16:06 UTC · Revision 1

Source evidence

X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring

core-osv · Original source

Published 25 Jun 2026, 19:38 UTC

X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.

osv:CVE-2026-11310
Complete source record
{
  "id": "9749f6dc79a611fb8a8a063e08afc0d4b5537ba18906b74c7093c5a9d2eef77a",
  "url": "https://osv.dev/vulnerability/CVE-2026-11310",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring",
    "summary": "X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.",
    "evidence": "osv:CVE-2026-11310",
    "products": [],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-11310",
      "aliases": [
        "CVE-2026-11310"
      ],
      "metrics": [
        {
          "type": "CVSS_V4",
          "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/wolfssl/wolfssl",
              "type": "GIT",
              "events": [
                {
                  "introduced": "59f4fa568615396fbf381b073b220d1e8d61e4c2"
                },
                {
                  "fixed": "ac01707f552c611fbd135cc723b2682b3e7f80f2"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "range": [
                      {
                        "introduced": "5.8.4"
                      },
                      {
                        "last_affected": "5.9.1"
                      }
                    ],
                    "source": "AFFECTED_FIELD",
                    "strategy": "StandardRange"
                  },
                  {
                    "cpe": "cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*",
                    "range": [
                      {
                        "introduced": "5.8.4"
                      },
                      {
                        "fixed": "5.9.2"
                      }
                    ],
                    "source": "CPE_RANGE"
                  }
                ]
              }
            }
          ],
          "versions": [
            "v5.9.1-stable",
            "v5.9.0-stable",
            "v5.8.4-stable",
            "wolfEntropy2d"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-11310.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:30.289403130Z",
      "provider": "osv",
      "references": [
        "https://www.wolfssl.com/docs/security-vulnerabilities/",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/11xxx/CVE-2026-11310.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-11310",
        "https://github.com/wolfSSL/wolfssl/pull/10674",
        "https://github.com/wolfSSL/wolfssl"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-295"
        ],
        "cna_assigner": "wolfSSL",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/11xxx/CVE-2026-11310.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-11310",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 497127,
  "published_at": "2026-06-25T19:38:19.099+00:00"
}