CVE-2026-3579: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-3579 is a timing side-channel vulnerability in wolfSSL 5.8.4 affecting RISC-V RV32I architectures (without the M multiplication extension). When the M extension is absent, the compiler inserts a __muldi3 subroutine for 64-bit multiplication that executes in variable time depending on operand values, violating the constant-time requirement for cryptographic operations. This affects multiple SP math functions including sp_256_mul_9 and sp_256_sqr_9, potentially exposing sensitive cryptographic material such as private keys. The vulnerability was published on March 19, 2026, and carries a CVSS v3.1 base score of 5.9 (Medium) and a CVSS v4.0 base score of 2.1 (Low) (Feedly, EUVD).

The root cause is classified as CWE-203 (Observable Discrepancy): on RISC-V RV32I targets compiled without the M (multiplication) extension, the GCC runtime library's __muldi3 function — which implements 64-bit integer multiplication — is not constant-time. Its execution time varies based on the values of its operands, creating a measurable timing side-channel. This flaw propagates into wolfSSL's SP (Single Precision) math layer, affecting functions such as sp_256_mul_9 and sp_256_sqr_9 used in elliptic curve cryptography. An attacker capable of making precise timing measurements of cryptographic operations (e.g., TLS handshakes) could statistically recover private key material over many observations. The fix, merged in PR #9855, introduces a constant-time multiplication implementation activated when SP_NO_MUL_INSTRUCTION is defined, and also corrects a non-constant-time comparison in get_entry (wolfSSL PR #9855, Feedly).

Successful exploitation could allow a network-adjacent or remote attacker to recover sensitive cryptographic data — most critically, private keys used in elliptic curve operations (e.g., ECDSA, ECDH) — by analyzing timing differences across many cryptographic operations. The impact is limited to confidentiality (no integrity or availability impact), and exploitation is constrained to systems running wolfSSL 5.8.4 on RISC-V RV32I hardware without the M extension. Exposure of private keys could enable session decryption, impersonation, or further compromise of systems relying on the affected cryptographic primitives (Feedly, EUVD).

1. Target Identification: Identify systems running wolfSSL 5.8.4 on RISC-V RV32I hardware compiled without the M extension (e.g., embedded IoT devices, microcontrollers). These systems will lack hardware multiply instructions and rely on the vulnerable __muldi3 software routine.
2. Timing Oracle Setup: Establish a channel to repeatedly trigger cryptographic operations on the target (e.g., initiating TLS handshakes or ECDH key exchanges) and measure response times with high precision.
3. Data Collection: Collect a large number of timing samples (potentially thousands to millions) for operations involving sp_256_mul_9, sp_256_sqr_9, or related SP math functions, correlating timing variations with known input values.
4. Statistical Analysis: Apply timing analysis techniques (e.g., correlation power analysis adapted for timing, or lattice-based attacks on ECDSA nonces) to the collected timing data to statistically recover bits of the private key.
5. Key Recovery: Reconstruct the full private key from recovered partial information, enabling decryption of past sessions or cryptographic impersonation (wolfSSL PR #9855, Feedly).

The fix was merged into wolfSSL's master branch on March 5, 2026 (PR #9855) and is targeted for release in wolfSSL version 5.9.2. Users should upgrade to wolfSSL 5.9.2 or later once available. The ENISA EUVD entry indicates affected versions are those below 5.9.0. As a workaround, avoid deploying wolfSSL 5.8.4 on RISC-V RV32I targets without the M extension for security-sensitive applications; enabling the M extension (if hardware supports it) eliminates the vulnerable code path. The fix introduces a constant-time __muldi3 implementation activated via the SP_NO_MUL_INSTRUCTION compile-time flag (wolfSSL PR #9855, EUVD).

The vulnerability was self-assigned by wolfSSL and addressed promptly via an internal pull request (PR #9855) merged on March 5, 2026, approximately two weeks before the CVE was published. The fix was also backported to the OpenEmbedded meta-openembedded layer in May 2026, indicating uptake in embedded Linux distributions. No significant broader media coverage or notable researcher commentary beyond the GitHub pull request discussion has been identified (wolfSSL PR #9855).