🚨 CVE-2026-54872
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
ec: make ossl_ec_scalar_mul_ladder() scalar padding constant time · openssl/openssl@1a5bee8
Fixes CVE-2026-54872
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Alicja Kario <hkario@redhat.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Merge-date: Tue...
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Alicja Kario <hkario@redhat.com>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Merge-date: Tue...
🚨 CVE-2026-54873
Issue summary: QUIC process may keep memory for QUIC packet
buffer for much longer period than necessary.
Impact summary: Remote peer can exploit this vulnerability
by sending maliciously crafted packets, making the local
QUIC stack to keep the memory for packet buffers allocated.
The time for which the memory remains allocated is entirely
under the control of the potentially malicious remote peer.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: To save copy operation from the packet buffer to the
stream reassemble buffer the QUIC stack leaves the stream data
on the packet buffer waiting to be copied to a buffer provided
by the local receiving application. The QUIC stack releases
a reference to the packet buffer only after the data are copied
to the application buffer. This design is more efficient for
legitimate data transfers but enables an attacker to allocate a lot
more memory than actually required by the data kept in the receiving
stream buffer.
To mitigate the vulnerability, the QUIC stack now calculates
and monitors memory overhead for every stream. The memory overhead
for a single stream frame is calculated as a difference between the
size of the whole packet that carries the stream frame and the size
of the stream frame itself. The memory overhead for a single stream
frame is added to the total (cumulative) memory overhead QUIC stack
keeps for each stream. Once the cumulative memory overhead exceeds
64kB, the QUIC stack moves the stream frame data from the packet
buffer to the stream buffer, starting with the next packet received.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
🎖@cveNotify
Issue summary: QUIC process may keep memory for QUIC packet
buffer for much longer period than necessary.
Impact summary: Remote peer can exploit this vulnerability
by sending maliciously crafted packets, making the local
QUIC stack to keep the memory for packet buffers allocated.
The time for which the memory remains allocated is entirely
under the control of the potentially malicious remote peer.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: To save copy operation from the packet buffer to the
stream reassemble buffer the QUIC stack leaves the stream data
on the packet buffer waiting to be copied to a buffer provided
by the local receiving application. The QUIC stack releases
a reference to the packet buffer only after the data are copied
to the application buffer. This design is more efficient for
legitimate data transfers but enables an attacker to allocate a lot
more memory than actually required by the data kept in the receiving
stream buffer.
To mitigate the vulnerability, the QUIC stack now calculates
and monitors memory overhead for every stream. The memory overhead
for a single stream frame is calculated as a difference between the
size of the whole packet that carries the stream frame and the size
of the stream frame itself. The memory overhead for a single stream
frame is added to the total (cumulative) memory overhead QUIC stack
keeps for each stream. Once the cumulative memory overhead exceeds
64kB, the QUIC stack moves the stream frame data from the packet
buffer to the stream buffer, starting with the next packet received.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
🎖@cveNotify
GitHub
Limit packet buffer overhead to ~64kB per stream. · openssl/openssl@1f643b8
There is currently no limit on how many bytes of packet
buffers each stream can hold in memory. To monitor and limit
the size of packet buffers used by stream the change accounts
so called stream c...
buffers each stream can hold in memory. To monitor and limit
the size of packet buffers used by stream the change accounts
so called stream c...
🚨 CVE-2026-54875
Issue summary: A non-constant-time optimized implementation of scalar
point multiplication is used for SM2 private key operations on ARM64 and
RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe
the cache-line access pattern of SM2 signing or decryption on an affected
platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized
scalar multiplication implementation whose conditional branches and table
look ups are chosen according to the bits of the secret scalar. The execution
time and the cache-access pattern therefore depend on the long-term private
key (during SM2 decryption) or the per-signature nonce (during SM2 signature
generation), forming a timing and cache side-channel.
FIPS Impact: no
SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part
of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and
RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal.
It was independently reported on 6 June 2026 by Feng Xue.
The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) --
Reported by: Abhinav Agarwal, Feng Xue
Fixed by: Igor Ustinov
🎖@cveNotify
Issue summary: A non-constant-time optimized implementation of scalar
point multiplication is used for SM2 private key operations on ARM64 and
RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe
the cache-line access pattern of SM2 signing or decryption on an affected
platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized
scalar multiplication implementation whose conditional branches and table
look ups are chosen according to the bits of the secret scalar. The execution
time and the cache-access pattern therefore depend on the long-term private
key (during SM2 decryption) or the per-signature nonce (during SM2 signature
generation), forming a timing and cache side-channel.
FIPS Impact: no
SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part
of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and
RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal.
It was independently reported on 6 June 2026 by Feng Xue.
The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) --
Reported by: Abhinav Agarwal, Feng Xue
Fixed by: Igor Ustinov
🎖@cveNotify
GitHub
Make the ecp_sm2p256 scalar multiplication constant time · openssl/openssl@3f01bbc
Fixes CVE-2026-54875.
This fix implemets the same idea as in PR#30649 by Joshua Rogers (@MegaManSec).
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Alicja Kario <hkario@redhat.com&g...
This fix implemets the same idea as in PR#30649 by Joshua Rogers (@MegaManSec).
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Alicja Kario <hkario@redhat.com&g...
🚨 CVE-2026-72897
Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a
connection to a different SSL_CTX part way through a handshake may access
memory beyond the end of an internal array if the replacement context knows
about more provider signature algorithms than the context the connection was
created from. Applications which never call SSL_set_SSL_CTX() are not
affected.
Impact summary: A remote peer may be able to cause a small out-of-bounds
read, and in some circumstances a fixed-value out-of-bounds write, on the
server heap. This may lead to a Denial of Service.
CWE: CWE-787: Out-of-bounds Write
Description: A TLS connection records how many certificate slots it has
when it is created, taken from the SSL_CTX that created it: the built-in
certificate types plus one slot for each provider TLS-SIGALG entry that
context was aware of. That count sizes an internal array of per-slot
certificate validity flags.
An application may replace a connection's SSL_CTX part way through the
handshake by calling SSL_set_SSL_CTX(), most commonly from a servername
callback in order to serve a different virtual host. Doing so did not
refresh the recorded count. A provider signature algorithm's slot index is
its position in the list of whichever context resolves it, so if the
replacement context is aware of more of them than the original, an
algorithm offered by the peer can resolve to an index beyond the end of the
array. Processing the peer's signature algorithms then reads one four byte
word past the end for each such algorithm and, where the word read is zero,
writes a fixed value over it. A peer offering many of them can corrupt heap
metadata and abort the process.
Only provider signature algorithms which occupy one of the excess slots,
and which the server also has configured, have this effect. Codepoints the
replacement context does not recognise are discarded without being resolved
to a slot, and provider signature algorithms are usable only from TLS 1.3.
The two contexts must therefore be aware of different numbers of provider
signature algorithms, which requires separate library contexts, a provider
loaded between the two being created, or providers which differ in what
they advertise - in 4.0, for example, the default provider advertises SM2
where the FIPS provider does not. A deployment meeting the condition is
also unable to negotiate the affected algorithms with legitimate clients,
since the same stale count hides the corresponding certificates, so the
misconfiguration is likely to be noticed. For that reason, and because the
configuration is not the default, this issue has been assessed as Low
severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.
🎖@cveNotify
Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a
connection to a different SSL_CTX part way through a handshake may access
memory beyond the end of an internal array if the replacement context knows
about more provider signature algorithms than the context the connection was
created from. Applications which never call SSL_set_SSL_CTX() are not
affected.
Impact summary: A remote peer may be able to cause a small out-of-bounds
read, and in some circumstances a fixed-value out-of-bounds write, on the
server heap. This may lead to a Denial of Service.
CWE: CWE-787: Out-of-bounds Write
Description: A TLS connection records how many certificate slots it has
when it is created, taken from the SSL_CTX that created it: the built-in
certificate types plus one slot for each provider TLS-SIGALG entry that
context was aware of. That count sizes an internal array of per-slot
certificate validity flags.
An application may replace a connection's SSL_CTX part way through the
handshake by calling SSL_set_SSL_CTX(), most commonly from a servername
callback in order to serve a different virtual host. Doing so did not
refresh the recorded count. A provider signature algorithm's slot index is
its position in the list of whichever context resolves it, so if the
replacement context is aware of more of them than the original, an
algorithm offered by the peer can resolve to an index beyond the end of the
array. Processing the peer's signature algorithms then reads one four byte
word past the end for each such algorithm and, where the word read is zero,
writes a fixed value over it. A peer offering many of them can corrupt heap
metadata and abort the process.
Only provider signature algorithms which occupy one of the excess slots,
and which the server also has configured, have this effect. Codepoints the
replacement context does not recognise are discarded without being resolved
to a slot, and provider signature algorithms are usable only from TLS 1.3.
The two contexts must therefore be aware of different numbers of provider
signature algorithms, which requires separate library contexts, a provider
loaded between the two being created, or providers which differ in what
they advertise - in 4.0, for example, the default provider advertises SM2
where the FIPS provider does not. A deployment meeting the condition is
also unable to negotiate the affected algorithms with legitimate clients,
since the same stale count hides the corresponding certificates, so the
misconfiguration is likely to be noticed. For that reason, and because the
configuration is not the default, this issue has been assessed as Low
severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.
🎖@cveNotify
GitHub
Fix out-of-bounds valid_flags access after SSL_set_SSL_CTX() · openssl/openssl@00646e5
SSL_new() sizes the connection-local signature algorithm state from the
SSL_CTX the connection was created from: sc->ssl_pkey_num counts the
built-in certificate slots plus one for each of t...
SSL_CTX the connection was created from: sc->ssl_pkey_num counts the
built-in certificate slots plus one for each of t...
🚨 CVE-2026-75804
Issue summary: OpenSSL QUIC stack does not enforce connection
level flow control for streams. Remote peers may send more bytes
as long as they fit within the stream flow control limits.
Impact summary: A malicious remote peer may exploit the lack of connection
flow control for streams to make the QUIC stack receive ~100MB of memory
instead of 768 KiB (default flow control window size).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The local QUIC stack advertises two flow control limits
to its remote peer: stream flow control limit and connection flow
control limit. The remote peer must follow both limits when transmitting
stream data.
Whenever the local QUIC stack receives a stream frame, it validates
that the size of the received stream frame stays within flow control limits.
If either limit is exceeded (stream level or connection level), then
the QUIC stack must close the connection with a flow control error.
The vulnerable OpenSSL QUIC stack enforces the stream-level but not
the connection-level limit. To exploit the issue, three conditions must be met:
- the remote peer opens several streams
- each stream must stay within the stream-level flow control limit
- there must be no zero-offset byte sent on any of the streams
(to prevent the vulnerable QUIC stack from consuming data).
By meeting the conditions above, the remote peer may make the local stack
allocate 2 x MAX_STREAMS x (stream flow control limit) bytes
of memory. MAX_STREAMS defaults to 100, and the limit applies to both
bidirectional and unidirectional streams, making it 200 in total. The default
flow control window for a stream is 512kB. The remote peer may
force the vulnerable QUIC stack to allocate 100MB of heap per connection.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
🎖@cveNotify
Issue summary: OpenSSL QUIC stack does not enforce connection
level flow control for streams. Remote peers may send more bytes
as long as they fit within the stream flow control limits.
Impact summary: A malicious remote peer may exploit the lack of connection
flow control for streams to make the QUIC stack receive ~100MB of memory
instead of 768 KiB (default flow control window size).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The local QUIC stack advertises two flow control limits
to its remote peer: stream flow control limit and connection flow
control limit. The remote peer must follow both limits when transmitting
stream data.
Whenever the local QUIC stack receives a stream frame, it validates
that the size of the received stream frame stays within flow control limits.
If either limit is exceeded (stream level or connection level), then
the QUIC stack must close the connection with a flow control error.
The vulnerable OpenSSL QUIC stack enforces the stream-level but not
the connection-level limit. To exploit the issue, three conditions must be met:
- the remote peer opens several streams
- each stream must stay within the stream-level flow control limit
- there must be no zero-offset byte sent on any of the streams
(to prevent the vulnerable QUIC stack from consuming data).
By meeting the conditions above, the remote peer may make the local stack
allocate 2 x MAX_STREAMS x (stream flow control limit) bytes
of memory. MAX_STREAMS defaults to 100, and the limit applies to both
bidirectional and unidirectional streams, making it 200 in total. The default
flow control window for a stream is 512kB. The remote peer may
force the vulnerable QUIC stack to allocate 100MB of heap per connection.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
🎖@cveNotify
GitHub
CVE-2026-75804 QUIC connection-level flow control not enforced, remot… · openssl/openssl@2e8f546
…e memory exhaustion
Function ossl_quic_rxfc_get_error() must also report flow control violation
error for connection level not just for stream level. Ignoring connection
level error prevents QUIC...
Function ossl_quic_rxfc_get_error() must also report flow control violation
error for connection level not just for stream level. Ignoring connection
level error prevents QUIC...
🚨 CVE-2026-75805
Issue summary: A CMP client that requests certificate revocation on the basis
of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when
processing a crafted revocation response.
Impact summary: The NULL pointer dereference happens on a read which
leads to a crash and a Denial of Service for the affected client application.
CWE: CWE-476: NULL-pointer dereference
Description: A CMP client revoking a certificate has to tell the server which
certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the
certificate itself or its issuer name and serial number. This is
'openssl cmp -cmd rr -csr <file>' on the command line, or
OSSL_CMP_exec_RR_ses() with the certificate supplied via
OSSL_CMP_CTX_set1_p10CSR() through the API.
A CSR does not contain the issuer name and serial number of the certificate,
so the client does not send them. A server may optionally name the
certificate it revoked in its response, and the client then compares that
name against what it sent. Having sent neither an issuer name nor a serial
number, it has nothing to compare against, and a server returning a specially
crafted name causes the client to read from a NULL pointer and crash.
The revocation response is checked for valid message protection before
the affected code is reached, so an attacker must be a malicious or
compromised CMP server, or a man-in-the-middle in possession of the
secret used for message protection. Clients that identify the certificate
to be revoked by a certificate or by issuer and serial number rather
than by a PKCS#10 CSR are not affected.
FIPS impact: no
No FIPS modules are affected by this issue, as the CMP protocol
implementation is outside the OpenSSL FIPS module boundary.
🎖@cveNotify
Issue summary: A CMP client that requests certificate revocation on the basis
of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when
processing a crafted revocation response.
Impact summary: The NULL pointer dereference happens on a read which
leads to a crash and a Denial of Service for the affected client application.
CWE: CWE-476: NULL-pointer dereference
Description: A CMP client revoking a certificate has to tell the server which
certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the
certificate itself or its issuer name and serial number. This is
'openssl cmp -cmd rr -csr <file>' on the command line, or
OSSL_CMP_exec_RR_ses() with the certificate supplied via
OSSL_CMP_CTX_set1_p10CSR() through the API.
A CSR does not contain the issuer name and serial number of the certificate,
so the client does not send them. A server may optionally name the
certificate it revoked in its response, and the client then compares that
name against what it sent. Having sent neither an issuer name nor a serial
number, it has nothing to compare against, and a server returning a specially
crafted name causes the client to read from a NULL pointer and crash.
The revocation response is checked for valid message protection before
the affected code is reached, so an attacker must be a malicious or
compromised CMP server, or a man-in-the-middle in possession of the
secret used for message protection. Clients that identify the certificate
to be revoked by a certificate or by issuer and serial number rather
than by a PKCS#10 CSR are not affected.
FIPS impact: no
No FIPS modules are affected by this issue, as the CMP protocol
implementation is outside the OpenSSL FIPS module boundary.
🎖@cveNotify
GitHub
Guard comparision when values are NULL · openssl/openssl@7588db7
Fixes: CVE-2026-75805
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Milan Broz <mbroz@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.found...
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Reviewed-by: Milan Broz <mbroz@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.found...
🚨 CVE-2026-75806
Issue summary: An established DTLS 1.2 association using an AEAD cipher suite
can be terminated by a single unauthenticated datagram whose encrypted
fragment is shorter than the mandatory explicit IV and authentication tag
overhead.
Impact summary: An attacker who can send a datagram that is routed to an
existing DTLS 1.2 association can tear that association down without knowing
any key material. This is a Denial of Service limited to the targeted
association. There is no memory safety or confidentiality impact.
CWE: CWE-1284: Improper Validation of Specified Quantity in Input
Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher
suite carries an explicit IV followed by the ciphertext and an authentication
tag. When decrypting such a record the record layer passed the record length to
the cipher implementation before checking that the record was long enough to
contain the explicit IV and the tag. For a record shorter than that overhead the
cipher implementation rejected the impossible length, and the record layer
treated this as an internal failure and raised a fatal internal_error alert
instead of treating the record as one that failed authentication.
In TLS 1.2 the same record causes a fatal internal_error alert instead of the
expected bad_record_mac alert. Since any undecryptable record already
terminates a TLS connection, this is a protocol conformance issue rather than
a security issue in TLS.
The fix validates the record length against the explicit IV and tag length
before any AEAD processing, so that TLS reports bad_record_mac and DTLS
silently discards the record.
FIPS impact: no
The affected code is outside the FIPS module boundary.
🎖@cveNotify
Issue summary: An established DTLS 1.2 association using an AEAD cipher suite
can be terminated by a single unauthenticated datagram whose encrypted
fragment is shorter than the mandatory explicit IV and authentication tag
overhead.
Impact summary: An attacker who can send a datagram that is routed to an
existing DTLS 1.2 association can tear that association down without knowing
any key material. This is a Denial of Service limited to the targeted
association. There is no memory safety or confidentiality impact.
CWE: CWE-1284: Improper Validation of Specified Quantity in Input
Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher
suite carries an explicit IV followed by the ciphertext and an authentication
tag. When decrypting such a record the record layer passed the record length to
the cipher implementation before checking that the record was long enough to
contain the explicit IV and the tag. For a record shorter than that overhead the
cipher implementation rejected the impossible length, and the record layer
treated this as an internal failure and raised a fatal internal_error alert
instead of treating the record as one that failed authentication.
In TLS 1.2 the same record causes a fatal internal_error alert instead of the
expected bad_record_mac alert. Since any undecryptable record already
terminates a TLS connection, this is a protocol conformance issue rather than
a security issue in TLS.
The fix validates the record length against the explicit IV and tag length
before any AEAD processing, so that TLS reports bad_record_mac and DTLS
silently discards the record.
FIPS impact: no
The affected code is outside the FIPS module boundary.
🎖@cveNotify
GitHub
TLS: Reject undersized TLS 1.2 AEAD records before AEAD processing · openssl/openssl@04728a2
In tls1_cipher() the receive path invoked EVP_CTRL_AEAD_TLS1_AAD before
checking that the record was long enough to contain the mandatory
explicit IV and authentication tag. A record shorter than t...
checking that the record was long enough to contain the mandatory
explicit IV and authentication tag. A record shorter than t...
🚨 CVE-2026-77696
Issue summary: SM2 signature generation uses non-constant-time arithmetic
on secret values, forming a timing side-channel.
Impact summary: An attacker able to measure SM2 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: SM2 signature generation computes the signature value using
variable-time BIGNUM operations on the secret nonce and the private key, so
the time taken to produce an SM2 signature depends on these secret values,
forming a timing side-channel.
Applications performing SM2 signature generation are affected on all
platforms.
FIPS Impact: no
SM2 is not a FIPS algorithm.
🎖@cveNotify
Issue summary: SM2 signature generation uses non-constant-time arithmetic
on secret values, forming a timing side-channel.
Impact summary: An attacker able to measure SM2 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: SM2 signature generation computes the signature value using
variable-time BIGNUM operations on the secret nonce and the private key, so
the time taken to produce an SM2 signature depends on these secret values,
forming a timing side-channel.
Applications performing SM2 signature generation are affected on all
platforms.
FIPS Impact: no
SM2 is not a FIPS algorithm.
🎖@cveNotify
GitHub
sm2: make sm2_sig_gen() constant time · openssl/openssl@1c4aed8
After fixing CVE-2025-9231, sm2_sig_gen() still used variable-time
BN_mod_mul() and BN_sub() on private key and nonce material.
This commit makes it fully constant time.
Fixes CVE-2026-77696
Co-a...
BN_mod_mul() and BN_sub() on private key and nonce material.
This commit makes it fully constant time.
Fixes CVE-2026-77696
Co-a...
🚨 CVE-2024-8122
The WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in multi-factor authentication (MFA). This allows unused OTPs to remain valid indefinitely, presenting an opportunity for malicious actors to conduct brute force attacks by repeatedly guessing the OTP.
The absence of automatic expiration for OTPs grants attackers an unlimited timeframe to attempt guessing the correct code. A successful brute force attack can lead to an MFA bypass, resulting in the unauthorized takeover of a user's account and compromising the security and privacy of both the individual and the system.
🎖@cveNotify
The WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in multi-factor authentication (MFA). This allows unused OTPs to remain valid indefinitely, presenting an opportunity for malicious actors to conduct brute force attacks by repeatedly guessing the OTP.
The absence of automatic expiration for OTPs grants attackers an unlimited timeframe to attempt guessing the correct code. A successful brute force attack can lead to an MFA bypass, resulting in the unauthorized takeover of a user's account and compromising the security and privacy of both the individual and the system.
🎖@cveNotify
Wso2
Page not found - WSO2 Security and Compliance Documentation
WSO2 security advisories, CVE justifications, cloud security bulletins, secure coding and deployment guidelines, and how to report a vulnerability.
🚨 CVE-2026-87680
A command injection vulnerability in the REST API management interface of Brocade Fabric OS versions before 10.0.1 allows an authenticated user to execute arbitrary system commands via crafted input parameters.
🎖@cveNotify
A command injection vulnerability in the REST API management interface of Brocade Fabric OS versions before 10.0.1 allows an authenticated user to execute arbitrary system commands via crafted input parameters.
🎖@cveNotify
🚨 CVE-2026-87681
An Access Control Bypass vulnerability exists in the Role-Based Access Control (RBAC) validation engine of Brocade Fabric OS versions before 10.0.1. When processing certain management protocol operations, the RBAC engine incorrectly categorizes non-standard action opcodes during permission checks. This allows authenticated users with read-only management privileges to bypass access controls and execute restricted administrative operations.
🎖@cveNotify
An Access Control Bypass vulnerability exists in the Role-Based Access Control (RBAC) validation engine of Brocade Fabric OS versions before 10.0.1. When processing certain management protocol operations, the RBAC engine incorrectly categorizes non-standard action opcodes during permission checks. This allows authenticated users with read-only management privileges to bypass access controls and execute restricted administrative operations.
🎖@cveNotify
🚨 CVE-2026-95387
SPDY protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
SPDY protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
SPDY Data Frame Reassembly Integer Overflow (#21487) · Issues · Wireshark Foundation / Wireshark · GitLab
SPDY Data Frame Reassembly Integer Overflow 1. Executive Summary
🚨 CVE-2026-95388
Sharkd utility crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
Sharkd utility crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
Sharkd RTP resampler output-size wrap causes undersized-buffer write (#21545) · Issues · Wireshark Foundation / Wireshark · GitLab
Executive Summary Mallory supplies Alice with a syntactically accepted SIP/SDP and RTP capture. When Alice or...
🚨 CVE-2026-95389
SCTP protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
SCTP protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
SCTP Fragment Reassembly integer overflow in fragment_reassembly() leads to heap buffer overflow (#21481) · Issues · Wireshark…
SCTP Reassembly Integer Overflow Vulnerability — Technical Report
🚨 CVE-2026-95390
PEAK CAN TRC file parser crash in 4.6.0 to 4.6.8 allows denial of service
🎖@cveNotify
PEAK CAN TRC file parser crash in 4.6.0 to 4.6.8 allows denial of service
🎖@cveNotify
GitLab
PEAK TRC v1 error-frame parser dereferences missing data tokens (#21503) · Issues · Wireshark Foundation / Wireshark · GitLab
Summary The PEAK TRC v1 ERROR-frame parser splits the data column and passes bytes[0] or bytes[1]...
🚨 CVE-2026-95391
ZigBee ZCL protocol dissector crash in 4.6.0 to 4.6.8 allows denial of service
🎖@cveNotify
ZigBee ZCL protocol dissector crash in 4.6.0 to 4.6.8 allows denial of service
🎖@cveNotify
GitLab
ZigBee ZCL Touchlink: empty the commissioning map on a redissect. (!26096) · Merge requests · Wireshark Foundation / Wireshark…
All of the entries in the commissioning map are allocated with "file" scope, which means that, before a redissect pass, they will all be freed. On...
🚨 CVE-2026-95392
MBIM protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
MBIM protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
MBIM GSM 7-bit character-count wrap causes full-tree analysis denial of service (#21549) · Issues · Wireshark Foundation / Wireshark…
Executive Summary Mallory can send Alice a Linux usbmon capture whose outer USB and MBIM framing...
🚨 CVE-2026-95393
CSN.1 protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
CSN.1 protocol dissector crash in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
Heap buffer overflow (WRITE) in CSN.1 dissector (#21510) · Issues · Wireshark Foundation / Wireshark · GitLab
Heap buffer overflow (WRITE) in CSN.1 dissector — CSN_RECURSIVE_ARRAY writes past destination array with no capacity check (packet-csn1.c)
🚨 CVE-2026-95394
Microsoft Network Monitor file parser large loop in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
Microsoft Network Monitor file parser large loop in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
NetMon 2.x timestamp normalization permits CPU denial of service from a small capture file (#21523) · Issues · Wireshark Foundation…
Summary A valid 868-byte Microsoft Network Monitor 2.0 capture can keep Wireshark's ordinary file reader CPU-bound in timestamp...
🚨 CVE-2026-95395
IEEE C37.118 Synchrophasor protocol dissector memory leak in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
IEEE C37.118 Synchrophasor protocol dissector memory leak in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service
🎖@cveNotify
GitLab
Wireshark SYNCHROPHASOR CFG3 frame parser memory exhaustion (#21492) · Issues · Wireshark Foundation / Wireshark · GitLab
Summary The SYNCHROPHASOR dissector (packet-synphasor.c) parses CFG3 configuration frames. The function config_3_frame_fast() reads the num_ph (number of phasors)...