secp256k1-native CVE-2026-63410

Exploitation requires a specific (source, compiler, flags) combination plus a downstream exposure, not a default remote condition: (1) the gem's native C extension must be compiled by an affected toolchain - GCC 14.3.0, 15.1.0, or 15.2.0 at -O2, which extconf.rb appends by default - causing GCC to reconstruct the branchless uint256_select into secret-dependent je/jne jumps; (2) a consumer must call Point#mul or the native scalar_multiply_ct on a secret private key or nonce; and (3) an attacker must be able to observe the timing of that operation, e.g. via an online signing oracle, and collect many repeated measurements for statistical recovery. Limiting factors that reduce realistic risk: builds using GCC ≤12.4.0 (pure bitwise ops) or GCC 13.3.0 (constant-time cmov) are NOT affected; the pure-Ruby path is unaffected and makes no constant-time claim; clang and GCC 16 were untested; version 0.18.0 removes the defect on all tested compilers; and the gem itself exposes no network surface, so network reachability depends entirely on the consuming application.

The input CVSS is 5.9 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - confidentiality-only, high attack complexity, no privileges or user interaction. No EPSS score is provided in the input, there is no CISA KEV listing (KEV=NO), and no confirmed working public exploit is present; the vulnerability was found internally via bare-metal dudect (|t|≈21) rather than an external weaponized PoC. SSVC-style signals are only partially present: the vuln.today decision label is 'this_month' (not act_now/emergency), which aligns with a serious-but-not-urgent cryptographic weakness rather than mass exploitation. The high C:H impact (recovery of a secret private key or nonce) is what drives the score upward, but AC:H and the narrow, consumer-dependent preconditions pull real-world priority down: the flaw only manifests in a binary built by specific GCC versions (14.3.0/15.1.0/15.2.0) at -O2 and only when a consumer calls Point#mul/scalar_multiply_ct on a secret scalar from a timing-observable context. The gem itself ships no network surface; the CVSS AV:N reflects an assumed downstream online signing oracle, so network reachability is consumer-dependent rather than intrinsic - this should be verified against the actual deployment. Net assessment: this is a legitimate cryptographic timing side-channel, not a high-CVSS-but-nonexistent-risk issue, but its practical priority is bounded by a tiny deployment footprint and strict compiler/exposure prerequisites. Missing data to note explicitly: no EPSS and no SSVC automatable/technical-impact fields were supplied, and the vendor itself states the affected-version grouping (only the 0.17.0 select idiom vs. earlier distinct CT issues) is unresolved.

A downstream service uses secp256k1-native - built with GCC 14/15 at the default -O2 - to perform ECDSA-style signing with a secret key or nonce, and exposes an online signing oracle whose response timing an attacker can measure. Because the compiler reconstructed the branchless uint256_select into secret-dependent je/jne jumps in the Montgomery ladder, the attacker submits many signing requests and statistically correlates timing variation with scalar bits, progressively recovering the secret (the classic Brumley-Boneh setting). No confirmed public weaponized exploit exists at time of analysis; the vendor demonstrated the leak internally with dudect (|t|≈21) and ctgrind, and the high attack complexity (AC:H) reflects the large number of timing measurements required.