CVE-2026-11586: WS Auto-PONG memory exhaustion

Summary:

TL;DR: a remote WebSocket peer can make default curl/libcurl grow memory until timeout or OOM by sending legal PING frames while refusing to read the client's automatic PONGs.

curl automatically replies to each received WebSocket PING with a PONG unless CURLWS_NOAUTOPONG is set. In lib/ws.c, ws_enc_add_cntrl() queues the generated PONG into ws->sendbuf and ignores the result of ws_flush(), while ws->sendbuf is initialized with BUFQ_OPT_SOFT_LIMIT. A malicious WebSocket peer can complete a valid upgrade, stop reading client data, and keep sending legal PING frames so curl continues appending internal PONGs without an effective hard limit. This is not just a never-ending transfer: even with --max-time 8, the default CLI path can hit 1 GiB RSS in about 2 seconds locally, and under a 180 MiB address-space limit it exits with curl: (27) Out of memory. The same input with CURLWS_NOAUTOPONG does not show comparable memory growth. As a temporary mitigation, a smaller --max-time / CURLOPT_TIMEOUT reduces the attack window, while CURLWS_NOAUTOPONG avoids this default auto-PONG queueing path entirely.

Affected version

Reproduced on current local build: