CVE-2025-61730

What it actually does

The vulnerability exists in the Go standard library's implementation of the TLS 1.3 handshake. If an attacker can send multiple handshake messages within single TLS records that span an encryption level boundary (e.g., from unencrypted to encrypted), the receiving endpoint may process a message before the encryption context is properly updated. This race condition can cause the endpoint to incorrectly process an encrypted message as if it were plaintext, leading to the disclosure of small amounts of sensitive handshake data.

Why it matters to the business

Exploitation could lead to the leakage of minor amounts of sensitive data transmitted during the initial setup of a secure connection. While the direct impact is low, it erodes the confidentiality guarantees of the TLS protocol, potentially violating compliance requirements or exposing metadata about secure sessions. The vulnerability affects a wide range of applications built with vulnerable versions of Go, including popular infrastructure tools like HashiCorp Vault, increasing the potential attack surface across the organization.

How an attack unfolds

A network-local attacker, positioned as a Man-in-the-Middle (MitM) between a client and server, can exploit this flaw. During a TLS 1.3 handshake between two endpoints using vulnerable Go-based applications, the attacker intercepts the traffic. The attacker then crafts and injects specific TLS records containing multiple handshake messages that are deliberately framed to cross an encryption boundary. This manipulation tricks the receiving endpoint into processing a message, such as the Encrypted Extensions, before it has switched to the new encryption keys. As a result, the contents of that message, which should be confidential, are processed incorrectly and may be exposed to the attacker monitoring the session.

How to fix it

The vulnerability is resolved by updating the underlying Go language runtime and rebuilding affected applications. For users of pre-compiled software, upgrade to a version that incorporates the fix. Specifically, update MinimOS packages for `vault`, `vault-oci-entrypoint`, and `vault-doc` to version `1.21.0-r1` or later. For developers building applications with Go, update the Go toolchain to a version including commit `63a1b82d1e68ddd87652467303901593efe0ff11` or a subsequent official release, and then recompile and redeploy all Go-based applications.

How to confirm the fix worked

To validate the fix, verify that all Go-based applications are running versions built with a patched Go compiler. For packaged software like HashiCorp Vault, check the installed version against the fixed versions specified by the vendor (e.g., `vault` version `1.21.0-r1` or newer). For custom-built applications, run `go version` on the build server to confirm the toolchain is patched, and inspect the running binary's build information if available (e.g., using `go version -m <binary>`). Network-level validation is complex and would require a specialized TLS testing tool capable of simulating the specific handshake message injection attack.

Typical attack path

1. Attacker gains a Man-in-the-Middle (MitM) position on the network between a client and a server running an application built with a vulnerable Go version.
2. The client initiates a TLS 1.3 handshake with the server.
3. The attacker intercepts the handshake traffic and injects specially crafted TLS records.
4. The malicious records contain multiple handshake messages designed to span an encryption boundary.
5. The vulnerable endpoint incorrectly processes a message at the wrong encryption level, before keys are updated.
6. The attacker captures the disclosed handshake information from the network traffic.

How to detect it

Detecting exploitation of this vulnerability is difficult as it requires deep inspection and stateful analysis of TLS 1.3 handshake traffic. Anomaly detection on TLS sessions might flag malformed or unusual handshake sequences. Network security monitoring (NSM) tools and Intrusion Detection Systems (IDS) with advanced TLS parsing capabilities may be able to identify the specific injection pattern if a signature is developed. Look for TLS 1.3 handshakes where single records contain multiple distinct handshake messages that cross encryption boundaries. There are no post-exploitation artifacts on the host itself, as the attack is confined to the network layer.

What your security team should do

• Prioritize patching internet-facing systems and critical internal services built with Go, such as HashiCorp Vault, to prevent potential information disclosure.
• Identify all applications within the environment that are built using Go and determine which are using a vulnerable version of the standard library.
• Update affected MinimOS packages (`vault`, `vault-oci-entrypoint`, `vault-doc`) to version `1.21.0-r1` or later.
• For internal development teams, mandate an upgrade of the Go compiler to a patched version and trigger a rebuild and redeployment of all Go applications.