CVE-2026-54872 in OpenSSL
Summary
by MITRE • 09/29/2026
Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing.
Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key.
CWE: CWE-208: Observable Timing Discrepancy
Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce.
The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1.
Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue.
The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected.
FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability described constitutes a critical side-channel attack vector within cryptographic libraries, specifically targeting elliptic curve digital signature algorithms such as ECDSA and SM2. The core technical flaw resides in the implementation of generic elliptic-curve scalar multiplication routines that lack dedicated constant-time optimizations for certain curves. When these generic implementations are invoked, they utilize non-constant-time BIGNUM operations to pad the secret scalar value. This architectural decision introduces a timing discrepancy where the execution time of the cryptographic operation becomes dependent on the specific bit pattern and magnitude of the secret scalar derived from the per-signature nonce. Consequently, an adversary capable of performing high-resolution timing measurements can extract minute variations in processing duration that correlate with the internal state of the computation.
This leakage is particularly insidious because it does not result in immediate key compromise but rather provides a statistical advantage to the attacker over time. The information leaked about the secret nonce is subtle and requires a substantial number of signing operations to become statistically significant. Once sufficient timing data has been collected, an attacker can employ lattice-based cryptanalysis techniques or solve the Hidden Number Problem to reconstruct the private signing key from the observed nonces. This type of attack exploits the fundamental requirement that cryptographic implementations must execute in constant time relative to secret inputs to prevent such side-channel analysis. The impact is most pronounced for curves whose group order aligns with machine-word boundaries, such as brainpoolP384r1, where the padding behavior creates more distinct timing signatures compared to other curve configurations.
The operational impact extends primarily to applications utilizing ECDSA or SM2 signing over generic prime curves that do not have specialized hardware or software optimizations for constant-time execution. This includes specific Brainpool curves and potentially others depending on the library version and configuration. It is crucial to distinguish this vulnerability from issues affecting NIST standard curves such as P-256, P-384, and P-521. These widely used standards benefit from dedicated implementations designed specifically for constant-time execution, thereby mitigating the timing leak described here. Furthermore, in environments adhering to FIPS 140-2 or FIPS 140-3 validation requirements, this vulnerability is not present because the approved NIST curves utilized within those modules employ these secure, constant-time implementations and do not fall back to the vulnerable generic code paths.
Mitigation strategies must focus on ensuring that all elliptic curve operations utilize constant-time algorithms regardless of the specific curve parameters. For systems currently relying on affected generic implementations, immediate updates to cryptographic libraries that include patched scalar multiplication routines are necessary. Developers should audit their dependency chains to ensure they are not inadvertently linking against vulnerable versions when using curves like brainpoolP384r1 or other non-NIST prime curves without dedicated optimizations. Additionally, implementing countermeasures such as randomizing the execution time through blinding techniques can provide an additional layer of defense against timing attacks until full code remediation is achieved. Security teams should also consider monitoring for anomalous signing latencies in production environments as a potential indicator of active side-channel probing attempts.
From a classification perspective, this vulnerability aligns with CWE-208: Observable Timing Discrepancy, which categorizes flaws where implementation details allow an attacker to infer secret data through measurement of execution time. In the context of the MITRE ATT&CK framework, this falls under T1539: Steal Web Session Cookie or more broadly under Side Channel Attacks (T1046), specifically targeting cryptographic key extraction rather than session hijacking. The attack vector is classified as Local if timing measurements can be taken from within a local process context, but it may also apply to Remote scenarios where network latency variations are negligible compared to the computational variance introduced by the vulnerability. Understanding these classifications helps in prioritizing remediation efforts and understanding the broader threat landscape associated with cryptographic implementation flaws.