CVE-2026-3503: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-3503 is a protection mechanism failure (fault injection vulnerability) in wolfCrypt's post-quantum cryptographic implementations — specifically ML-KEM (Kyber) and ML-DSA (Dilithium) — within wolfSSL running on ARM Cortex-M microcontrollers. A physical attacker can induce transient faults to corrupt or redirect seed and pointer values during Keccak-based expansion, compromising cryptographic key material and/or cryptographic outcomes. The vulnerability affects wolfSSL (wolfCrypt) versions 5.8.2 through before 5.9.0, specifically tied to commit hash d86575c766e6e67ef93545fa69c04d6eb49400c6. It carries a CVSS v3.1 base score of 5.2 (Medium) and a CVSS v4.0 base score of 4.3 (Medium), reflecting its physical-access requirement (Feedly, GitHub PR #9734, ENISA EUVD).

The root cause is classified as CWE-335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator), reflecting a failure of the protection mechanism in wolfCrypt's post-quantum implementations. During Keccak-based seed expansion used in ML-KEM key generation and ML-DSA signing, an attacker with physical access can induce transient hardware faults (e.g., via voltage glitching or electromagnetic fault injection) that corrupt the private seed buffer or redirect pointer values — such as the y parameter pointer in ML-DSA signing — causing the algorithm to operate on attacker-influenced data. The fix, merged in GitHub PR #9734 on March 6, 2026, introduces fault-hardening measures: ML-KEM uses a separate sigma buffer with copy-verification checks, ML-DSA adds pointer-integrity checks during signing, and SHA-3 widens check variables to prevent overflow, all gated behind the --enable-faultharden compile-time option (GitHub PR #9734, Feedly).

Successful exploitation allows a physical attacker to compromise post-quantum cryptographic key material (high confidentiality impact) and manipulate cryptographic outcomes such as signatures (low integrity impact), with no availability impact. The attack is limited to devices running wolfSSL 5.8.2–5.8.x on ARM Cortex-M microcontrollers, a common embedded/IoT platform, meaning the scope is constrained to systems where an adversary can gain physical access. In high-security embedded deployments — such as hardware security modules, IoT devices, or embedded authentication tokens — compromise of ML-KEM or ML-DSA key material could undermine post-quantum secure communications or authentication schemes (Feedly, ENISA EUVD).

1. Physical Access: Gain physical access to a target ARM Cortex-M microcontroller running wolfSSL versions 5.8.2 through 5.8.x with ML-KEM or ML-DSA enabled.
2. Setup Fault Injection Equipment: Prepare a fault injection platform (e.g., voltage glitching hardware such as ChipWhisperer, or an electromagnetic fault injection probe) capable of inducing transient faults in the target device.
3. Identify Target Operation: Trigger a cryptographic operation on the device that invokes ML-KEM key generation or ML-DSA signing, which internally uses Keccak-based seed expansion.
4. Induce Transient Fault: At the precise moment of Keccak-based seed/pointer processing, inject a fault to corrupt the private seed buffer or redirect the y parameter pointer in ML-DSA signing to attacker-controlled memory.
5. Observe Faulty Output: Collect the faulty cryptographic output (e.g., a faulty signature or derived key material) from the device.
6. Analyze and Recover Key Material: Use differential fault analysis (DFA) or similar techniques on the collected faulty outputs to recover the underlying private key or seed material (GitHub PR #9734, Feedly).

The primary remediation is to upgrade wolfSSL to version 5.9.0 or later, which includes the fault-hardening patch merged on March 6, 2026 (PR #9734). When building wolfSSL, enable the fault-hardening compile-time option (--enable-faultharden) to activate the ML-KEM separate sigma buffer verification, ML-DSA pointer-integrity checks, and SHA-3 hardening. For environments where immediate patching is not feasible, implement physical security controls to prevent unauthorized access to ARM Cortex-M devices running vulnerable wolfSSL versions. High-security deployments should also consider additional hardware-level countermeasures against fault injection attacks (e.g., tamper-detection enclosures) (GitHub PR #9734, Feedly, ENISA EUVD).

The vulnerability was assigned by wolfSSL Inc. and disclosed on March 19, 2026, with the fix already merged into the wolfSSL master branch on March 6, 2026, prior to public disclosure. The ENISA EUVD assigned this a provider urgency of "Amber," indicating moderate concern. No significant public researcher commentary, social media discussion, or major media coverage has been identified beyond standard vulnerability database aggregation (ENISA EUVD, GitHub PR #9734).