secp256k1-native: Compiler-reconstructed secret-dependent branch in native scalar multiplication
Affects secp256k1-native 0.17.0 before 0.18.0 when built with an affected GCC (14 or 15) at -O2 and used via Point#mul or scalar_multiply_ct on secret keys or nonces. Fixed in 0.18.0.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Fix
- Fixed in 0.18.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
secp256k1-native, a native C secp256k1 implementation for Ruby, is affected when built with certain GCC compilers at optimization level -O2. In those builds, the constant-time scalar multiplication can leak timing information that may allow an attacker who can observe timing to statistically recover secret private key or nonce bits.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
secp256k1-native is a native C secp256k1 implementation for Ruby. In affected native builds, native constant-time scalar multiplication through `Point#mul` or `scalar_multiply_ct` can leak timing information about a secret scalar when compiled by a toolchain that reconstructs branchless selection into a branch. The `Montgomery ladder` uses `uint256_select` with an all-zeros or all-ones mask, but affected GCC builds at `-O2` recover the original condition and emit secret-dependent `je` or `jne` jumps whose timing correlates with scalar bits. This defeats the assumption behind the 0.17.0 `jp_add_internal` infinity-branch fix. A consumer must multiply a secret private key or nonce in a context where an attacker can observe timing; repeated measurements can statistically recover scalar bits. The defect is in the compiled binary, so source review or `ctgrind` on a non-reconstructing toolchain may miss it. GCC 14.3.0, 15.1.0, and 15.2.0 reproduced the branch reconstruction, and `extconf.rb` appends `-O2`. Tested GCC versions through 12.4.0 used bitwise operations and GCC 13.3.0 used constant-time `cmov`; the pure-Ruby path is not affected by this flaw and separately makes no constant-time claim. GCC 16 and clang were untested, and point releases, targets, and flag combinations were not exhaustively bisected. `Earlier pre-0.17.0 versions had different constant-time issues rather than this introduced select idiom.` Version 0.18.0 contains the verified fix. The advisory's broad pre-0.18.0 guidance also covers earlier, different constant-time issues; whether this CVE groups those issues or only the select idiom introduced in 0.17.0 remains unresolved.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- sgbett secp256k1-native
From 0.17.0 · fixed in 0.18.0
References 5
GitHub · sgbett/secp256k1-native
Questions about CVE-2026-63410
What does this mean?
The compiler turns a constant-time select written in the library's scalar multiplication code back into a branch on the secret boolean condition. That branch can make the running time depend on secret scalar bits, so repeated timing measurements can statistically recover key or nonce bits.Source: github.com
Am I affected, and how do I check?
Builds of secp256k1-native from 0.17.0 up to but not including 0.18.0 are affected when the native extension is compiled by GCC 14 or 15 at -O2, which extconf.rb adds by default. Check the installed gem version and the GCC version used to build the extension. The risk applies when Point#mul or scalar_multiply_ct is called on a secret key or nonce.Source: github.com
What should I do about it?
Upgrade to secp256k1-native 0.18.0, which the advisory recommends. Compiling at -O0 or -O1, or with a compiler that does not reconstruct the select, is possible but fragile and not recommended.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data