CVE-2025-61730

Published Jan 28, 2026

Last updated 6 months ago

CVSS medium 5.3
Golang
AWS
Splunk
SSL
Tls

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-61730 is a vulnerability found within the `crypto/tls` component of the Go programming language. This flaw involves the processing of handshake messages at an incorrect encryption level. The improper handling of these messages can lead to information disclosure. Patches for this vulnerability were included in Go versions 1.25.6 and 1.24.12.

Description
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 can cause some minor information disclosure if a network-local attacker can inject messages during the handshake.
Source
security@golang.org
NVD status
Analyzed
Products
go

Risk scores

CVSS 3.1

Type
Secondary
Base score
5.3
Impact score
1.4
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Severity
MEDIUM

Weaknesses

nvd@nist.gov
NVD-CWE-noinfo

Social media

Hype score
Not currently trending

  1. 🔍 Lambda Watchdog detected that CVE-2025-61730 is no longer present in latest AWS Lambda base image scans. https://t.co/PMzbSik8k5 #AWS #Lambda #Security #CVE #DevOps #SecOps

    @LambdaWatchdog

    23 Feb 2026

    18 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. 🚨 New HIGH CVE detected in AWS Lambda 🚨 CVE-2025-61730 impacts libcap in 20 Lambda base images. Details: https://t.co/PMzbSik8k5 More: https://t.co/6EUGaPyRZk #AWS #Lambda #CVE #CloudSecurity #Serverless

    @LambdaWatchdog

    8 Feb 2026

    2 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. 🔍 Lambda Watchdog detected that CVE-2025-61730 is no longer present in latest AWS Lambda base image scans. https://t.co/zjgsZtNJU8 #AWS #Lambda #Security #CVE #DevOps #SecOps

    @LambdaWatchdog

    6 Feb 2026

    3 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-61730 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 me… https://t.co/Z377UW1E8D

    @CVEnew

    28 Jan 2026

    162 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🥳 Go 1.26 Release Candidate 2 is released! 🔐 Security: Includes security fixes for archive/zip (CVE-2025-61728), net/http (CVE-2025-61726), crypto/tls (CVE-2025-68121, CVE-2025-61730), cmd/go (CVE-2025-61731, CVE-2025-68119). 🏃‍♀️ Run it in dev! Run it in prod! F

    @golang

    15 Jan 2026

    22045 Impressions

    52 Retweets

    423 Likes

    30 Bookmarks

    4 Replies

    2 Quotes

  6. 🎊 Go 1.25.6 and 1.24.12 are released! 🔐 Security: Includes security fixes for archive/zip (CVE-2025-61728), net/http (CVE-2025-61726), crypto/tls (CVE-2025-68121, CVE-2025-61730), cmd/go (CVE-2025-61731, CVE-2025-68119). 📣 Announcement: https://t.co/seVA1REoeH 📦 Do

    @golang

    15 Jan 2026

    14651 Impressions

    53 Retweets

    279 Likes

    26 Bookmarks

    4 Replies

    3 Quotes

Configurations

Related CVEs

  1. CVE-2024-31884
  2. Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16317
  3. The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16318
  4. In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.•CVE-2026-63978
  5. In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.8, 9.4.13, and 9.3.14, and Splunk Cloud Platform versions below 10.5.2605.0, 10.4.2604.6, 10.2.2510.18, and 10.1.2507.24, a user who holds a role that contains the `edit_local_apps` and `install_apps` capabilities could cause a legitimate app installation to write files outside the intended app directory, into `$SPLUNK_HOME/etc/` and its subdirectories.<br><br>The vulnerability is caused by a path traversal in the app installation workflow, which does not restrict the installation path to the intended app directory.•CVE-2026-20297

References

Sources include official advisories and independent security research.