UltrafastSecp256k1 CVE-2026-55174

Exploitation requires that the application use UltrafastSecp256k1's ECDSA adaptor-signature feature (ecdsa_adaptor_sign / ecdsa_adaptor_verify) prior to version 4.2.0 and rely on ecdsa_adaptor_verify returning true to mean a pre-signature is genuinely adaptable - e.g. in atomic swaps, discreet log contracts, or payment-channel constructions. The attacker must be the signing counterparty who can craft the pre-signature, substituting an arbitrary r' not bound to adaptor point T and rescaling s_hat = s_hat*(z + r'*x)*(z + r*x)^-1. Limiting factors: no impact against deployments that do not use the adaptor-signature path; the flaw is integrity-only (no data disclosure or crash); AC:H reflects the cryptographic knowledge and protocol positioning needed; and it is fully remediated by upgrading to 4.2.0 or later.

This is a genuine cryptographic soundness flaw but a low real-world priority given the product's obscurity. The vendor CVSS of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) correctly captures an integrity-only impact with no confidentiality or availability effect and elevated attack complexity - consistent with a protocol-level forgery that requires the attacker to act as the signing party and construct a mathematically consistent but unbound pre-signature. No EPSS score, no CISA KEV listing, and no public exploit were supplied; per the precision rules this is 'no public exploit identified at time of analysis.' The commit diff does include a regression test that demonstrates the forgery construction (substituting r' and rescaling s_hat), so the exploit technique is publicly documented in the fix, but that is a defensive test rather than weaponized exploit code and should not be conflated with active exploitation. No SSVC decision data was provided. The signals are internally consistent - there is no CVSS-vs-description conflict here - but note that PR:N reflects that the malicious actor is a legitimate protocol counterparty (the signer) rather than an authenticated user of a victim system; the true limiting factor is that an application must actually use the ECDSA adaptor-signature workflow and trust its verification result.

Two parties run an atomic swap or discreet log contract using this library's ECDSA adaptor signatures. A malicious signer produces a pre-signature with an 'r' value that is not cryptographically bound to the adaptor point T (substituting an arbitrary r' and rescaling s_hat accordingly); the victim's ecdsa_adaptor_verify wrongly accepts it as a valid, adaptable pre-signature, but it cannot actually be adapted into a usable signature, breaking the swap's fairness in the attacker's favor. The forgery construction is documented in the patch's regression test, though no standalone public exploit tool is identified.