{"id":"CVE-2026-11310","aliases":["ALPINE-CVE-2026-11310","DEBIAN-CVE-2026-11310","EUVD-2026-39548","GHSA-h4wh-367g-85gm","JLSEC-2026-697","UBUNTU-CVE-2026-11310"],"status":"published","title":"X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring","description":"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.","severity":{"version":"4.0","score":8.7,"vector":"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00234,"percentile":0.14426,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295"],"published":"2026-06-25T19:38:19Z","modified":"2026-11-03T06:33:01Z","fixes":[{"ecosystem":"Alpine:v3.24","package":"wolfssl","fixed_in":["5.9.2-r0"],"sources":["osv"]},{"ecosystem":"Julia","package":"wolfSSL_jll","fixed_in":["5.9.2+0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.24","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.8.4"},{"fixed":"5.9.2-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.5.4-2","5.5.4-2+deb12u1","5.5.4-2+deb12u2","5.5.4-2+deb12u3","5.5.4-2.1","5.6.4-1","5.6.4-2","5.6.6-1","5.6.6-1.1","5.6.6-1.2","5.6.6-1.3","5.6.6-1.3~exp1","5.7.0-0.1","5.7.0-0.2","5.7.0-0.3","5.7.2-0.1","5.7.2-0.2","5.7.2-0.3","5.7.2-0.4","5.8.2-1","5.8.2-1.1","5.8.2-1.2","5.8.4-1","5.9.0-0.1","5.9.0-0.2","5.9.1-0.1","5.9.2-1"]},{"source":"osv","ecosystem":"Debian:13","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.7.2-0.1","5.7.2-0.1+deb13u1","5.7.2-0.1+deb13u2","5.7.2-0.2","5.7.2-0.3","5.7.2-0.4","5.8.2-1","5.8.2-1.1","5.8.2-1.2","5.8.4-1","5.9.0-0.1","5.9.0-0.2","5.9.1-0.1","5.9.2-1"]},{"source":"osv","ecosystem":"Julia","package":"wolfSSL_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"5.8.4+0"},{"fixed":"5.9.2+0"}]}]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.4.8+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.10.2+dfsg-2","3.12.0+dfsg-1","3.12.2+dfsg-1","3.13.0+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.1.0+dfsg-2","4.2.0+dfsg-1","4.2.0+dfsg-2","4.2.0+dfsg-3","4.3.0+dfsg-2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.6.0-3","5.0.0-1","5.1.1-1","5.2.0-1","5.2.0-2"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.5.4-2","5.5.4-2.1","5.6.4-2","5.6.6-1.2","5.6.6-1.3","5.6.6-1.3build1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.7.2-0.1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.9.1-0.1","5.9.2-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"wolfssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.7.2-0.1","5.8.2-1.2","5.8.4-1","5.9.1-0.1"]}],"products":[{"vendor":"wolfssl","product":"wolfssl"}],"references":[{"url":"https://github.com/wolfSSL/wolfssl/pull/10674","tags":["patch","Issue Tracking","Patch","fix","web","report"]},{"url":"https://www.wolfssl.com/docs/security-vulnerabilities/","tags":["Vendor Advisory","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-11310","tags":["advisory","web"]},{"url":"https://www.wolfssl.com/docs/security-vulnerabilities","tags":["web"]},{"url":"https://github.com/advisories/GHSA-h4wh-367g-85gm","tags":["web"]},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-11310","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/11xxx/CVE-2026-11310.json","tags":["advisory"]},{"url":"https://github.com/wolfSSL/wolfssl","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-11310","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-11310","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-11310","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-11310","title":"X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring","description":"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.","status":"published","published":"2026-06-25T19:38:19.099Z","modified":"2026-06-26T14:02:37.876Z","cvss":[{"version":"4.0","score":8.7,"vector":"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","level":"high","assessor":"cna"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:20:04.463704Z"}],"euvd":[{"id":"EUVD-2026-39548","description":"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.","status":"published","published":"2026-06-25T19:38:19Z","modified":"2026-06-26T14:02:37Z","cvss":[{"version":"4.0","score":8.7,"vector":"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","level":"high"}],"updated_at":"2026-11-02T18:20:24.495602Z"}],"ghsa":[{"id":"GHSA-h4wh-367g-85gm","title":"X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier ...","description":"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.","status":"published","published":"2026-06-25T21:31:31Z","modified":"2026-06-26T21:32:11Z","cvss":[{"version":"4.0","score":8.7,"vector":"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/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","level":"high"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:09:01.878033Z"}],"nvd":[{"id":"CVE-2026-11310","description":"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.","status":"published","published":"2026-06-25T20:17:09.777Z","modified":"2026-06-26T18:54:51.247Z","cvss":[{"version":"4.0","score":8.7,"vector":"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/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","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high","assessor":"primary"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:12:26.045561Z"}],"osv":[{"id":"ALPINE-CVE-2026-11310","description":"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.","status":"published","published":"2026-06-25T20:17:09.777Z","modified":"2026-11-03T06:33:01.403016762Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-03T07:15:53.944853Z"},{"id":"CVE-2026-11310","title":"X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring","description":"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.","status":"published","published":"2026-06-25T19:38:19.099Z","modified":"2026-10-28T02:30:30.28940313Z","cvss":[{"version":"4.0","score":8.7,"vector":"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","level":"high"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:44:56.310988Z"},{"id":"DEBIAN-CVE-2026-11310","description":"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.","status":"published","published":"2026-06-25T20:17:09.777Z","modified":"2026-10-01T03:01:43.642553455Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:45:50.391389Z"},{"id":"JLSEC-2026-697","title":"X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier...","description":"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.","status":"published","published":"2026-07-14T21:41:35.775Z","modified":"2026-07-25T18:24:47.544201121Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"},{"version":"4.0","score":8.7,"vector":"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/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","level":"high"}],"updated_at":"2026-11-02T15:47:19.003546Z"},{"id":"UBUNTU-CVE-2026-11310","description":"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.","status":"published","published":"2026-06-25T20:17:00Z","modified":"2026-10-17T12:58:04.164841747Z","cvss":[{"version":"4.0","score":8.7,"vector":"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","level":"high"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T16:55:59.591851Z"}]}}