Which versions of wolfSSL are affected by CVE-2026-55960?

wolfSSL versions compiled with the HAVE_RPK build option contain a certificate validation bypass that allows attackers to impersonate servers or clients by presenting raw public keys instead of valid…. A patch is available.

How to fix or mitigate CVE-2026-55960?

Within 24 hours: Inventory all systems running wolfSSL and identify which were compiled with HAVE_RPK support (check build configuration or logs). Within 7 days: Apply vendor-released patch to all affected systems; if the non-default RPK feature is not in use, disable HAVE_RPK in the build configuration. Within 30 days: Verify patch deployment across the environment and confirm that any remaining wolfSSL instances have RPK support disabled unless explicitly required.

wolfSSL CVE-2026-55960

Q: What is the CVSS score of CVE-2026-55960?

CVE-2026-55960 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/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. EPSS exploitation probability: 0.2%.

EUVD-2026-39545 HIGH

Improper Certificate Validation (CWE-295)

2026-06-25 wolfSSL

GHSA-58fj-7xwc-45hq

Authentication Bypass Wolfssl

8.2

CVSS 4.0 · Vendor: wolfSSL

Severity by source

Vendor (wolfSSL) PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/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

vuln.today AI

5.9 MEDIUM

Network-reachable authentication bypass with no privileges or interaction (PR:N/UI:N), but AC:H reflects the non-default HAVE_RPK build and un-negotiated-type precondition; impact is integrity-only (I:H, C:N/A:N).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (wolfSSL).

CVSS VectorVendor: wolfSSL

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 25, 2026 - 20:21 vuln.today

Analysis Generated

Jun 25, 2026 - 20:21 vuln.today

DescriptionCVE.org

Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all.

AnalysisAI

Certificate validation bypass in wolfSSL (builds compiled with HAVE_RPK) allows a peer to present an un-negotiated Raw Public Key (RFC 7250) in place of a full X.509 certificate, defeating chain-of-trust validation. Because a raw public key carries no certificate chain, ParseCertRelative() accepts it without performing any trust verification, so an attacker presenting a bare key can impersonate a server (or client) when neither side actually negotiated the RPK certificate type. No public exploit identified at time of analysis and the issue is not in CISA KEV; the high CVSS (8.2, CVSS 4.0) reflects a full authentication/integrity bypass, but exploitation is gated by the non-default HAVE_RPK build option.

Technical ContextAI

wolfSSL is a compact embedded/IoT TLS library; the affected component is its TLS certificate-message processing in src/internal.c. The root cause is CWE-295 (Improper Certificate Validation): RFC 7250 Raw Public Keys allow a peer to send only a SubjectPublicKeyInfo blob instead of an X.509 chain, and RFC 8446/7250 require both sides to explicitly negotiate the server_certificate_type / client_certificate_type extensions before an RPK may be used. wolfSSL only enforced the type match when a count of negotiated RPK types was exactly 1, leaving the no-negotiation case unguarded - so a received raw key (dCert->isRPK) slipped past trust validation, since an RPK has no chain for ParseCertRelative() to verify. The fix defaults the expected certificate type to X.509 (cType = WOLFSSL_CERT_TYPE_X509) whenever nothing was negotiated, compares it against the received server cert type on the client and the selected client cert type on the server, and rejects any mismatch - including an un-negotiated bare key - with UNSUPPORTED_CERTIFICATE. The CPE cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:* identifies the affected product.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the change from wolfSSL pull request https://github.com/wolfSSL/wolfssl/pull/10702 and consult https://www.wolfssl.com/docs/security-vulnerabilities/ for the tagged release that contains it, then upgrade to that version. As an immediate compensating control if you cannot patch, rebuild wolfSSL without HAVE_RPK (omit --enable-all and do not enable RPK) since the vulnerability only affects RPK-enabled builds; the trade-off is loss of RFC 7250 Raw Public Key functionality for any peer that legitimately relies on it. Where RPK must remain enabled, ensure peer authentication is additionally enforced at the application layer (e.g. pin expected server public keys / certificate types) until the patched build is deployed, accepting the operational overhead of explicit pinning. Note the same PR also hardens several adjacent checks (BIO negative-length handling, intermediate-CA keyCertSign enforcement, degenerate PKCS#7 verification, and TLS 1.3 post-handshake-auth certificate requirements), so taking the full patched release is preferable to cherry-picking only the RPK change.