crypto/tls at a glance
Show as table
| Month | Vulnerabilities | Critical |
|---|---|---|
| Nov 2026 | 0 | 0 |
| Oct 2026 | 1 | 0 |
| Sep 2026 | 0 | 0 |
| Aug 2026 | 1 | 0 |
| Jul 2026 | 1 | 0 |
| Jun 2026 | 0 | 0 |
| May 2026 | 0 | 0 |
| Apr 2026 | 1 | 0 |
| Mar 2026 | 0 | 0 |
| Feb 2026 | 1 | 1 |
| Jan 2026 | 1 | 0 |
| Dec 2025 | 0 | 0 |
| Nov 2025 | 0 | 0 |
| Oct 2025 | 1 | 0 |
| Sep 2025 | 0 | 0 |
| Aug 2025 | 0 | 0 |
| Jul 2025 | 0 | 0 |
| Jun 2025 | 0 | 0 |
| May 2025 | 0 | 0 |
| Apr 2025 | 0 | 0 |
| Mar 2025 | 0 | 0 |
| Feb 2025 | 0 | 0 |
| Jan 2025 | 0 | 0 |
| Dec 2024 | 0 | 0 |
13 results · Feed
-
High 7.5
Reject malformed ECH outer extension references in crypto/tls
Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted packet that could trigger memory exhaustion in the server process by specifying multiple references. We now reject these as malformed and …
-
High 7.5
Limit handshake messages we are willing to accept post-handshake in crypto/tls
Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key deriva…
-
Medium 5.3
Invoking Encrypted Client Hello privacy leak in crypto/tls
Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.
-
High 7.5
Unauthenticated TLS 1.3 KeyUpdate record can cause persistent connection retention and DoS in crypto/tls
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.
-
Critical 9.1
Unexpected session resumption in crypto/tls
During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user ca…
-
Medium 5.3
Handshake messages may be processed at the incorrect encryption level in crypto/tls
During the TLS 1.3 handshake if multiple messages are sent in records that span encryption level boundaries (for instance the Client Hello and Encrypted Extensions messages), the subsequent messages may be processed before the encryption level changes. This c…
-
Medium 5.3
ALPN negotiation error contains attacker controlled information in crypto/tls
When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.
-
Unscored —
Before Go 1.20, the RSA based key exchange methods in crypto/tls may exhibit a timing side channel
Before Go 1.20, the RSA based TLS key exchanges used the math/big library, which is not constant time. RSA blinding was applied to prevent timing attacks, but analysis shows this may not have been fully effective. In particular it appears as if the removal of…
-
Unscored —
Memory exhaustion in QUIC connection handling in crypto/tls
QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now consistently reject messages larger than 65KiB in …
-
Unscored —
Panic when processing post-handshake message on QUIC connections in crypto/tls
Processing an incomplete post-handshake message for a QUIC connection can cause a panic.
-
Unscored —CVE-2023-29409 Public exploit
Large RSA keys can cause high CPU usage in crypto/tls
Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to <= 8192 bits. Based on a survey of publicly trusted RSA…
-
Unscored —
Panic on large handshake records in crypto/tls
Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 cli…
-
Low 3.1
Session tickets lack random ticket_age_add in crypto/tls
Non-random values for ticket_age_add in session tickets in crypto/tls before Go 1.17.11 and Go 1.18.3 allow an attacker that can observe TLS handshakes to correlate successive connections by comparing ticket ages during session resumption.