Hello,

CERT/CC published three vulnerability notes on 13 and 14 October 2026 about how open-source TLS/X.509 libraries enforce Name Constraints (RFC 5280 section 4.2.1.10). I reported the findings. This is a summary of public fixes and statuses; it does not announce new CVEs.

https://kb.cert.org/vuls/id/573195 https://kb.cert.org/vuls/id/948176 https://kb.cert.org/vuls/id/410595

The differences fall into four areas: DNS-name comparison (RFC 5280 requires case-insensitive matching), IP addresses (the RFC does not say whether IPv4-mapped IPv6 should be treated as IPv4), URI-authority parsing, and wildcards (the RFC does not define wildcard SAN semantics).

Fixed or merged:

pyca/cryptography CVE-2026-34073, fixed in 46.0.6. DNS constraints were checked against the certificate's SANs but not against the requested peer name. GHSA-m959-cc7f-wv43 rustls/webpki wildcards under permitted subtrees: CVE-2026-93601, fixed in 0.103.12 / 0.104.0-alpha.6 (GHSA-xgp8-3hg3-c2mh). Unsupported URI constraints were accepted: CVE-2026-93600, first fix in 0.103.12 / 0.104.0-alpha.6, excludedSubtrees case completed in 0.103.13 / 0.104.0-alpha.7 (GHSA-965h-392x-2mh5). GnuTLS CVE-2026-3833, fixed in 3.8.13. DNS names and the domain part of rfc822Name constraints compared case-sensitively. Independently co-reported. wolfSSL CVE-2026-5263, fixed in 5.9.1: URI constraints parsed but not enforced. Fragment wildcards (e.g. foo.com): PR 9991, in 5.9.1. Note: VU#948176 cites CVE-2026-3547 for the URI report; that CVE record describes an ALPN parsing issue. AWS-LC wildcard Common Name fallback fixed in 1.71.0 / aws-lc-sys 0.39.0 (GHSA-3jrg-j22w-mpmc, GHSA-394x-vwmw-crm3). The same advisory covers Unicode CN; VU#948176 lists that report as still under coordination. Go crypto/x509 CVE-2026-33810, fixed in Go 1.26.2 (GO-2026-4866, co-credited): case handling in wildcard parent-constraint lookup. OpenSSL URI authority: the userinfo scan for @ ran past /, ? or #. PR #30319; OpenSSL confirmed on 2026-09-10 that it is in all then-supported versions. BoringSSL VU#410595.8 (wildcard vs excluded host) and .12 (trailing-dot DNS names) fixed upstream in commit 5774eca (2026-03-04), legacy crypto/x509 path.

Open, disputed or declined (per the notes):

Go two reports in triage; IPv4-mapped IPv6 report not accepted as meeting the security bar OpenSSL userinfo-colon report in triage BoringSSL .9 accepted (upstream change b84dc60, 2026-05-05), .10 disputed, .11 declined Mozilla NSS IP-address report under coordination LibreSSL wildcard report under coordination s2n-tls Common Name fallback report in triage Mbed TLS non-critical Name Constraints not enforced in the reported configuration; vendor treats support as a feature request, reporter's concern disputed

Conditions, according to CERT/CC: an attacker needs a trusted signature over chosen certificate fields, an affected validation path must be reachable, and the application must use the accepted name for authorization. The notes do not report exploitation. Using one of these libraries does not by itself mean a product reaches an affected path.

No test vectors are published for anything not fixed.

Per-finding status with dated sources: https://paperlock.org/findings/

Regards, Oleh Konko 1seal - https://1seal.org/research/

OpenSSL Security Advisory [29th September 2026] ===============================================

DTLS Retransmits Handshake Messages From a Stale Buffer Offset (CVE-2026-84782) ===============================================================================

Severity: High

Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly.

Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region.

CWE: CWE-125: Out-of-bounds Read

Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANTWRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.

The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer.

Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSLread(), SSLwrite(), SSLaccept(), or SSLconnect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build.

The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead.

FIPS impact: no The affected code is outside the FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to 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

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23 OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zj OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zs

