Loading story…
wolfSSL fixed two flaws in its hand-optimized ML-KEM-1024 SIMD decapsulation code that can permit near-complete private-key recovery when static ML-KEM keys are reused and an attacker can access a plaintext-checking or decapsulation oracle. CVE-2026-10097 affects AVX2 builds by omitting comparison of the final 32 bytes of a 1,568-byte ciphertext, while CVE-2026-6330 affects ARM64 NEON builds by leaving approximately half the ciphertext unchecked. Researchers reported recovery of 98.0% of secret coefficients with 400 chosen ciphertexts on AVX2 and 98.5% with 600 on NEON; wolfSSL addressed both issues in version 5.9.2.
The defects are implementation failures in wolfSSL’s independently written SIMD Fujisaki–Okamoto ciphertext validation, not a break of ML-KEM or FIPS 203. They add to prior evidence that post-quantum cryptographic deployments remain exposed to implementation-level side channels: the KyberSlash research found secret-dependent timing behavior in several Kyber/ML-KEM implementations, including reference code, that enabled practical secret-key recovery on Raspberry Pi 2 and Arm Cortex-M4 systems. Organizations using wolfSSL should upgrade to 5.9.2 or later, identify long-lived static ML-KEM keys on affected AVX2 or NEON systems, and prioritize rotation of potentially exposed keys; TLS 1.3 deployments using freshly generated ephemeral hybrid ML-KEM keys are not susceptible to this key-recovery attack.
Track how attackers are adapting to this technology.
3 events from the most recent confirmed update back to the earliest known activity.
IACR ePrint posted Bhabani Sankar Das's preprint, “Incomplete Ciphertext Comparison in ML-KEM: From an IND-CCA2 Break to Key Recovery.” It showed that unchecked ciphertext bytes in vulnerable wolfSSL SIMD implementations can enable near-complete recovery of reused static ML-KEM private keys when a plaintext-checking decapsulation oracle is available.
wolfSSL released version 5.9.2 with fixes for incomplete ML-KEM-1024 Fujisaki–Okamoto ciphertext comparisons in its AVX2 and ARM64 NEON code. The defects, tracked as CVE-2026-10097 and CVE-2026-6330, affected applicable builds in versions 5.7.x through 5.9.1.
The KyberSlash paper documented the KyberSlash1 and KyberSlash2 secret-dependent division timing vulnerabilities affecting several Kyber implementations, including the official reference code. The researchers demonstrated practical secret-key recovery on Raspberry Pi 2 and Arm Cortex-M4 platforms, and reported that maintainers patched affected libraries after responsible disclosure.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A public disclosure reported that **wolfSSL** versions `5.7.2` through `5.9.0-stable` contain a flaw in the **ML-DSA-44** signing path that frees a heap buffer holding private signing material without clearing it first. In native ML-DSA builds enabled with `--enable-mldsa` or `--enable-dilithium`, a same-process attacker can recover secret key material from reused heap memory and forge signatures on arbitrary messages. Researcher Abhinav Agarwal demonstrated end-to-end signature forgery on Linux and macOS, with forged signatures accepted by `wc_dilithium_verify_msg()` in compiled `libwolfssl` binaries. wolfSSL confirmed the issue and addressed it through fixes referenced in pull requests **#10100** and **#10113**, with the remediation shipping in **wolfSSL 5.9.1-stable**. The vendor did not assign a CVE and reportedly classified the finding as a bug rather than a vulnerability, even as its broader release advisory warned of multiple cryptographic verification weaknesses affecting certificate validation and signature handling. The disclosure also noted that similar missing-memory-clearing problems had previously been corrected in wolfSSL code paths for Dilithium key generation, Ed25519 signing, and Ed448 signing.
Jun 29, 2026
A newly disclosed vulnerability, **CVE-2026-5194**, affects wolfSSL and can cause ECDSA certificate verification routines to accept digests smaller than required because hash/digest size and OID checks are missing. The flaw is classified as `CWE-295` and weakens certificate-based authentication by reducing the assurance that an ECDSA signature was validated against the proper digest constraints. The issue impacts ECDSA/ECC verification in wolfSSL configurations where **EdDSA** or **ML-DSA** is also enabled, and the risk is greater when the public CA key is known. Public references point to a wolfSSL GitHub pull request as well as MITRE and NVD tracking, while severity data published by Tenable includes CVSS v2, v3, and v4 scoring that describes a network-reachable issue with significant confidentiality and integrity impact in newer versions.
Jun 30, 2026
Two high-severity memory-corruption vulnerabilities were disclosed in widely used TLS-related software components. **CVE-2026-5264** affects wolfSSL and stems from DTLS 1.3 ACK message processing, where a remote attacker can send a crafted ACK packet to trigger a heap buffer overflow. The flaw is classified as `CWE-122` and is network-reachable with low attack complexity and no privileges or user interaction required, raising concern for applications that expose DTLS 1.3 services. A separate flaw, **CVE-2026-5402**, was disclosed in Wireshark’s TLS protocol dissector and affects versions `4.6.0` through `4.6.4`. The vulnerability is also a heap-based buffer overflow (`CWE-122`) and could allow denial of service and possible code execution when malicious traffic is processed, with the CVSS vector indicating high impact to confidentiality, integrity, and availability. Public references point to a wolfSSL GitHub pull request for the DTLS issue and to a GitLab issue and official Wireshark security advisory for the dissector flaw.
Jun 29, 2026