Filipe Casal

**Name of the Vulnerable Software and Affected Versions** OpenSSL (affected versions not specified) **Description** A NULL pointer dereference can occur in server or client configurations where RFC7250 Raw Public Keys (RPKs) are enabled and only a private key is configured locally without an associated certificate. This happens when a remote peer requests raw public keys and includes the `signature algorithms cert` TLS extension. This issue can lead to a Denial of Service (DoS) due to an application abort. A NULL pointer dereference is a software error where the program attempts to read or write to a memory address that is NULL, typically causing the application to crash. **Recommendations** Update to an updated release. As a mitigation measure, configure a corresponding certificate (self-signed or signed by a CA) alongside the private key to ensure the `signature algorithms cert` extension is handled reliably.

**Name of the Vulnerable Software and Affected Versions** OpenSSL (affected versions not specified) **Description** An issue exists in the CMP response validation where the `ossl cmp msg check update()` function converts a peer-supplied sender distinguished name using `X509 NAME oneline()` and passes it directly as the format argument to `ERR raise data()`. Because percent characters are preserved during conversion, a malicious or intercepted CMP endpoint can provide a sender DN containing format specifiers like `%s` or `%n`. These specifiers reach `BIO vsnprintf()` without matching variadic arguments, causing the client to dereference or write through unrelated stack contents. This leads to a denial of service by crashing the CMP client, specifically when the client enforces an expected sender or uses a pinned server certificate. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions 3.5 and later **Description** An OpenSSL QUIC server can allocate and queue new incoming channels without enforcing a limit when processing valid QUIC Initial packets for unknown destination connection IDs. The system uses the `Connection-Id` from the packet header to locate an existing connection; if none is found and the packet type is INITIAL, a new channel object is allocated and queued to be accepted by the local application via the `SSL accept()` function. If the application cannot call `SSL accept()` frequently enough, the memory used for these channel objects can grow without bounds, potentially leading to a Denial of Service by making the QUIC listener unavailable. **Recommendations** Update OpenSSL to a version that implements a limit for pending connections. Applications can adjust the default limit of 256 pending connections by using the `SSL set value uint()` function.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions prior to 3.0.22 OpenSSL versions prior to 3.4.7 OpenSSL versions prior to 3.5.8 OpenSSL versions prior to 3.6.4 OpenSSL versions prior to 4.0.2 OpenSSL version 1.1.1 **Description** An 8-byte out-of-bounds heap write occurs during CMS decryption when the key-unwrap output buffer is sized based on the queried unwrapped key size, but the AES-WRAP-PAD unwrap primitive writes more bytes than reported. An attacker can trigger this by supplying a crafted CMS message and modifying a single OID byte to select the padded variant. This leads to heap corruption and typically results in a Denial of Service. The issue is reachable via the `CMS decrypt()` function. **Recommendations** Upgrade to version 3.0.22. Upgrade to version 3.4.7. Upgrade to version 3.5.8. Upgrade to version 3.6.4. Upgrade to version 4.0.2. As a temporary workaround, restrict the use of the `CMS decrypt()` function when processing untrusted CMS messages.

**Name of the Vulnerable Software and Affected Versions** libcurl (affected versions not specified) **Description** An issue exists in the certificate authentication procedure where the library maintains a connection pool for reusing connections in subsequent transfers. If a handle initially uses the default native CA trust and is later switched to custom CA material, it may continue to trust the native platform store for subsequent transfers using that handle. This could allow a remote attacker to perform data spoofing or gain unauthorized access to protected information. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.