CVE-2026-3503: wolfSSL Information Disclosure Vulnerability

CVE-2026-3503 Overview

A protection mechanism failure vulnerability exists in wolfCrypt's post-quantum cryptographic implementations (ML-KEM and ML-DSA) within wolfSSL when deployed on ARM Cortex-M microcontrollers. This vulnerability allows a physical attacker with hardware access to compromise key material and cryptographic outcomes by inducing transient faults that corrupt or redirect seed and pointer values during Keccak-based expansion operations.

Critical Impact

Physical attackers can compromise post-quantum cryptographic key material through fault injection attacks, potentially undermining the security guarantees of ML-KEM key encapsulation and ML-DSA digital signatures on embedded systems.

Affected Products

• wolfSSL (wolfCrypt) commit hash d86575c766e6e67ef93545fa69c04d6eb49400c6
• wolfSSL deployments on ARM Cortex-M microcontrollers using ML-KEM implementations
• wolfSSL deployments on ARM Cortex-M microcontrollers using ML-DSA implementations

Discovery Timeline

• 2026-03-19 - CVE CVE-2026-3503 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-3503

Vulnerability Analysis

This vulnerability targets the post-quantum cryptographic implementations in wolfCrypt, specifically affecting the ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) and ML-DSA (Module-Lattice-Based Digital Signature Algorithm) modules. These algorithms are part of the NIST post-quantum cryptography standardization effort, designed to resist attacks from quantum computers.

The flaw resides in the protection mechanisms implemented to safeguard the Keccak-based expansion functions used during key generation and cryptographic operations. ARM Cortex-M microcontrollers, commonly found in IoT devices and embedded systems, are particularly susceptible to physical fault injection attacks such as voltage glitching, electromagnetic fault injection (EMFI), or laser fault injection.

When an attacker induces transient faults during the Keccak permutation or during seed/pointer operations, they can cause the cryptographic implementation to operate on corrupted data or redirect memory accesses to attacker-controlled locations. This can result in the exposure of secret key material or predictable cryptographic outputs that undermine the security of the entire cryptographic scheme.

Root Cause

The root cause is classified as CWE-335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator). The vulnerability stems from insufficient protection against fault injection attacks during the seed expansion phase of the post-quantum algorithms. The Keccak-based expansion function, which derives keying material from initial seeds, lacks adequate countermeasures to detect or prevent corruption of critical seed values and memory pointers when subjected to physical fault injection.

Attack Vector

The attack requires physical access to the target device running wolfSSL on an ARM Cortex-M microcontroller. An attacker must be capable of inducing precise transient faults through techniques such as:

1. Voltage Glitching: Momentarily disrupting the power supply to cause computational errors
2. Electromagnetic Fault Injection (EMFI): Using electromagnetic pulses to corrupt specific memory or register values
3. Laser Fault Injection: Using focused laser beams to flip bits in specific memory locations

During the Keccak-based expansion phase of ML-KEM or ML-DSA operations, the attacker times their fault injection to corrupt seed values or redirect pointers. This can cause the PRNG to produce predictable outputs, leak portions of the secret key through differential fault analysis, or cause the algorithm to use attacker-influenced values in place of legitimate cryptographic material.

The physical access requirement limits the attack surface, but embedded systems in physically accessible locations (IoT devices, smart cards, automotive systems) remain at risk.

Detection Methods for CVE-2026-3503

Indicators of Compromise

• Unexpected cryptographic operation failures or inconsistent outputs from ML-KEM/ML-DSA functions
• Physical evidence of tampering on devices running wolfSSL on ARM Cortex-M platforms
• Anomalous power consumption patterns that may indicate fault injection attempts
• Cryptographic signature verification failures that cannot be attributed to software bugs

Detection Strategies

• Implement hardware-based tamper detection mechanisms to identify physical access attempts
• Monitor for anomalous behavior in cryptographic operations including unexpected timing variations
• Deploy integrity verification for cryptographic outputs using redundant computation
• Utilize secure elements or hardware security modules (HSMs) that provide physical tamper resistance

Monitoring Recommendations

• Enable detailed logging of cryptographic operations to identify patterns indicative of fault injection attacks
• Implement runtime integrity checks for critical memory regions used during post-quantum cryptographic operations
• Consider deploying environmental sensors (voltage, temperature, electromagnetic) to detect fault injection attempts
• Regularly audit physical security controls for devices using wolfSSL in security-critical applications

How to Mitigate CVE-2026-3503

Immediate Actions Required

• Update wolfSSL to a version containing the fix from the wolfSSL Pull Request #9734
• Assess physical security controls for all devices running wolfSSL with post-quantum cryptography on ARM Cortex-M platforms
• Consider temporarily disabling ML-KEM and ML-DSA functionality on devices in physically insecure environments until patching is complete
• Implement additional application-layer verification for cryptographic operations where feasible

Patch Information

A fix has been submitted to the wolfSSL repository addressing this vulnerability. The patch is available in wolfSSL Pull Request #9734. The affected commit is d86575c766e6e67ef93545fa69c04d6eb49400c6. Organizations should update to a wolfSSL version that includes this fix and rebuild their applications.

Workarounds

• Restrict physical access to devices running vulnerable wolfSSL implementations through enhanced physical security measures
• Consider using hardware security modules (HSMs) or secure elements for post-quantum cryptographic operations instead of software implementations
• Implement redundant cryptographic operations with comparison checks to detect fault-induced errors
• Enable compiler-level hardening options and fault detection countermeasures where available in the toolchain

# Configuration example
# Update wolfSSL to patched version
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
git pull origin master
# Verify the fix is included by checking for PR #9734 changes
git log --oneline | grep -i "fault\|keccak\|ML-KEM\|ML-DSA"
# Rebuild with hardening options
./autogen.sh
./configure --enable-hardening --enable-pq
make
make install