The ML-KEM ARM64 NEON ciphertext comparison only compares half of the input

ML-KEM (FIPS 203, the NIST post-quantum KEM formerly known as Kyber) relies on the Fujisaki-Okamoto transform to convert a CPA-secure PKE into an IND-CCA2 KEM. The core trick is *implicit rejection*: on decapsulation the recipient re-encrypts the derived message and does a constant-time, full-length compare against the received ciphertext; on any mismatch the KEM returns a pseudorandom key derived from a secret seed instead of failing. The wolfSSL ARM64 NEON code path only compared roughly the first half of the re-encrypted ciphertext bytes, so mutations in the untested tail were silently accepted as valid.

This is a legitimate cryptographic regression: half the ciphertext is effectively unauthenticated, which breaks the FO transform's chosen-ciphertext hardening. That said, the CVSS C:L/I:L/A:N framing is fair. To turn the flaw into recovered plaintext or key material an attacker needs (a) reuse of a long-lived ML-KEM private key across many decapsulations, (b) an oracle that reveals whether decapsulation *effectively succeeded* (via observable session establishment, key confirmation, or subsequent AEAD success), and (c) the target must be compiled with the NEON backend on ARM64. Vendor MEDIUM (6.3) matches reality — it's a real IND-CCA2 downgrade, not a break-the-ciphertext primitive.

Why this verdict

• Chosen-ciphertext oracle required — attacker needs to observe decapsulation success/failure across many crafted ciphertexts. TLS 1.3 KDF and transcript hashing blind the oracle in the dominant PQ profile.
• Static key reuse required — ephemeral ML-KEM keys (the default in TLS 1.3 hybrid groups and IKEv2) eliminate the attack surface entirely. Only long-lived KEM keypairs (some IoT / VPN / bespoke messaging profiles) are exposed.
• Narrow build target — only wolfSSL ARM64 NEON path. x86_64, generic C, and AVX2 builds compare full ciphertext correctly.
• Role multiplier: identity/PKI role — wolfSSL is used inside some VPN concentrators and embedded IdP/certificate proxies. If one of these reuses a static ML-KEM key, chain outcome is session-key or long-term-key recovery. However, wolfSSL's ML-KEM deployment is still overwhelmingly ephemeral-key TLS 1.3, so the high-value-role installed base share is well below the 1% CRITICAL floor threshold.
• Role multiplier: embedded / IoT typical role — wolfSSL's dominant footprint is embedded devices where TLS handshakes may be volumetrically low and keys sometimes long-lived. Chain succeeds in theory, but query budgets of 10^5+ handshakes against a device are impractical and detectable.
• No amplifier evidence — EPSS 0.0013, no PoC, no KEV, no in-the-wild reports.

Why not higher?

HIGH would require either broad KEM-key-reuse deployments, a demonstrated efficient oracle in a common protocol profile, or active exploitation evidence. None of those exist today: TLS 1.3 and IKEv2 use ephemeral keys, the CCA query budget is enormous, and no PoC or campaign has surfaced.

Why not lower?

LOW / IGNORE is wrong because this is a genuine break of the FO transform's IND-CCA2 property on a real deployed code path, and there are wolfSSL profiles (embedded VPN, some messaging stacks) that DO reuse ML-KEM keys. Anywhere key reuse exists, the vendor's C:L/I:L framing understates the ceiling — full-key recovery is the theoretical endpoint.

1. Disable the ARM64 NEON ML-KEM backend and fall back to generic C — Rebuild wolfSSL with --disable-armasm or unset WOLFSSL_ARMASM_CRYPTO_MLKEM on ARM64 targets until the patched version is deployed. Ship this within the 365-day remediation window; there is no noisgate mitigation SLA for MEDIUM verdicts.
2. Force ephemeral ML-KEM keys in every protocol profile you control — In TLS 1.3, ensure the hybrid group is negotiated per-handshake (default in mainline profiles). In IKEv2 with PQ additional key exchanges, verify KEM keys are not cached across SAs. Ephemeral key use eliminates the oracle entirely.
3. Rate-limit and alert on repeated PQ handshake failures from a single source — The chosen-ciphertext attack needs 10^4–10^6 queries against one key. Standard TLS/IKE handshake anti-abuse (per-IP throttling, cookie challenges, failure-rate alerts) neutralizes the query budget.
4. Inventory static ML-KEM key usage across VPN, messaging, and embedded fleets — Ask each product team: *does this deployment cache or persist an ML-KEM keypair across sessions?* Any 'yes' answer plus wolfSSL ARM64 NEON is your patch-first cohort.

Run this on each wolfSSL-linked host (ARM64 targets in particular). Invoke as sudo ./check_wolfssl_mlkem.sh — needs read access to /usr/lib, /usr/local/lib, and the ability to run wolfssl-config if installed. Reports VULNERABLE if a wolfSSL library on ARM64 is present at a pre-fix version with NEON support compiled in.

#!/usr/bin/env bash
# noisgate: CVE-2026-6330 wolfSSL ML-KEM ARM64 NEON check
set -u
FIXED_MAJOR=5
FIXED_MINOR=8
FIXED_PATCH=0   # adjust to actual patched wolfSSL tag once published

arch=$(uname -m)
if [[ "$arch" != "aarch64" && "$arch" != "arm64" ]]; then
  echo "PATCHED (host arch $arch is not affected — NEON path is ARM64-only)"
  exit 0
fi

found=0
vuln=0
while IFS= read -r lib; do
  found=1
  # Extract version string from the shared object
  ver=$(strings "$lib" 2>/dev/null | grep -Eo 'wolfSSL [0-9]+\.[0-9]+\.[0-9]+' | head -1 | awk '{print $2}')
  if [[ -z "$ver" ]]; then
    echo "UNKNOWN wolfSSL version in $lib"
    continue
  fi
  IFS=. read -r MA MI PA <<< "$ver"
  # Check NEON ML-KEM symbol presence
  if nm -D "$lib" 2>/dev/null | grep -qiE 'mlkem.*neon|kyber.*neon|armasm.*mlkem'; then
    if (( MA < FIXED_MAJOR )) || \
       (( MA == FIXED_MAJOR && MI < FIXED_MINOR )) || \
       (( MA == FIXED_MAJOR && MI == FIXED_MINOR && PA < FIXED_PATCH )); then
      echo "VULNERABLE: $lib wolfSSL $ver (ARM64 NEON ML-KEM present, pre-fix)"
      vuln=1
    else
      echo "PATCHED: $lib wolfSSL $ver"
    fi
  else
    echo "PATCHED: $lib wolfSSL $ver (no NEON ML-KEM symbols)"
  fi
done < <(find /usr/lib /usr/local/lib /opt -name 'libwolfssl*.so*' 2>/dev/null)

if (( found == 0 )); then
  echo "UNKNOWN: no libwolfssl found on standard paths"
  exit 2
fi
exit $(( vuln ))

Sources

1. CVE-2026-6330 (THREATINT)
2. CVE-2026-6330 (TheHackerWire)
3. wolfSSL Security Vulnerabilities advisory index
4. C2SP/CCTV ML-KEM test vector suite
5. NIST FIPS 203 (ML-KEM specification)
6. Failing gracefully: Decryption failures and the FO transform
7. Binding Security of Implicitly-Rejecting KEMs
8. filippo.io — Post-quantum Cryptography for the Go Ecosystem (background on ML-KEM CCA)