Writeup Exploits
62,204 exploits tracked across all sources.
ESF-IDF: Heap Out-of-Bounds Read in Bluedroid AVRCP Target Parser
ESF-IDF is the Espressif Internet of Things (IOT) Development Framework. In versions 5.2.6, 5.3.5, 5.4.4, 5.5.3, and 6.0, an out-of-bounds read exists in the BlueDroid AVRCP vendor-command parser (avrc_pars_vendor_cmd() in components/bt/host/bluedroid/stack/avrc/avrc_pars_tg.c). This issue has been patched in versions 5.2.7, 5.3.6, 5.4.5, 5.5.4, and 6.0.1.
CVSS 4.6
Unauthenticated denial-of-service via BEAM atom table exhaustion in membrane_mp4_plugin
Allocation of Resources Without Limits or Throttling vulnerability in membraneframework membrane_mp4_plugin allows unauthenticated denial-of-service via BEAM atom table exhaustion.
The MP4 box header parser converts each 4-byte box name to an atom using String.to_atom/1 without validation. 'Elixir.Membrane.MP4.Container.Header':parse_box_name/1 in lib/membrane_mp4/container/header.ex interns every box name encountered while 'Elixir.Membrane.MP4.Container.Header':parse/1 walks the input. BEAM atoms are never garbage-collected, so each unique attacker-controlled 4-byte name is a permanent allocation. A crafted MP4 of approximately 8 MB containing roughly 1.1 million boxes with distinct non-standard names exhausts the atom table (default ceiling around 1,048,576 atoms), aborting the entire BEAM node and taking down all applications running on it.
This issue affects membrane_mp4_plugin from 0.3.0 before 0.36.7.
Cerebrate before v1.37 allows mass assignment of record identifiers during object creation
Cerebrate before version 1.37 contains a mass-assignment vulnerability in the generic CRUD add path. The add() handler attempted to remove an attacker-supplied id from $params before normalizing the request through __massageInput(). Because the normalized $input could still contain an id field, a user able to reach an affected add endpoint could supply an identifier that should have been server-controlled.
Successful exploitation could allow creation of objects with attacker-chosen identifiers, potentially causing unauthorized data manipulation, object spoofing, inconsistent references, or disruption through identifier collisions, depending on the affected model and endpoint permissions. The issue was fixed in v1.37 by removing id from the normalized input before entity patching.
Cerebrate < 1.37 - Authenticated Mass Assignment Record Overwrite
Cerebrate before version 1.37 allowed the id primary key field to be supplied through request input during CRUD edit operations and certain custom entity patching flows. In affected entities that did not explicitly mark id as inaccessible, an authenticated attacker could submit a crafted edit request containing the id of another record, causing the save operation to update that unrelated record instead of the record identified by the route parameter. The issue affected several entity types inheriting permissive mass-assignment defaults, including User, Role, UserSetting, LocalTool, PermissionLimitation, and EnumerationCollection. Since UserSettings edit functionality was reachable by any authenticated user, exploitation could allow unauthorized modification of records within the same entity type, with impact depending on the affected endpoint and writable fields. Cerebrate 1.37 fixes this by stripping id from request input after marshalling callbacks and by globally marking id as inaccessible in the base AppModel entity.
The discovery of those potential vulnerabilities are inherited from initial finding from Jeroen Pinoy additional support from AI-Assisted Optus 4.8 (the commit wrongly assign Claude Fable 5 as the model switched) and coordinated by Andras Iklody.
Cerebrate self-registration password hash exposure via inbox and audit log views
Cerebrate before version 1.37 exposed credential material from self-registration requests. The self-registration workflow stored the registrant’s hashed password in the inbox message data payload. This payload was returned unredacted through inbox index and view responses, including HTML, JSON, and CSV outputs, and could also be written unredacted into audit log entries for the inbox message.
An authenticated user with sufficient privileges to access inbox entries or related audit logs could retrieve password hashes associated with pending self-registration requests. Although the exposed value is a password hash rather than a plaintext password, disclosure of password hashes may enable offline password-cracking attempts and could increase risk where users reuse passwords across systems.
Cerebrate 1.37 fixes the issue by redacting sensitive password and authkey fields from inbox display/API output and recursively redacting those fields from JSON values written to audit logs, while leaving the stored registration payload intact for account creation processing.
Affected component: Inbox self-registration request handling and audit logging
Fixed version: Cerebrate 1.37
Unbounded Frame Count in video/jpeg Base64 Data URL Processing Leads to OOM DoS in vllm-project/vllm
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method. When processing `video/jpeg` data URLs, the method splits the base64 data string on commas to extract individual JPEG frames without enforcing a frame count limit. An attacker can exploit this by crafting a single API request containing thousands of comma-separated base64-encoded JPEG frames in a data URL, causing the server to decode all frames into memory and crash due to excessive memory consumption. This vulnerability is reachable via the OpenAI-compatible chat completions API and does not require authentication.
CVSS 7.5
The expat and elementtree parsers use insufficient entropy for XML hash-flooding protection
`xml.parsers.expat` and `xml.etree.ElementTree` use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
CVSS 7.5
FTP PASV SSRF, ftpcp() does not use actual peer address, trusts server-supplied PASV host address
The ftpcp() function in Lib/ftplib.py was not updated when
CVE-2021-4189 was fixed. While makepasv() was patched to replace
server-supplied PASV host addresses with the actual peer address
(getpeername()[0]), ftpcp() still calls parse227() directly and passes
the raw attacker-controllable IP address and port to target.sendport(). This patch is related to CVE-2021-4189.
tarfile.data_filter path traversal bypass allows writing outside the extraction directory
tarfile.data_filter could be bypassed using crafted link entries, including symlinks with empty or directory-like names, to redirect later archive members outside the intended extraction directory. This allowed a malicious tar archive to cause tarfile.extractall() to write files outside the destination directory, subject to the permissions of the extracting process.
CPython bz2.BZ2Decompressor - Stack Buffer Overflow
bz2.BZ2Decompressor objects could be reused after a decompression error. If an application caught the resulting OSError and retried with the same decompressor, crafted input could cause the decompressor to resume from an invalid internal state and perform out-of-bounds writes to a stack buffer. This could crash the process when processing untrusted data.
Heap Buffer Over-read in ASN.1 Content Parsing
Issue summary: Parsing a crafted DER-encoded ASN.1 structure with a primitive
element whose content exceeds 2 gigabytes in length may cause a heap buffer
over-read on 64-bit Unix and Unix-like platforms.
Impact summary: The heap buffer over-read may crash the application (Denial of
Service) or to load into the decoded ASN.1 object contents of memory beyond the
end of the input buffer. More typically such ASN.1 elements would instead be
truncated.
An integer truncation in OpenSSL's ASN.1 decoder causes the content length of
an ASN.1 primitive element to be mishandled when it exceeds 2 gigabytes. In the
worst case the truncated length is treated as a request to scan the binary
content for a terminating zero byte, possibly causing OpenSSL to read either
less than or beyond the end of the allocated buffer.
Applications that pass attacker-supplied data to d2i_X509(), d2i_PKCS7(), or
any other d2i_* decoding function are affected. OpenSSL's own command-line
tools are not vulnerable, as data read through the BIO layer is checked before
it reaches the affected code. The issue only affects 64-bit Unix and Unix-like
platforms; 32-bit platforms and 64-bit Windows 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.
CVSS 7.5
PKCS#12 Files with PBMAC1 Are Accepted with Short HMAC Keys
Issue Summary: The PKCS#12 file processing fails to perform sufficient input
validation for files that use Password-Based Message Authentication Code 1
(PBMAC1) integrity mechanism allowing a certificate and private key forgery.
Impact Summary: An attacker impersonating a user can cause a service reading
PKCS#12 files to accept forged certificates and private keys with a 1 in 256
probability.
If a service accepting PKCS#12 files is using passwords for authenticating
the received files, the attacker can create unencrypted PKCS#12 files that
use PBMAC1 authentication that specifies an HMAC key of only one byte, allowing
them to craft a file that will be accepted with a 1 in 256 probability.
That would then cause the service to accept a certificate and private key
controlled by the attacker.
The FIPS modules are not affected by this issue, as the affected code is
outside the OpenSSL FIPS module boundary.
CVSS 7.4
CMS AuthEnvelopedData Processing May Accept Forged Messages
Issue Summary: Cryptographic Message Services (CMS) processing fails to perform
sufficient input validation on the cipher and tag length fields of
AuthEnvelopedData containers, leading to various potential compromises.
Impact Summary: Attackers making use of these vulnerabilities may achieve
key-equivalent functionality for a given CMS recipient and/or bypass integrity
validation for a given message.
In one use case, an attacker may send a CMS message containing
AuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSL
erroneously allows this selection, and attempts to decrypt and validate the
message.
An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData
addressed to the victim can re-emit it with the recipientInfos set left
byte-for-byte intact, so the victim's private key still unwraps the genuine CEK
(the content-encryption key), but with the inner OID rewritten to AES-256-OFB
(Output Feedback Mode, an unauthenticated keystream mode) and with an
attacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the
real CEK, never consults the MAC field, and CMS_decrypt() returns success.
If the application under attack responds to the attacker with any indicator
showing success or failure of the decryption effort, it is possible for the
attacker to use this as an oracle to obtain key equivalent functionality for the
CEK used for the chosen recipient of the message.
In another use case, an attacker can reduce the tag length of the chosen AEAD
cipher for a given AuthEnvelopedData container to be a single byte long,
allowing an attacker to brute force CMS decryption, producing an integrity
bypass for applications that trust CMS_decrypt() to reject modified content.
The FIPS modules are not affected by this issue.
CVSS 9.1
Unbounded Memory Growth in the QUIC PATH_CHALLENGE Handler
Issue summary: Remote peer may exhaust heap memory of the QUIC
server or client by flooding it with packets containing PATH_CHALLENGE
frames.
Impact summary: A malicious remote peer can cause an unbounded
memory allocation which can lead to an abnormal termination of the
application acting as a QUIC client or server and a Denial of Service.
A remote peer may exhaust heap memory by flooding the local
QUIC stack with PATH_CHALLENGE frames. The local QUIC stack
allocates a PATH_RESPONSE frame for every PATH_CHALLENGE it receives.
The allocated PATH_RESPONSE frame gets freed only when the remote
peer acknowledges reception of the PATH_RESPONSE frame which will
not be done by a malicious peer.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by
this issue. The QUIC stack is outside of OpenSSL FIPS module
boundary.
CVSS 7.5
OpenSSL - Possible NULL Dereference in Password-Based CMS Decryption
Issue summary: A specially crafted password-encrypted CMS message
can trigger a NULL pointer dereference during CMS decryption.
Impact summary: This NULL pointer dereference leads to an application crash
and a Denial of Service.
The CMS PasswordRecipientInfo.keyDerivationAlgorithm field is defined as
OPTIONAL in the ASN.1 specification and may therefore be absent in specially
crafted inputs. During the password-based CMS decryption the OpenSSL
CMS implementation dereferences this field without first checking whether it
was present.
An attacker who supplies such a CMS message to an application performing
password-based CMS decryption can trigger an application crash, leading to
a Denial of Service.
Applications that process password-encrypted CMS messages may be 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.
CVSS 5.9
OpenSSL - NULL Pointer Dereference in CRMF EncryptedValue Decryption
Issue summary: An attacker-controlled CMP (Certificate Management Protocol)
server could trigger a NULL pointer dereference in a CMP client application.
Impact summary: A NULL pointer dereference causes a crash of the
application and a Denial of Service.
An attacker controlling a CMP server (or acting as a man-in-the-middle) could
craft a CMP response containing a CRMF (Certificate Request Message Format)
CertRepMessage with an EncryptedValue structure where the symmAlg field
has an algorithm OID but no parameters field. When the OpenSSL CMP client
processes this response, the NULL dereference occurs, causing a crash of
the CMP client.
Applications that process untrusted CMP/CRMF messages may be 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.
CVSS 5.9
Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()
Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to
Bleichenbacher-style attack when an attacker is able to provide the CMS or
S/MIME messages and observe the error code and/or decryption output.
Impact summary: The Bleichenbacher-style attack allows an attacker to use the
victim's vulnerable application as a way to decrypt or sign messages with the
victim's private RSA key.
The attack is possible in 2 variants.
1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without
providing the recipient certificate. In this case OpenSSL iterates over every
KeyTransRecipientInfo (KTRI) without stopping at the first success.
An attacker who authors a message with two KTRI entries — the first one
wrapping a real CEK under the victim's public key, the second with an
arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to
get a valid PKCS#1 v1.5 padding if the error code of the application is
available.
That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an
adaptive-chosen-ciphertext side channel from which the attacker decrypts any
RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under
it.
2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with
the recipient certificate, and the recipient is not found, a random
key is substituted.
An attacker who authors a message and is able to compare both error code and
the result of the decryption, can mount a Bleichenbacher oracle.
We are not aware of any applications that provide a remote attacker
an opportunity to mount an attack described in these scenarios. We consider
the existence of such application very unlikely, and for this reason this
CVE has been evaluated as Low severity.
To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the
invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described
in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit
rejection was explicitly disabled.
The implicit rejection mechanism always returns a plaintext value,
the symmetric key. This result is deterministic for the ciphertext and the
private key. The length of the decryption result can happen to match the
length of the key of the symmetric cipher that was used for the content
encryption. When a certificate is not provided, the last RecipientInfo
producing a key that looks valid will be used. It may cause getting garbage
content on decryption. As a proper way to deal with this a recipient
certificate has to be provided to identify the particular RecipientInfo for
decryption.
The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as
CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.
CVSS 3.7
Trust-Anchor Substitution via cert/issuer Typo in CMP rootCaKeyUpdate
Issue Summary: An error in the callback used to verify the certificate
provided in a Root CA key update Certificate Management Protocol (CMP)
message response rendered the certificate validation ineffectual, which
could lead to escalation of credentials from the Registration Authority (RA)
level to the root Certification Authority (root CA) level.
Impact Summary: The Registration Autority could replace the root CA
certificate for the CMP clients with an arbitrary root CA certificate.
One of the parts of the Certificate Management Protocol (CMP), specified in
RFC 9810, is Root Certification Authority (root CA) key Rollover,
which is sent by the server in a message with type 'id-it-rootCaKeyUpdate'.
As part of these messages, 'newWithOld' certificate, the new root CA
certificate signed with the old root CA key, is provided, and verifying its
signature is crucial for transferring the trust from the old CA key to the
new one.
The 'id-it-rootCaKeyUpdate' messages are expected to be processed with
OSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the 'newWithOld'
certificate. A typo in the certificate chain building code led to adding
an incorrect certificate ('newWithOld' instead of 'oldRoot') to the
certificate chain, rendering the certificate verification process ineffectual
(only the issuer name and the algorithm OIDs were verified by other parts
of the verification code).
An attacker who already has credentials that satisfy the CMP message
protection checks can generate a new key pair and use a crafted self-signed
certificate in its 'id-it-rootCaKeyUpdate' CMP messages which affected CMP
clients would accept as a new trust anchor.
Significant preconditions for the attack (having valid RA-level credentials)
are the reason the issue was assigned Low severity.
The FIPS modules are not affected by this issue, as the affected code is
outside the OpenSSL FIPS module boundary.
CVSS 5.3
OpenSSL - FFC-DH Peer Validation Uses Attacker-Supplied Q
Issue 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, and 3.0 are affected by this
issue.
CVSS 3.7
OpenSSL - AES-OCB IV Ignored on EVP_Cipher() Path
Issue 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.
CVSS 7.5
Incorrect Tag Processing for Empty Messages in AES-GCM-SIV and AES-SIV modes
Issue 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.
CVSS 4.8
Heap Use-After-Free in the PKCS7_verify() Function
Issue 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.
CVSS 8.8
Possible Heap Buffer Overflow in ASN.1 Multibyte String Conversion
Issue summary: A signed integer overflow when sizing the destination
buffer for Unicode output in ASN1_mbstring_ncopy() can lead to a heap
buffer overflow.
Impact summary: A heap buffer overflow may lead to a crash or possibly
attacker controlled code execution or other undefined behaviour.
In ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destination
size for Unicode output is computed in a signed int: by left shift
of the input character count for BMPSTRING (UTF-16) and
UNIVERSALSTRING (UTF-32), and by summing per-character byte counts
for UTF8STRING. The calculation overflows when the input reaches
around 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30
characters) the size wraps to zero, OPENSSL_malloc(1) is called, and
the subsequent character copy writes several gigabytes past the
one-byte allocation.
X.509 certificate processing routes through ASN1_STRING_set_by_NID(),
whose DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NID
size limits cap the input length; no network protocol or
certificate-handling path in OpenSSL exercises the overflow.
Triggering the bug requires an application that calls
ASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registers
a custom string type via ASN1_STRING_TABLE_add(), with
attacker-controlled input on the order of half a gigabyte or more.
For these reasons this issue was assigned Low severity.
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.
CVSS 8.1
Out-of-Bounds Read in CMS Password-Based Decryption
Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap)
processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK
cipher can trigger a heap out-of-bounds read in kek_unwrap_key().
Impact summary: A heap buffer over-read may trigger a crash which leads to
Denial of Service for an application if the input buffer ends at a memory
page boundary and the following page is unmapped. There is no information
disclosure as the over-read bytes are not revealed to the attacker.
The key unwrapping function performs a check-byte test as specified in the
RFC that reads 7 bytes from a heap allocation that is based on the wrapped
key length from the message. There is a minimum length check based on the
block length of the wrapping cipher. However the cipher is selected from
an OID carried in the attacker's PWRI keyEncryptionAlgorithm with no
requirement that the cipher be a block cipher. When an attacker selects
a stream-mode cipher the guard will be ineffective and the allocated buffer
containing the unwrapped key can be too small to fit the check-bytes
specified in the RFC and a buffer over-read can happen.
Applications calling CMS_decrypt() or CMS_decrypt_set1_password()
(equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMS
data are vulnerable to this issue. No password knowledge is required: the
over-read happens during the unwrap attempt before any authentication
succeeds.
The over-read is limited to a few bytes and is not written to output, so
there is no information disclosure. Triggering a crash requires the
allocation to border unmapped memory, which is unlikely with the normal
allocator.
The FIPS modules are not affected by this issue.
CVSS 7.5
ESF-IDF: Out-of-bounds Read in lwIP DHCP Server Option Parser
ESF-IDF is the Espressif Internet of Things (IOT) Development Framework. In versions 5.2.7, 5.3.5, 5.4.4, 5.5.4, and 6.0.1, an out-of-bounds read flaw exists in the DHCP server option parser (parse_options() in components/lwip/apps/dhcpserver/dhcpserver.c) shipped with ESP-IDF's lwIP component. The parser walks the BOOTP/DHCP options field without validating that each option's length byte and declared payload length stay within the received packet buffer. A crafted DHCP request can cause the parser to read past the end of the options buffer into adjacent heap memory. The issue affects the DHCP server used by ESP-IDF's SoftAP and any configuration where the device runs as a DHCP server on a local network. This issue has been patched in versions 5.2.8, 5.3.6, 5.4.5, 5.5.5, and 6.0.2.
CVSS 6.5
By Source