CVE-2026-93304
Wolfssl 4.7.0 – 5.9.2
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/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:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-93304 is a medium-severity Incorrect Behavior Order (CWE-696) vulnerability in Wolfssl Wolfssl. Its CVSS base score is 6.3 (Medium).
Operationally, ranked at the 4th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to RA-5 (Vulnerability Monitoring and Scanning) and SA-11 (Developer Testing and Evaluation) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-87909
Vulnerability Data
A (D)TLS 1.2 client can accept a ChangeCipherSpec message before it has sent its ClientKeyExchange. No master secret has been derived at that point, so the client installs read keys derived from a known (deterministic) key and checks the server's…
more
Finished against that same key. An out-of-order ChangeCipherSpec can therefore be used by an attacker to complete the handshake in place of the server and send data the client accepts as authentic. The client's own traffic still uses correctly derived keys, so the attacker cannot read it, and the genuine server never completes the handshake. DTLS 1.2 clients are exposed because a datagram read can deliver the out-of-order records on its own. TLS 1.2 clients are exposed when the application supplies received bytes with wolfSSL_inject() or enables read ahead. For certificate suites, the attacker must be in a man-in-the-middle position. For PSK (Pre Shared Key) connections, any fake server can succeed without knowing the PSK.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Vulnerability scanning may surface order-related weaknesses after code is built but does not address their root cause.
Developer testing and evaluation at post-design stages can discover incorrect ordering of related behaviors before deployment.
Mandating a documented development process and standards enforces review of behavior ordering within the software lifecycle.
Security and privacy engineering principles applied during design and implementation directly require correct sequencing of operations to avoid introducing order-dependent flaws.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.25 mandates security in the SDLC including secure coding, requirements, checkpoints, testing and developer training that can catch and stop incorrect behavior ordering before it reaches production, but this is only a minority slice of the weakness class (most instances arise from implementation errors not governed by process mandates).
Secure system architecture and engineering principles require proper ordering of design and implementation steps.
Secure coding standards enforce correct execution order of security-critical operations.
Security testing can detect ordering flaws but does not prevent them during development.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.
- No fine-grained STIG row for CWE-696, a class-level weakness, and none of its children carries one either.