MediumPublic exploit

wolfSSL ML-KEM-1024 ARM64 NEON Incomplete Ciphertext Comparison

IdentifiersCVE-2026-6330CWE-697

CVE-2026-6330 is an implementation flaw in wolfSSL’s ARM64 NEON ML-KEM-1024 ciphertext-comparison path. An ARM64 assembly instruction error used ins where ext was intended, causing the constant-time comparison used during Fujisaki-Okamoto re-encryption validation to examine only approximately half of the ciphertext. Of the 1,568-byte ML-KEM-1024 ciphertext, 784 bytes can remain unchecked. Consequently, modifications to unchecked ciphertext material may not trigger the mandatory implicit-rejection behavior during decapsulation, violating the intended Fujisaki-Okamoto security construction and weakening IND-CCA2 security. The flaw affects wolfSSL versions 5.7.4 through 5.9.1 in applicable ARM64 NEON builds with ML-KEM enabled.

For your environment

Are you exposed to this one?

Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.

Start free trial

ANALYST BRIEF

Impact, mitigation & remediation

What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.

Impact

What an attacker gets, and what they’ve been doing with it.

An attacker can modify unchecked ciphertext bytes without necessarily causing decapsulation to perform implicit rejection. This creates an IND-CCA2 distinguishing weakness in the affected NEON implementation. Where a static or reused ML-KEM private key is exposed to a suitable plaintext-checking or decapsulation oracle, the unchecked bytes can leak information related to decryption noise that is linearly related to the secret key. Reported research recovered approximately 98.5% of the 2,048 secret coefficients using 600 chosen ciphertexts in an ARM64 NEON test environment, with an estimated total requirement of 100,000 to 1,000,000 decapsulations against one key. The issue does not constitute a mathematical break of ML-KEM or FIPS 203.

Mitigation

If you can’t patch tonight, do this now.

Until an upgrade can be deployed, disable ML-KEM in affected ARM64 NEON wolfSSL builds or prevent use of the vulnerable NEON code path. Avoid static, long-lived, pinned, embedded, or otherwise reused ML-KEM private keys. Restrict untrusted parties’ ability to submit arbitrary ciphertexts for decapsulation and avoid exposing decapsulation outcomes through plaintext-checking or application-level response oracles. Fresh per-session ML-KEM keys reduce private-key recovery risk but do not correct the underlying IND-CCA2 failure.

Remediation

Patch, then assume compromise.

Upgrade wolfSSL to version 5.9.2 or later, which corrects the affected ML-KEM SIMD comparison implementations. Validate the deployed build configuration and architecture after upgrading. Regression testing should mutate ciphertext bytes throughout the full ML-KEM ciphertext, including the final and previously unchecked regions, and confirm that every mutation causes implicit rejection during decapsulation.

PUBLIC EXPLOITS

Exploits

1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.

VALID 1 / 1 TOTALView more in app

ml-kem-key-recoveryMaturityPoCVerified exploit

This repository is a real exploit/research repo for two wolfSSL ML-KEM-1024 vulnerabilities: CVE-2026-10097 (x86-64 AVX2) and CVE-2026-6330 (ARM64 NEON). Its purpose is not remote intrusion in the classic sense, but practical cryptographic key recovery from a vulnerable decapsulation oracle. The core capability is to exploit incomplete ciphertext comparison in wolfSSL’s Fujisaki-Okamoto implicit-rejection logic so that tampered ciphertexts are accepted if modifications fall in unchecked regions. The Python recovery harnesses then vary unchecked compressed v-coefficients, observe oracle output, reconstruct decryption-noise-related measurements, and solve a linear regression problem to recover the secret ML-KEM key coefficients. Repository structure is split into two parallel subtrees: avx2-cve-2026-10097/ and neon-cve-2026-6330/. Each contains README/reproduction docs, a C oracle implementation, a C sweep tool to identify unchecked ciphertext positions, and Python scripts for simulation, validation, and live recovery. The AVX2 subtree is the more complete analytical path, including RECOVERY_ANALYSIS.md and scripts verify_compressed.py, regress_compressed.py, test_harness.py, and live_recover_avx2.py. The NEON subtree mirrors the live attack flow with predict_unchecked.py, regress_neon.py, validate_neon.py, live_recover_neon.py, and a Dockerfile for ARM64/QEMU reproduction. Main exploit behavior: - wolf_oracle.c creates a persistent local ML-KEM-1024 decapsulation oracle using vulnerable wolfSSL code, exports public/private keys for scoring, and accepts ciphertexts over stdin. - sweep_implicit_reject.c and sweep_neon_fo.c confirm which ciphertext bytes are not checked by decapsulation. - live_recover_avx2.py and live_recover_neon.py perform the end-to-end attack by generating ciphertexts, modifying unchecked v-coefficients, querying the oracle repeatedly, deriving regression targets, and solving for the secret key. - regress_compressed.py and regress_neon.py simulate the same recovery offline against kyber-py models. - validate_neon.py is a lighter live validation script for the NEON case. Targeting details extracted from the code/docs: - Product: wolfSSL ML-KEM-1024 implementation before 5.9.2. - AVX2 bug: only bytes 1536-1567 of the 1568-byte ciphertext are unchecked, corresponding to v-coefficients 205-255. - NEON bug: approximately half the ciphertext is unchecked; predicted/validated v-coefficient bands are [52-101], [154-203], and [231-255]. - Reproduction uses pre-fix wolfSSL commit d278da09d. This is operational exploit code rather than mere detection: it includes a working oracle, live attack harnesses, and documented recovery results showing high-percentage or full recovery of ML-KEM secret coefficients under the stated conditions.

007bsdDisclosed Jul 22, 2026pythonclocalnetwork

EXPOSURE SURFACE

Affected products & vendors

Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.

VendorProductType

WolfsslWolfsslapplication

Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.

ACTIVITY FEED

Recent activity

7 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.

7 SOURCESView more in app

postquantumNews

Aug 17, 2026

wolfSSL ML-KEM Key Recovery Bug: What It Means for PQC

A wolfSSL ARM64 NEON assembly flaw in the ML-KEM Fujisaki-Okamoto ciphertext comparison. An erroneous instruction causes roughly half of the ciphertext to go unchecked, creating a chosen-ciphertext oracle that can support near-complete private-key recovery when a static ML-KEM key is reused.

What this page doesn’t show

The version that knows your environment.

This page is what’s public. Mallory adds the parts that aren’t: which of your assets are affected, which adversaries are exploiting it right now, which detections to deploy, and what to do tonight.

Start free trial

Exposure mapping

Query your assets running an affected version, and investigate the blast radius.

Threat actor evidence

Every observed campaign linking this CVE to a named adversary.

Associated malware

Malware families riding this exploit, with evidence and IOCs.

Detection signatures

YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.

Vendor-by-vendor mapping

Cross-references every affected SKU, including bundled OEM variants.

Social activity6

Community discussion across Reddit, Mastodon, and other social sources.

EXTERNAL REFERENCES

MITRE CVE

cve.org · CVE-2026-6330

NVD

nvd.nist.gov/vuln/detail/CVE-2026-6330

MITRE CWE · CWE-697

cwe.mitre.org

Patch

github.com/wolfSSL/wolfssl/pull/10192

Vendor Advisory

wolfssl.com/docs/security-vulnerabilities

wolfSSL ML-KEM-1024 ARM64 NEON Incomplete Ciphertext Comparison

IdentifiersCVE-2026-6330CWE-697