CVE-2026-5466: Verified Repro With Script Download

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.

The original CVE-2026-5466 vulnerability is a universal signature forgery in wolfSSL’s ECCSI (wc_VerifyEccsiHash) verifier caused by missing scalar range checks on the decoded signature components r and s. The upstream fix (commit 13a016367ff4b4d3cc4c9bc2bfdfe692a512dd81, released in v5.9.1) adds three defenses: (1) a [1, q-1] range check on r immediately after decoding in wc_VerifyEccsiHash; (2) a matching range check on s in eccsi_calc_j after eccsi_decode_sig_s; and (3) a defense-in-depth point-at-infinity guard on j before the final comparison.

This variant analysis systematically tested ten distinct bypass and alternate-trigger scenarios against both the vulnerable (v5.9.0-stable, commit 922d04b3568c6428a9fb905ddee3ef5a68db3108) and fixed (v5.9.1-stable, commit 1d363f3adceba9d1478230ede476a37b0dcdef24) versions. No bypass was found. The fix correctly rejects all tested scalar boundary conditions, malformed encodings, and parser-robustness attempts.

Fix Coverage / Assumptions

The fix assumes that the only code path capable of verifying an ECCSI signature is wc_VerifyEccsiHash (client-side), which internally calls the static helper eccsi_calc_j. The fix enforces the following invariants:

• Invariant 1: After eccsi_decode_sig_r_pvt decodes r from the signature buffer, r must satisfy 1 <= r < q (where q is the curve order). This is checked with mp_iszero(r) and mp_cmp(r, &params->order) != MP_LT.
• Invariant 2: After eccsi_decode_sig_s decodes s, s must satisfy 1 <= s < q. This is checked with mp_iszero(s) and mp_cmp(s, &key->params.order) != MP_LT.
• Invariant 3 (defense-in-depth): The intermediate point j must not be the point at infinity before the final mp_cmp(jx, r) comparison.

The fix explicitly covers:

• wc_VerifyEccsiHash in wolfcrypt/src/eccsi.c
• eccsi_calc_j in wolfcrypt/src/eccsi.c

It does not modify the signing path (wc_SignEccsiHash / eccsi_gen_sig), because the signing loop already re-rolls when s == 0 or s == HE. It also does not modify wc_ValidateEccsiPair or wc_ValidateEccsiPvt, which are key-pair validation routines that do not process attacker-supplied signature buffers.

Variant / Alternate Trigger

Ten distinct variant attempts were executed and logged. None succeeded on the fixed version.

Entry point for all attempts: wc_VerifyEccsiHash in wolfcrypt/src/eccsi.c (lines 2204–2333 in v5.9.0-stable, lines 2204–2348 in v5.9.1-stable).

Key finding: wc_VerifyEccsiHash is the sole ECCSI verification API exposed by wolfSSL. eccsi_calc_j, eccsi_decode_sig_r_pvt, and eccsi_decode_sig_s are all static functions with exactly one caller each inside eccsi.c. Therefore there are no alternate entry points that reach the same verification arithmetic without passing through the new checks.

• Package/Component: wolfSSL wolfcrypt/src/eccsi.c, wc_VerifyEccsiHash
• Affected Versions: < 5.9.1 (tested v5.9.0-stable)
• Fixed Version: 5.9.1-stable (commit 1d363f3adceba9d1478230ede476a37b0dcdef24)
• Risk Level: High for unpatched versions; the patched version is not vulnerable to the tested variants.

Root Cause

The same underlying root cause (missing scalar range validation after mp_read_unsigned_bin) is fully mitigated by the upstream fix. No code path in the fixed version reaches the eccsi_calc_j scalar multiplication or the final mp_cmp(jx, r) comparison without first satisfying:

1. r != 0 and r < q (checked in wc_VerifyEccsiHash)
2. s != 0 and s < q (checked in eccsi_calc_j)
3. j is not the point at infinity (checked before the final comparison)

Reproduction Steps

1. Run bash vuln_variant/reproduction_steps.sh.
2. The script:
   • Builds wolfSSL v5.9.0-stable (vulnerable) and v5.9.1-stable (fixed) with --enable-eccsi --enable-ecc --enable-sha256.
   • Compiles vuln_variant/eccsi_variant.c against each build.
   • Executes the harness against both libraries, capturing output to logs/variant_vulnerable.txt and logs/variant_fixed.txt.
3. Expected outcome: The vulnerable library accepts r=0, s=0 for any message (universal forgery). The fixed library rejects all ten variant attempts with non-zero error codes (MP_ZERO_E, ECC_OUT_OF_RANGE_E, BAD_FUNC_ARG, or ECC_INF_E).

Evidence

• Vulnerable run log: logs/variant_vulnerable.txt
  • Shows *** FORGERY ACCEPTED *** for Tests 1 and 10 (r=0, s=0).
• Fixed run log: logs/variant_fixed.txt
  • Shows all ten tests rejected; no FORGERY ACCEPTED lines.
• Script output: Confirms NO BYPASS: fixed version correctly rejects all variant attempts.

Recommendations / Next Steps

1. No additional fix is required for the ECCSI verification path tested here. The upstream patch is complete for wc_VerifyEccsiHash.
2. Future hardening: Consider centralizing scalar validation for all ECC-based signature schemes (ECCSI, ECDSA, SM2 if applicable) through the existing wc_ecc_check_r_s_range helper rather than inlining checks. This reduces the risk of the same class of bug re-appearing in new schemes.
3. Regression test: Add a unit test in wolfcrypt/test/test.c that explicitly feeds r=0, s=0, r=q, s=q, and r=q+1, s=q+1 into wc_VerifyEccsiHash and asserts rejection, to prevent regression.
4. Documentation: Update the ECCSI header doxygen comments to state that r and s must be in [1, q-1], matching RFC 6507 Section 5.2.2 requirements.

Additional Notes

• Idempotency: vuln_variant/reproduction_steps.sh was executed twice consecutively; both runs produced identical results and exited cleanly with code 1 (no bypass).
• Trust boundary: All tests exercise the attacker-controlled signature buffer path (untrusted input delivered to wc_VerifyEccsiHash). This is the same trust boundary as the original CVE.
• Security policy: wolfSSL’s .github/SECURITY.md does not exclude cryptographic signature verification failures from scope; the fix is in-scope.