CVE-2025-10148

What it actually does

Websocket implementation reuses a static 32-bit mask value across all outgoing frames instead of generating a fresh value per frame, violating the masking requirement and enabling a remote peer to predict the masked payload.

Why it matters to the business

Organizations using curl-based clients behind caching proxies risk cache poisoning that can cause malicious or incorrect content to be served to many downstream users, potentially leading to widespread misinformation, malware distribution, or service disruption.

How an attack unfolds

An attacker hosts a malicious websocket server; a victim client connects using the vulnerable curl library; because the mask never changes, the attacker crafts frames whose masked bytes, when observed by an intervening proxy, are interpreted as valid HTTP requests carrying attacker-chosen content; the proxy caches the poisoned response and subsequently serves it to other clients.

How to fix it

Upgrade curl to the version containing commit 11b991232fbcaa88e2b1faecac224416b0001e35 or later; rebuild any statically linked applications and verify the updated library is in use.

How to confirm the fix worked

Confirm the running curl binary or library reports a version built after commit 11b991232fbcaa88e2b1faecac224416b0001e35; inspect source or binary for per-frame mask generation logic in the websocket send path; test by establishing a websocket connection and verifying distinct mask values on successive frames.

Typical attack path

1. Attacker deploys a websocket endpoint that responds to client connections
2. Victim application using vulnerable curl initiates a websocket session to the attacker-controlled endpoint
3. Attacker observes or predicts the static mask value used for the session
4. Attacker sends specially constructed frames that survive masking and appear as legitimate HTTP to any proxy
5. Proxy caches the attacker-supplied content under a URL or origin that will be requested by other users
6. Subsequent clients receive the poisoned cached content from the proxy

How to detect it

Search proxy or web-server access logs for repeated identical responses to websocket-originated requests, unexpected content-type mismatches, or cache hits on URLs that should not be cacheable; monitor for curl processes establishing long-lived websocket connections to untrusted endpoints.

What your security team should do

• Immediately inventory all systems and containers that ship or link against curl and schedule upgrades to the fixed commit
• Prioritize patching of any internet-facing or proxy-using clients within the next 30 days given the published date and cache-poisoning impact
• Add curl version checks to build pipelines and dependency scanners to prevent re-introduction of the vulnerable code
• Review proxy cache configurations for websocket-related origins and consider shorter TTLs or cache-key hardening until patches are deployed