curl CVE-2026-107928

Exploitation requires that curl be built against the GnuTLS TLS backend (not OpenSSL or other backends) AND with WebSocket support enabled, and that the curl client connect to an attacker-controlled WebSocket server. The specific trigger is a blocked TLS send that causes GnuTLS's gnutls_record_send() to return a byte count greater than the amount it was asked to send; only then does curl read past its send buffer. Limiting factors: the attacker must control or impersonate the WebSocket server the client connects to (client-initiated outbound connection), WebSocket support in curl is experimental and off by default in many builds, and the OpenSSL-backed builds that dominate most deployments are not affected - substantially narrowing the realistically exploitable population despite curl's near-universal presence.

No CVSS vector, EPSS score, KEV listing, or POC is provided in the input, so quantitative exploitation signals are entirely absent and cannot be cross-referenced - this limits confidence in any automated prioritization. Based on the technical description alone, this is a client-side out-of-bounds read (CWE-125) in curl's GnuTLS backend, triggered only when curl connects to a malicious WebSocket server and GnuTLS's gnutls_record_send() over-reports bytes sent after a blocked send. The real-world risk is moderate-to-low: the victim must be the curl client reaching out to attacker-controlled infrastructure, the specific GnuTLS 'bytes sent > bytes given' edge case must occur (a blocked send), and WebSocket support in curl is experimental and infrequently enabled. The primary consequence is disclosure of adjacent process memory being transmitted to the attacker's server (and a possible crash), not remote code execution. Exploitation status: no public exploit identified at time of analysis. This looks like a genuine but niche memory-safety defect worth patching promptly where the vulnerable configuration exists, rather than a mass-exploitation emergency; the absence of EPSS/KEV data should be treated as missing information, not as evidence of safety.

An attacker stands up a malicious WebSocket (wss://) server and lures or redirects a curl client - built against GnuTLS with WebSocket support - into connecting to it. By manipulating TLS flow control to induce a blocked send, the attacker causes gnutls_record_send() to report more bytes written than were supplied, making curl read past its send buffer and transmit adjacent process memory back to the server, leaking potentially sensitive data or crashing the client. No public exploit code is identified at time of analysis.