CVE-2026-5466: wolfSSL: ECCSI universal signature forgery via missing scalar range check

wolfSSL's implementation of ECCSI (RFC 6507 — Elliptic Curve-based Certificateless Signatures for Identity-based Encryption) contains a critical flaw in wc_VerifyEccsiHash where the scalar signature components r and s are decoded from the signature buffer using mp_read_unsigned_bin without validating that they lie in the mathematically required range [1, q-1] (where q is the curve order). When either scalar is zero, the subsequent verification arithmetic collapses to identities that the verifier mistakes for a valid signature. An attacker can craft a forged signature with r = 0, s = 0 (or other trivial constants) that passes verification for any message under any identity without possessing any private key material.

• Package/Component: wolfSSL — wolfcrypt/src/eccsi.c, specifically the wc_VerifyEccsiHash verifier and eccsi_calc_j helper
• Affected Versions: wolfSSL < 5.9.1 (last vulnerable tag: v5.9.0-stable)
• Fixed Version: 5.9.1-stable (commit 13a016367ff4b4d3cc4c9bc2bfdfe692a512dd81)
• Risk Level: High (CVSS 3.1: 8.1, CVSS 4.0: 7.6)
• Consequences: Universal signature forgery — any message can be authenticated as signed by any identity. ECCSI is used in MIKEY-SAKKE, 3GPP MCData/MCVideo, and other identity-based PKI deployments where this flaw effectively nullifies signature security.

Root Cause

The ECCSI verification algorithm (RFC 6507, Section 5.2.2) requires checking that signature scalars r and s are valid non-zero elements less than the curve order q. wolfSSL's wc_VerifyEccsiHash decodes r via eccsi_decode_sig_r_pvt and s via eccsi_decode_sig_s, but proceeds directly to the scalar multiplications and final comparison without range validation.

The arithmetic collapse occurs as follows:

1. With s = 0, the scalar multiplication [s]([HE]G + [r]Y) in eccsi_calc_j evaluates to the point at infinity, whose affine x-coordinate J_x is 0.
2. With r = 0, the final comparison mp_cmp(J_x, r) becomes mp_cmp(0, 0), which returns MP_EQ.
3. The verifier interprets this equality as "signature valid," unconditionally accepting the forgery regardless of the message or identity.

The fix (commit 13a01636) adds three defensive checks:

1. In wc_VerifyEccsiHash: reject r if mp_iszero(r) or mp_cmp(r, &params->order) != MP_LT, returning MP_ZERO_E or ECC_OUT_OF_RANGE_E.
2. In eccsi_calc_j: reject s with the same [1, q-1] range checks after decoding.
3. Defense-in-depth: before the final comparison, reject J if it is the point at infinity using wc_ecc_point_is_at_infinity(j).

Reproduction Steps

The reproduction is fully automated by repro/reproduction_steps.sh, which:

1. Clones the wolfSSL repository (if not already present).
2. Builds vulnerable wolfSSL v5.9.0-stable with --enable-eccsi --enable-ecc --enable-sha256 into /tmp/wolfssl-vuln.
3. Builds fixed wolfSSL v5.9.1-stable with the same flags into /tmp/wolfssl-fixed.
4. Compiles repro/eccsi_forge.c against both libraries.
5. Runs the forgery harness against both versions and captures output to logs/vulnerable_forge.txt and logs/fixed_forge.txt.

The harness (repro/eccsi_forge.c):

1. Generates a valid ECCSI KMS key and identity pair on curve P-256.
2. Signs a real message to obtain a valid 129-byte signature (r | s | PVT).
3. Constructs multiple forged signatures by replacing r and s with:
   • r = 0, s = 0
   • r = q, s = q
   • r = q, s = 0
   • r = q, s = 1
   • r = 2q, s = 2q while keeping the original (valid) PVT point.
4. Calls wc_VerifyEccsiHash with each forged signature against an attacker-chosen message.
5. Also tests r = 0, s = 0 against a completely different, never-signed message.

Expected evidence of reproduction:

• Vulnerable build: at least one forged scalar tuple returns ret=0, verified=1. The harness confirms r=0, s=0 succeeds for both the original message and an unrelated message.
• Fixed build: all forged tuples are rejected. r=0, s=0 returns MP_ZERO_E (-121); r=q, s=q and related out-of-range values return ECC_OUT_OF_RANGE_E (-217).

Evidence

• Vulnerable run log: logs/vulnerable_forge.txt

  • Key excerpt:

    Test: r=0, s=0
      wc_VerifyEccsiHash ret=0, verified=1
      *** FORGERY ACCEPTED ***
    
    Test: r=0, s=0 with DIFFERENT message
      wc_VerifyEccsiHash ret=0, verified=1
      *** FORGERY ACCEPTED ***
    

• Fixed run log: logs/fixed_forge.txt

  • Key excerpt:

    Test: r=0, s=0
      wc_VerifyEccsiHash ret=-121, verified=0
      Forgery rejected (expected)
    
    Test: r=q, s=q
      wc_VerifyEccsiHash ret=-217, verified=0
      Forgery rejected (expected)
    

• Validation verdict: repro/validation_verdict.json contains {"verdict": "confirmed"} because the vulnerable verifier accepted a forgery and the fixed verifier rejected all tested forgeries.

• Environment: Ubuntu-based container, wolfSSL built from source with --enable-eccsi, linked statically, compiled with GCC.

Recommendations / Next Steps

1. Upgrade immediately to wolfSSL >= 5.9.1-stable (or apply commit 13a01636 as a patch). The fix is minimal (35 lines) and only touches wolfcrypt/src/eccsi.c.
2. Validate all ECCSI signatures processed by pre-5.9.1 systems as potentially forged. Because the attack requires no secret material and works universally, any signature received from an untrusted channel before the upgrade is suspect.
3. Regression tests: Ensure CI includes a test case that submits r = 0, s = 0 and r = q, s = q to wc_VerifyEccsiHash and expects failure. This directly exercises the missing checks.
4. Audit other ECCSI implementations in the same codebase (or derived from wolfSSL) for the same missing range checks, especially any custom verifiers that may have been copied from the vulnerable code.

Additional Notes

• Idempotency confirmed: repro/reproduction_steps.sh was executed twice consecutively; both runs produced identical verdicts (confirmed) and the same error codes.
• Edge cases tested: The harness tests not only r=0, s=0 but also boundary cases (r=q, s=q, r=2q, s=2q). Only the zero-scalar case produced a successful universal forgery on the vulnerable build; the others were correctly rejected by the arithmetic or the point-at-infinity handling in the vulnerable code. This confirms the attack surface is specifically the r=0, s=0 path.
• No ASAN / sanitizer required: This is a pure logic bug in the cryptographic protocol; memory safety tools do not detect it. The reproduction demonstrates the actual security failure (universal forgery) rather than a crash or memory corruption.