EUVD-2026-87911
GHSA-qqgw-76jp-m5f3
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/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
Network-reachable and unauthenticated (PR:N), but AC:H reflects the non-default RPK build requirement plus needing a malicious/on-path server; auth bypass enables MITM so C:H/I:H, no availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
When using RPK (Raw Public Key), the client side of a TLS 1.2, 1.3 and DTLS 1.2 connection could accept an unsolicited server_cert_type=RawPublicKey which allowed a malicious or misbehaving server to bypass authentication. RPK is off by default and only enabled in --enable-rpk OR --enable-all OR --enable-distro AKA HAVE_RPK builds.
AnalysisAI
Authentication bypass in wolfSSL TLS clients built with Raw Public Key (RPK) support allows a malicious or on-path server to force acceptance of an unsolicited server_cert_type=RawPublicKey extension during a TLS 1.2, TLS 1.3, or DTLS 1.2 handshake, causing the client to treat RPK as the negotiated credential form and skip normal certificate-chain verification. Only builds compiled with HAVE_RPK (--enable-rpk, --enable-all, or --enable-distro) are exposed; default builds are unaffected, and exploitation additionally requires the victim to act as the client connecting to the attacker-controlled server (or an on-path injector) with no user interaction, as reflected by PR:N in the vector. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
No credit card · 7-day full trial
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires a wolfSSL build compiled with RPK support (HAVE_RPK via --enable-rpk, --enable-all, or --enable-distro) - off in default builds. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | Signals conflict between raw score and real-world reachability. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Upstream fix available (PR/commit); released patched version not independently confirmed - apply the change set in wolfSSL PR #11009 (https://github.com/wolfSSL/wolfssl/pull/11009) or upgrade to the first wolfSSL release that contains it once published. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: inventory all wolfSSL deployments and determine which are compiled with HAVE_RPK (check build flags for --enable-rpk, --enable-all, or --enable-distro); for any identified, immediately restrict outbound TLS/DTLS connections to known trusted servers and enable logging of certificate negotiation. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL builds that enable the WOLFSSL_TRUST_PEER_CERT macro can be induced to accept a forged clone of a trusted-peer C
Certificate forgery in the wolfSSL client (versions 5.7.2 through 5.9.2) lets a remote attacker who already holds any ce
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today