CGA-82QX-J63J-44F9: libcrypto3
Unknown
Published Date unknownLast modified Date unknown
Status not reported
The data service did not report a status for this record. Only the available sections are shown.Vulnerability summary
CGA-82QX-J63J-44F9 is a vulnerability in libcrypto3 with no CVSS score yet.
Priority
Insufficient evidence
No CVSS vector published; no exploitation reported by the 5 checked sources
Source freshness unavailable
How is this decided?CVSS score
Not scored
010
No CVSS score recordedEPSS scoreNot scoredRisk metrics not yet published.
KEVNot listedNot listed by any tracked catalog.
RansomwareNot flaggedNo ransomware use recorded.
Public exploits0No public exploits recorded
Advisory lineage
Upstream 0 · Downstream 0 · Related 1Timeline
No timeline events recorded.
Description
No description has been published for this record.
CVSS metrics
Risk metrics not yet published.
EPSS trend
No EPSS score has been published for this record yet.
Known exploited
Compare KEV catalogs
CISA KEVNot in the CISA KEV catalog.
ENISA CNWNot in the ENISA CNW catalog.
CIRCLNot in the CIRCL catalog.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeNo weakness data has been published for this record.
Affected systems
Version check
Known conditions: not stated in public data.
Chainguard26 products
- libcrypto3< 3.1.0-r5
- libssl3< 3.1.0-r5
- openssl< 3.1.0-r5
- openssl-config< 3.1.0-r5
- openssl-dbg< 3.1.0-r5
- openssl-dev< 3.1.0-r5
- openssl-doc< 3.1.0-r5
- openssl-engine-afalg< 3.1.0-r5
- openssl-engine-capi< 3.1.0-r5
- openssl-engine-loader-attic< 3.1.0-r5
- openssl-engine-padlock< 3.1.0-r5
- openssl-provider-fips< 3.0.9-r1
- openssl-provider-legacy< 3.1.0-r5
- ruby-3.0All versions (No fix recorded)
- ruby-3.0-devAll versions (No fix recorded)
- ruby-3.0-docAll versions (No fix recorded)
- ruby-3.1All versions (No fix recorded)
- ruby-3.1-baseAll versions (No fix recorded)
- ruby-3.1-base-devAll versions (No fix recorded)
- ruby-3.1-devAll versions (No fix recorded)
- ruby-3.1-docAll versions (No fix recorded)
- ruby-3.2All versions (No fix recorded)
- ruby-3.2-baseAll versions (No fix recorded)
- ruby-3.2-base-devAll versions (No fix recorded)
- ruby-3.2-devAll versions (No fix recorded)
- ruby-3.2-docAll versions (No fix recorded)
Wolfi25 products
- libcrypto3< 3.1.0-r5
- libssl3< 3.1.0-r5
- openssl< 3.1.0-r5
- openssl-config< 3.1.0-r5
- openssl-dbg< 3.1.0-r5
- openssl-dev< 3.1.0-r5
- openssl-doc< 3.1.0-r5
- openssl-engine-afalg< 3.1.0-r5
- openssl-engine-capi< 3.1.0-r5
- openssl-engine-loader-attic< 3.1.0-r5
- openssl-engine-padlock< 3.1.0-r5
- openssl-provider-legacy< 3.1.0-r5
- ruby-3.0All versions (No fix recorded)
- ruby-3.0-devAll versions (No fix recorded)
- ruby-3.0-docAll versions (No fix recorded)
- ruby-3.1All versions (No fix recorded)
- ruby-3.1-baseAll versions (No fix recorded)
- ruby-3.1-base-devAll versions (No fix recorded)
- ruby-3.1-devAll versions (No fix recorded)
- ruby-3.1-docAll versions (No fix recorded)
- ruby-3.2All versions (No fix recorded)
- ruby-3.2-baseAll versions (No fix recorded)
- ruby-3.2-base-devAll versions (No fix recorded)
- ruby-3.2-devAll versions (No fix recorded)
- ruby-3.2-docAll versions (No fix recorded)
2 vendors · 51 products
References
0 linksNo references have been published for this record.
Related vulnerabilities
PrioritiseCVE-2026-14456openssl +36 moreUnbounded Memory Growth in QUIC Server Incoming Channel QueueIssue summary: When an OpenSSL QUIC server (Listener SSL object) processes
valid QUIC Initial packets for unknown destination connection IDs, it
can allocate and queue new incoming channels without enforcing any limit.
Impact summary: A remote peer that can make many Initial packets reach the
server listener faster than the application accepts connections, can cause the
memory allocated to store the per-channel state to grow without any limits,
potentially making the QUIC listener unavailable and causing Denial of Service.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The function that handles inbound QUIC packets uses
Connection-Id from the packet header to find an existing connection
(QUIC channel). If no existing connection is found and the packet
type is INITIAL, the function treats the packet as a new connection. It
allocates a new channel object and inserts it into a queue where it
waits to be accepted by the local application with SSL_accept(3ossl).
The memory occupied by these initial channel objects may grow
without bounds if the application is not able to call SSL_accept()
frequently enough to serve these inbound connection requests.
The issue is present since OpenSSL 3.5 when the QUIC server implementation
was added.
The fix introduces a limit for pending connections. The default limit is set
to 256 pending connections (waiting to be accepted by the local application).
Applications may change the default by calling SSL_set_value_uint(3ossl).
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.CVSS7.5HighEPSS0.73%PrioritiseCVE-2026-54876openssl +32 moreClient-Side Memory Leak in OCSP Response CheckingIssue summary: A malicious TLS server can cause a memory leak in a TLS
client that has enabled OCSP response checking by sending an OCSP
response that contains no single response entries.
Impact summary: An attacker can leak an attacker-tunable amount of memory
per TLS handshake in a victim client application. A long-running client
that repeatedly connects to a malicious server can have its memory
exhausted, resulting in a Denial of Service.
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Description: The affected function is called during X.509 certificate
chain verification when OCSP response checking is enabled
with the X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL
verification flags, for example when a TLS client verifies an OCSP
response stapled into the TLS handshake by the server.
When the received BasicOCSPResponse contains an empty SEQUENCE OF
SingleResponse, which is permitted on the wire and accepted by the
OpenSSL decoder, the OCSP_BASICRESP structure allocated by
OCSP_response_get1_basic() was not freed because an early return
bypassed the cleanup code at the end of the function.
The amount of memory leaked per handshake can be amplified by the
attacker by padding the certs field of the BasicOCSPResponse with
bogus certificates, which are parsed and stored in the leaked
structure before the empty response check triggers the early return.
A long-running TLS client that repeatedly connects to a malicious
server can have its memory exhausted over time.
OCSP response checking is not enabled by default. Only client
applications that explicitly enable the OCSP response check
verification flags are affected.
FIPS impact: no
The FIPS modules in 4.0 and 3.6 are not affected by this issue as the
affected code is outside the OpenSSL FIPS module boundary.CVSS7.5HighEPSS0.52%RoutineCVE-2026-45447openssl +37 moreHeap Use-After-Free in the PKCS7_verify() FunctionIssue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData
digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may
incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent
use of the BIO by the calling application results in a use-after-free
condition.
In the common case this occurs when the application later calls
BIO_free() on the BIO originally passed to PKCS7_verify(). Depending
on allocator behavior and application-specific BIO usage patterns, this
may result in a crash or other memory corruption. In some application
contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL
PKCS#7 APIs may be affected. Applications using the CMS APIs for this
processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.CVSS8.8HighEPSS4.00%RoutineCVE-2026-45446openssl +26 moreIncorrect Tag Processing for Empty Messages in AES-GCM-SIV and AES-SIV modesIssue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV
(RFC 8452) mishandle the authentication of AAD (Additional Authenticated
Data) with an empty ciphertext allowing a forgery of such messages.
Impact summary: An attacker can forge empty messages with arbitrary AAD
to the victim's application using these ciphers.
AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD
modes: they accept a key, nonce, optional AAD (bytes that are authenticated
but not encrypted), and plaintext, and produces ciphertext plus a 16-byte
tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only
if the tag is verified succesfully.
In OpenSSL's provider implementation of these ciphers, the expected tag is
computed only when decryption function is invoked with non-empty data.
If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without
invocation of the ciphertext update, which can happen when the received
ciphertext length is zero, the tag is never recalculated and still holds its
all-zeros value.
When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty
ciphertext, and all-zeros tag passes authentication under any key they do not
know, single-shot. When AES-SIV is used, for mounting the attack it's
necessary for the application to reuse the decryption context without
resetting the key.
AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since
OpenSSL 3.2.
No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support
either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must
implement their own protocol and use the EVP interface. Also they must skip the
ciphertext update when a message with an empty ciphertext arrives.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as these algorithms are not FIPS approved and the affected code is
outside the OpenSSL FIPS module boundary.CVSS4.8MediumEPSS0.44%PrioritiseCVE-2026-45445openssl +26 moreAES-OCB IV Ignored on EVP_Cipher() PathIssue summary: When an application drives an AES-OCB context through the
public EVP_Cipher() one-shot interface, the application-supplied
initialisation vector (IV) is silently discarded.
Impact summary: Every message encrypted under the same key uses the
same effective nonce regardless of the IV supplied by the caller,
resulting in (key, nonce) reuse and loss of confidentiality. If the
same code path is used to compute the authentication tag, the tag
depends only on the (key, IV) pair and not on the plaintext or
ciphertext, allowing universal forgery of arbitrary ciphertext from a
single captured message.
OpenSSL provides two ways to drive a cipher: the documented streaming
interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level
one-shot, EVP_Cipher(), whose documentation explicitly recommends
against use by applications in favour of EVP_CipherUpdate() and
EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes
the application-supplied IV into the OCB context before processing
data; the one-shot handler did not. Every call to EVP_Cipher() on an
AES-OCB context therefore ran with the all-zero key-derived offset
state left by cipher initialisation, regardless of the caller's IV.
If EVP_EncryptFinal_ex() is subsequently used to obtain the
authentication tag, the deferred IV setup runs at that point and
clears the running checksum that should have been accumulated over the
plaintext. The resulting tag is a function of (key, IV) only and
verifies against any ciphertext produced under the same (key, IV)
pair.
The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a
TLS cipher suite, and libssl does not call EVP_Cipher() in any case.
Applications that drive AES-OCB through the documented streaming AEAD
API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only
applications that combine the AES-OCB cipher with the EVP_Cipher()
one-shot API are vulnerable.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as AES-OCB is outside the OpenSSL FIPS module boundary.CVSS7.5HighEPSS0.70%RoutineCVE-2026-42770openssl +29 moreFFC-DH Peer Validation Uses Attacker-Supplied qIssue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)
peer key, the peer key is not properly checked for the subgroup membership.
Impact summary: A malicious peer which presents an X9.42 key carrying the
victim's p and g parameters, a forged q = r (a small prime factor of the
cofactor (p−1)/q_local), and a public value Y of order r can recover the
victim's private key after a small number of key exchange attempts.
When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the
subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's
own q parameter, not the local key's q. The peer's domain parameters are
then matched against the domain parameters of the private key, but the value
of q is not compared.
A malicious peer who presents an X9.42 key carrying the victim's p, g,
a forged q = r (a small prime factor of the cofactor), and a public
value Y of order r passes all checks. The shared secret then takes only
r distinct values, leaking priv mod r. Repeating for each small-prime
factor of the cofactor and combining via CRT recovers the full private
key (Lim–Lee / small-subgroup-confinement attack).
The realistic attack surface is narrow: principally CMP deployments with
long-lived RA/CA DHX keys and bespoke enterprise or government applications
using X9.42 DHX static keys with interactive protocols and therefore this
issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this
issue.CVSS3.7LowEPSS0.50%