CVE-2024-9143 in OpenSSL
Summary
by MITRE • 10/16/2024
Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes.
Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low.
In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding.
The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions.
Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/20/2026
This vulnerability resides within the cryptographic library's implementation of binary elliptic curve arithmetic operations, specifically targeting the GF(2^m) field arithmetic APIs. The flaw manifests when applications utilize low-level elliptic curve APIs with untrusted explicit curve parameters that define the field polynomial. The core technical issue involves improper validation of field polynomial coefficients, particularly when the constant term is zero, which creates invalid mathematical representations that can cause memory access violations during computation. The vulnerability operates at the intersection of cryptographic implementation security and memory safety, where the mathematical integrity of elliptic curve operations is compromised by malformed input parameters. This represents a classic buffer over-read and over-write condition that can occur when the library assumes valid field polynomial structures without sufficient validation checks. The affected functions EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and supporting BN_GF2m_*() operations process explicit curve parameters without adequate bounds checking, potentially allowing attackers to manipulate field polynomial representations that result in memory access patterns beyond allocated buffers.
The operational impact of this vulnerability extends beyond simple application crashes to potentially enabling remote code execution under specific conditions. While the likelihood of exploitation is reduced due to the limited use of explicit binary curve parameters in real-world implementations, the vulnerability remains concerning because it can be triggered by applications that do support "exotic" curve encodings. The memory safety implications are severe as out-of-bounds reads and writes can corrupt application memory, leading to unpredictable behavior, denial of service, or more critically, code execution. The vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories, representing a failure to validate input parameters before processing. This type of flaw is particularly dangerous in cryptographic contexts where memory corruption can lead to information disclosure or arbitrary code execution, especially when the vulnerable code path is reachable through network input processing. The ATT&CK framework would categorize this as a software vulnerability exploitation technique, potentially enabling privilege escalation or lateral movement if the vulnerable application has elevated privileges.
The security implications are further complicated by the fact that standard cryptographic protocols like X.509 certificates and TLS implementations typically rely on named curves or X9.62 encoded binary curves that do not permit the problematic zero constant term values. This protective mechanism means that common cryptographic implementations are not affected, but specialized applications using custom or exotic curve parameter formats remain at risk. The vulnerability's exploitation requires specific conditions where applications explicitly accept and process untrusted binary curve parameters that could contain invalid field polynomial representations. The FIPS modules in versions 3.3, 3.2, 3.1, and 3.0 are explicitly excluded from this vulnerability, suggesting that the affected implementations are in non-FIPS compliant code paths or that the FIPS implementations have additional validation layers. Organizations should focus their mitigation efforts on identifying applications that might be using explicit binary curve parameters, particularly those that process custom or untrusted cryptographic inputs, rather than broadly patching all cryptographic libraries. The remediation approach should emphasize parameter validation and input sanitization, ensuring that field polynomial representations meet mathematical requirements before being processed by the vulnerable APIs.