WebSocket reader data race in auto-PONG/CLOSE-echo handling in HTTP.jl

Description

The WebSocket reader task processed incoming frames by calling ws_on_incoming_data! without holding ws.sendlock. That function is not a pure parser: its auto-PONG and CLOSE-echo paths push! onto the shared ws.codec.outgoing_frames vector, while application send/ping/pong/close paths mutate the same vector while holding ws.sendlock. Because the reader did not take the lock, a remote peer flooding PING frames against a multithreaded server (julia -t N, N>1) could drive concurrent push!/empty! of a Julia Vector from two OS threads — undefined behavior that can corrupt the array metadata or segfault the process.

Impact

A remote peer could crash, or potentially corrupt memory in, a multithreaded WebSocket server through concurrent frame processing.

Patches

Fixed in HTTP.jl v2.4.0. A new _process_incoming_data! helper acquires ws.sendlock and runs ws_on_incoming_data! followed by _flush_ws_output_locked! under the lock, making each decode atomic with its flush; all production decode call sites route through it. The blocking read stays outside the lock so concurrent senders cannot deadlock the reader, and lock ordering is unchanged.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.