This issue was reported on 17 August 2026 by Laurent Gaffie (secorizon.com). The fix has been developed by Ryan Hooper.

Use-After-Free in X.509 Extension Cache Under Concurrent Use (CVE-2026-84783) =============================================================================

Severity: Moderate

Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it.

Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service.

CWE: CWE-416: Use After Free

Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory.

Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time.

FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary.

OpenSSL 4.0 is vulnerable to this issue.

OpenSSL 3.6, 3.5, 3.4, 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.

This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan.

The fix has been developed by Bob Beck.

Excessive Memory Allocation in Relative CRLDP Processing (CVE-2026-35189) =========================================================================

Severity: Low

Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions.

Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates.

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations.

The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received.

FIPS impact: no The affected code is outside the FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to 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.

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zj. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zs.

This issue was reported on 29 Jul 2026 by Fuzz0x (ZKSC Institute of Security Research). The fix has been developed by Viktor Dukhovni.

QUIC Unvalidated Amplification Credit may be Over Accounted (CVE-2026-35191) ============================================================================

Severity: Low

Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received.

Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack.

CWE: CWE-440: Expected Behavior Violation

Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed.

The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC.

FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.

OpenSSL 4.0, 3.6, 3.5 are vulnerable to this issue.

OpenSSL 3.4, 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.

This issue was reported on 13 June 2026 by Ali Firas and independently on 22 August 2026 by Nikolas Gauder (NVIDIA). The fix has been developed by Neil Horman.

Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC (CVE-2026-42772) =========================================================================

Severity: Low

Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data.

Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth.

CWE: CWE-407: Inefficient Algorithmic Complexity

Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current tail.

By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process.

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5, and 3.4 are vulnerable to this issue.

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 20 April 2026 by Saku0512 and on 29 June 2026 by Opal Wright (Trail of Bits) in collaboration with OpenAI.

The fix has been developed by Alexandr Nedvedicky.

Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves (CVE-2026-54872) ====================================================================================

Severity: Low

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.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to 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.

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zj. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zs.

This issue was identified during Minerva-style analysis by Alicja Kario and George Pantelakis (Red Hat) based on the report of Youngjae Choi (Korea University), dated 20 January 2026. The fix was developed by Igor Ustinov.

QUIC STREAM Fragment Metadata DoS (CVE-2026-54873) ==================================================

Severity: Low

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.

OpenSSL 4.0, 3.6, 3.5, and 3.4 are vulnerable to this issue.

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 28 May 2026 by Zhen Yan (AntAISecurityLab), and on 13 July 2026 by Bhabani Sankar Das. The fix has been developed by Alexandr Nedvedicky.

Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V (CVE-2026-54875) ================================================================================

Severity: Low

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.

Out-of-Bounds Access After SSLsetSSLCTX() During a Handshake (CVE-2026-72897) ================================================================================

Severity: Low

Issue summary: A TLS server that calls SSLsetSSLCTX() to switch a connection to a different SSLCTX 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 SSLsetSSLCTX() 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 SSLCTX 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 SSLCTX part way through the handshake by calling SSLsetSSLCTX(), 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.

OpenSSL 4.0, 3.6, 3.5, and 3.4 are vulnerable to this issue.

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 25 June 2026 by Filipe Casal (Trail of Bits) in collaboration with OpenAI and independently by Brandon Luo on 22 July 2026, Luigino Camastra (Aisle Research) on 6 August 2026 and Bhargava Shastry on 11 September 2026. The fix has been developed by Matt Caswell.

QUIC Connection-Level Flow Control is Not Enforced for Streams (CVE-2026-75804) ===============================================================================

Severity: Low

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 MAXSTREAMS x (stream flow control limit) bytes of memory. MAXSTREAMS 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.

OpenSSL 4.0, 3.6, 3.5, 3.4 are vulnerable to this issue.

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 20 July 2026 by Moltenbit, independently on 11 August 2026 by Bhabani Sankar Das, on 25 August 2026 by Saiyowa Security Team and on 23 September 2026 by mzfr. The fix has been developed by Alexandr Nedvedicky.

