CVE-2025-10148: Haxx Curl WebSocket Mask Vulnerability

CVE-2025-10148 Overview

CVE-2025-10148 affects the WebSocket implementation in curl, the widely used data transfer library and command-line tool maintained by Haxx. The vulnerability stems from curl reusing a fixed 32-bit mask pattern across every outgoing WebSocket frame instead of generating a fresh, unpredictable mask per frame as required by RFC 6455. A predictable mask enables a malicious WebSocket server to craft payloads that intermediary proxies interpret as legitimate HTTP traffic, poisoning shared proxy caches. Cached poisoned responses can then be delivered to any user routed through the affected proxy.

Critical Impact

A malicious WebSocket server can leverage curl's predictable frame mask to inject attacker-controlled content into shared HTTP proxy caches, exposing all downstream proxy users to poisoned responses.

Affected Products

• curl (Haxx) — versions containing the affected WebSocket implementation
• Applications and tooling linking against vulnerable libcurl builds with WebSocket support enabled
• Distributions packaging affected curl releases prior to the upstream fix

Discovery Timeline

• 2025-09-10 - Coordinated disclosure published on the OpenWall oss-security mailing list
• 2025-09-12 - CVE-2025-10148 published to the National Vulnerability Database (NVD)
• 2026-01-20 - Last updated in NVD database

Technical Details for CVE-2025-10148

Vulnerability Analysis

The WebSocket protocol requires clients to mask every frame sent to a server using a freshly generated 32-bit masking key. The mask exists specifically to prevent client-controlled bytes from aligning with attacker-chosen positions on the wire, which would otherwise enable cross-protocol attacks against intermediaries.

curl's WebSocket code generated a single mask when the connection was established and reused that same value for every outgoing frame for the lifetime of the connection. The mask therefore became predictable to any server that observed even one masked frame, since XOR of known plaintext against ciphertext reveals the key. Once the key is known, a malicious server can predict the exact byte sequence curl will place on the wire for any future frame content.

The practical impact is HTTP cache poisoning. An attacker-controlled WebSocket server can choreograph the client's masked output so that the resulting bytes, when inspected by a transparent or configured proxy that does not fully parse the WebSocket upgrade, resemble a valid HTTP request and response. The proxy may then cache attacker-supplied content under a victim URL and serve that content to other clients.

Root Cause

The defect is a specification compliance failure in the WebSocket frame construction path. curl initialized the mask once per connection rather than per frame, violating RFC 6455 Section 5.3. NVD classifies the weakness as NVD-CWE-noinfo, but the underlying issue maps to insecure use of a predictable value in a security-sensitive protocol field.

Attack Vector

Exploitation requires a victim to initiate a WebSocket connection, using curl or libcurl, to a server controlled by the attacker, with proxy infrastructure sitting in the path. No authentication or user interaction beyond the initial connection is required. The attacker recovers the mask from observed traffic, then composes WebSocket payloads whose post-mask byte stream encodes a forged HTTP request or response targeting the proxy cache. Successful poisoning affects every user of that proxy who later requests the targeted resource.

No public exploit code or proof of concept has been published as of the latest NVD update. See the curl.se CVE-2025-10148 Advisory and HackerOne Report #3330839 for the technical write-up.

Detection Methods for CVE-2025-10148

Indicators of Compromise

• Outbound WebSocket sessions from curl or libcurl-based applications where successive client frames exhibit an identical 32-bit masking key
• Proxy cache entries containing content that does not correspond to any legitimate origin response for the cached URL
• Unexpected HTTP responses served from shared forward or transparent proxies following WebSocket activity by client hosts

Detection Strategies

• Inspect WebSocket traffic at network egress points and flag client-to-server frames whose masking-key field repeats across frames within a single connection
• Inventory installed curl and libcurl versions across endpoints and servers, comparing against the fixed release listed in the vendor advisory
• Correlate proxy cache anomalies with hosts that recently established WebSocket sessions to untrusted destinations

Monitoring Recommendations

• Enable verbose proxy logging that records cache insertions tied to client identifiers, then alert on cache writes whose response headers conflict with the origin server's known behavior
• Monitor for curl-based processes initiating long-lived WebSocket connections to untrusted external endpoints
• Track patch state of curl packages and libcurl-linked applications through software inventory tooling

How to Mitigate CVE-2025-10148

Immediate Actions Required

• Upgrade curl and libcurl to the fixed release identified in the curl.se CVE-2025-10148 Advisory
• Rebuild or repackage downstream applications that statically link libcurl after updating to the patched library
• Audit forward and transparent proxy caches for suspicious entries and purge any content that cannot be validated against the origin

Patch Information

The curl maintainers released a fix that generates a new 32-bit mask for each outgoing WebSocket frame, restoring RFC 6455 compliance. Patch details, affected version ranges, and commit references are published in the curl.se CVE-2025-10148 Advisory and the corresponding JSON advisory data. Linux distributions are tracking backports through their respective security trackers.

Workarounds

• Disable WebSocket functionality in applications that do not require it by building libcurl without WebSocket support until the patched version can be deployed
• Restrict curl-based clients from connecting to untrusted WebSocket endpoints through egress filtering or allowlisting
• Configure intermediary proxies to bypass caching for traffic associated with WebSocket upgrade negotiations

# Verify installed curl version and confirm WebSocket build support
curl --version
curl-config --features | tr ' ' '\n' | grep -i websockets

# Example: rebuild libcurl without WebSocket support as an interim mitigation
./configure --disable-websockets
make && sudo make install