CVE-2026-107928 in curl
Summary
by MITRE • 10/21/2026
When curl is built with GnuTLS, a malicious WebSocket server can make curl send memory past its send buffer. This is due to an out of bounds read following when `gnutls_record_send()` returns a number of bytes sent **greater than the number of bytes it was given to send**. GnuTLS does that after a blocked send.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in curl, specifically when compiled with the GnuTLS transport layer security library, represents a critical memory safety flaw within the WebSocket implementation. This issue arises from an improper handling of return values during encrypted data transmission operations. The core technical defect is classified as an out-of-bounds read, which corresponds to CWE-125 in common vulnerability enumeration standards. The root cause lies in how curl processes the feedback from the underlying GnuTLS function gnutls_record_send(). Under normal circumstances, this function returns the number of bytes successfully transmitted or a negative error code if transmission fails. However, under specific network conditions involving blocked sends, GnuTLS may return a positive value that exceeds the size of the buffer originally provided for sending. This anomalous behavior is not necessarily indicative of successful data transfer but rather reflects internal state management within the TLS library during blocking operations.
Curl's WebSocket implementation failed to adequately validate this return value against the actual amount of data queued or intended for transmission. By trusting that the number returned by gnutls_record_send() accurately represents the bytes consumed from its own send buffer, curl proceeds with subsequent memory access logic based on this inflated count. Consequently, when the application attempts to manage internal buffers or update pointers relative to the reported byte count, it accesses memory locations beyond the allocated boundaries of the current send buffer. This out-of-bounds read allows a malicious WebSocket server, which controls the network conditions and potentially influences the TLS handshake or record fragmentation timing, to trigger this state. The attacker can force curl into a condition where blocked sends occur frequently enough that GnuTLS returns these exaggerated byte counts repeatedly.
The operational impact of this vulnerability is primarily centered on information disclosure through memory content leakage. Because the flaw involves an out-of-bounds read rather than a write operation, it does not directly enable arbitrary code execution or remote control of the host system in most scenarios. Instead, curl may inadvertently expose sensitive data residing in adjacent memory regions to the network stream or internal logs depending on how the leaked bytes are processed. This could include private keys, authentication tokens, session cookies, or other confidential information previously loaded into the process memory space. The severity is heightened by the fact that WebSocket connections often maintain persistent state and handle significant volumes of data, increasing the likelihood of encountering the specific blocking conditions required to trigger this bug. From a threat modeling perspective using MITRE ATT&CK frameworks, this behavior aligns with techniques related to unauthorized access to system information or memory scraping, although it is limited by the read-only nature of the flaw.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary solution involves upgrading curl to a version where the WebSocket TLS handling logic has been patched to strictly validate that the bytes reported as sent do not exceed the actual buffer size provided to gnutls_record_send(). If an upgrade is not immediately feasible, administrators should consider disabling GnuTLS support in favor of OpenSSL or other transport libraries if those alternatives demonstrate more robust return value handling for similar operations. Additionally, developers integrating curl into larger applications should implement strict input validation and ensure that all network-facing components are updated to the latest stable releases. Security teams should monitor for unusual memory access patterns or anomalies in WebSocket traffic logs that might indicate exploitation attempts. Regular auditing of third-party library integrations is essential to prevent similar logic errors where assumptions about underlying cryptographic libraries' behavior lead to boundary violations.