NULL Pointer Dereference in CMP Client Revocation Response Handling (CVE-2026-75805) ====================================================================================

Severity: Low

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 OSSLCMPexecRRses() with the certificate supplied via OSSLCMPCTXset1p10CSR() 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.

OpenSSL 4.0, 3.6, 3.5, 3.4, and 3.0 are vulnerable to this issue.

OpenSSL 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

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23

This issue was reported on 21 July 2026 by Bhabani Sankar Das. The fix has been developed by Bhabani Sankar Das and Norbert Pocs.

Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS (CVE-2026-75806) ===============================================================================

Severity: Low

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 internalerror alert instead of treating the record as one that failed authentication.

In TLS 1.2 the same record causes a fatal internalerror alert instead of the expected badrecordmac 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 badrecordmac and DTLS silently discards the record.

FIPS impact: no The affected code is outside the FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is 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.

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zj.

This issue was reported on 10 August 2026 by Mounir Idrassi. The fix has been developed by Mounir Idrassi.

Timing Side-Channel in SM2 Signature Generation (CVE-2026-77696) ================================================================

Severity: Low

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.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is 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.

Premium support customers only: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.23. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zj.

This issue was reported on 7 May 2026 by Vladimir Tokarev. The fix was developed by Igor Ustinov and Viktor Dukhovni.

QUIC: Unbounded RETIRECONNECTIONID Backlog (CVE-2026-84784) =============================================================

Severity: Low

Issue summary: A malicious remote peer may flood the local QUIC stack with NEWCONNECTIONID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Impact summary: The local QUIC stack sends a RETIRECONNID frame for every NEWCONNECTIONID frame it receives. The RETIRECONNID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).

CWE: CWE-770: Allocation of Resources Without Limits or Throttling

Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEWCONNECTIONID and RETIRECONNECTIONID frames to identify the CID which is being either associated with a connection or retired.

The remote peer sends a NEWCONNECTIONID frame to let the local stack know a new CID is being associated with an existing connection. The NEWCONNECTIONID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRECONNECTIONID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRECONNECTIONID frame.

Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRECONNECTIONID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEWCONNECTIONID, while in fact the destination CID must be retired after an ACK for the RETIRECONNECTIONID frame is received. Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue.

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 26 August 2026 by Bhabani Sankar Das.

General Advisory Notes ======================

URL for this Security Advisory: https://openssl-library.org/news/secadv/20260929.txt

Note: the online version of the advisory may be updated with additional details over time.

Only currently supported releases have been analysed. OpenSSL 3.1, 3.2 and 3.3 are out of support and have not been analysed.

For details of OpenSSL severity classifications please see: https://openssl-library.org/policies/general/security-policy/

Issue summary: A malicious remote peer may flood the local QUIC stack with NEWCONNECTIONID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.

Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it.

Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service.

CWE: CWE-416: Use After Free

Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory.

Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time.

FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary.

OpenSSL 4.0 is vulnerable to this issue.

OpenSSL 3.6, 3.5, 3.4, 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.

This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan.

The fix has been developed by Bob Beck.

-- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck

DTLS Retransmits Handshake Messages From a Stale Buffer Offset

Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel.

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 internalerror alert instead of treating the record as one that failed authentication.

In TLS 1.2 the same record causes a fatal internalerror alert instead of the expected badrecordmac 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 badrecordmac and DTLS silently discards the record.

FIPS impact: no The affected code is outside the FIPS module boundary.

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.

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.

Issue summary: A TLS server that calls SSLsetSSLCTX() to switch a connection to a different SSLCTX 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 SSLsetSSLCTX() are not affected.

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.

Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary.

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.

Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data.

Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received.

Excessive Memory Allocation in Relative CRLDP Processing

OpenSSL Release Announcement

The OpenSSL project team would like to announce the upcoming release of OpenSSL versions 4.0.3, 3.6.5, 3.5.9, and 3.4.8.

We will also be releasing extended support for OpenSSL versions 3.0.23, 1.1.1zj, and 1.0.2zs which will be available to premium support customers.

These releases will be made available on Tuesday, 29 September 2026, between 1300 and 1700 UTC.

These are security-fix releases. The highest severity issue fixed in these releases is High:

https://openssl-library.org/policies/general/security-policy/index.html

Yours

The OpenSSL Project Team

A double free in the OpenSSL-based TLS certificate revocation checking path of the MongoDB C Driver can be reached by a TLS endpoint that the client already trusts. During the handshake, specially formed certificate data can cause the same heap object to be released twice. An unauthenticated party acting as the trusted endpoint may cause the connecting client application to terminate unexpectedly.

opensslencrypt before 1.4.9 fails to validate KDF cost parameters in encrypted file metadata and keystore headers, allowing attackers to trigger unbounded memory allocation. Attackers can craft malicious encrypted files declaring arbitrarily large Argon2, scrypt, or balloon KDF parameters to exhaust system memory and crash the process without authentication.

opensslencrypt versions before 1.4.9 use under-parameterized PBKDF2-HMAC-SHA256 with only 100,000 iterations to protect PQC keyfile private keys and 10,000 iterations for dual-encryption file-password verification. Attackers who obtain keyfiles or encrypted files can brute-force wrapping passwords offline using GPU or ASIC acceleration.

opensslencrypt before 1.4.9 fails to sanitize the email field of imported identity documents, allowing attackers to inject ANSI escape sequences that forge the fingerprint verification line displayed to users. Attackers can deliver a crafted identity bundle through normal contact-exchange flows or keyserver responses to manipulate terminal output and display a fraudulent fingerprint, bypassing the out-of-band verification mechanism that protects against key substitution attacks.

opensslencrypt before 1.4.9 fails to prevent namespace collisions between own identities and contacts in IdentityStore, allowing attackers to create shadowed contact entries invisible until the corresponding own identity is deleted. When the own identity is deleted, the shadowed contact becomes visible and resolves to the attacker's keys, enabling silent key substitution for encrypted files.

opensslencrypt versions before 1.4.9 fail to validate encryption status of embedded post-quantum private keys in file metadata. Attackers can craft files with unencrypted embedded PQC keys that decrypt under any password, bypassing authentication and producing attacker-chosen plaintext with false integrity verification.

opensslencrypt versions before 1.4.9 contain a weak key derivation vulnerability in the D-Bus CryptoService.EncryptFile handler that uses unstretched SHA-256 instead of Argon2id. Attackers can perform offline password guessing against encrypted files roughly six to seven orders of magnitude faster than documented protection by exploiting the missing key stretching and hash rounds.

opensslencrypt before 1.4.9 fails to re-derive and validate fingerprints when loading identities from identity.json, allowing attackers to substitute public keys in identity stores. Attackers can replace legitimate public keys with their own while maintaining the claimed fingerprint, enabling silent key substitution where encryption uses attacker keys and signature verification appears valid.

opensslencrypt versions before 1.4.9 use a denylist to identify trusted built-in plugins, allowing unsigned plugins in top-level plugins/ directories and unknown subdirectories to bypass signature verification. Attackers can place malicious unsigned plugins following documented installation paths to achieve arbitrary code execution in the CLI process with access to passwords and cryptographic keys.

opensslencrypt versions before 1.4.9 fail to properly validate key derivation function costs in crafted files, allowing attackers to trigger unbounded memory and CPU exhaustion during pre-authentication processing. Attackers can supply malicious files with excessive KDF parameters to exhaust system resources and crash or wedge the process before password verification occurs.

opensslencrypt versions before 1.4.9 fail to sanitize terminal control characters in file metadata printed by the info command. Attackers can craft malicious files containing escape sequences to repaint terminal output and forge verification information displayed to users.

opensslencrypt versions before 1.4.9 fail to escape attacker-controlled keyid values printed to stderr during decrypt auto-detection. Attackers can craft encrypted files with malicious keyid containing escape sequences to repaint terminal output and forge authenticity verification blocks.

opensslencrypt versions before 1.4.9 fail to validate server URLs in login and registerwithemail functions, accepting unencrypted http:// URLs and unconfigured hosts. Attackers on the network path can intercept cleartext credentials including clientid, passwords, and JWTs to achieve full keyserver account takeover.