JLSEC-2026-611

Description

The HTTP.jl HTTP/2 server advertised an empty initial SETTINGS frame, leaving SETTINGS_MAX_CONCURRENT_STREAMS effectively unlimited, and the HEADERS code path allocated per-stream state, a send-window entry, and a Threads.@spawned handler with no check on the number of open streams. RST_STREAM was not rate-limited, so a single connection could drive unbounded stream state and handler-task creation — the "Rapid Reset" denial-of-service class (cf. CVE-2023-44487). Separately, the new-stream guard compared hf.stream_id < max_stream_id, which allowed a client to reuse the highest closed stream id once it had been cleaned up, including after GOAWAY.

Impact

A remote peer could exhaust a multithreaded server's memory and CPU by rapidly opening and resetting streams over a single connection, or could reuse closed stream ids to confuse connection state.

Patches

Fixed in HTTP.jl v2.4.0. A configurable per-connection concurrent-stream cap (max_concurrent_streams, default 100) is advertised via SETTINGS_MAX_CONCURRENT_STREAMS and enforced on incoming HEADERS — an over-cap stream is refused with RST_STREAM(REFUSED_STREAM) without allocating state or spawning a handler. Peer-initiated resets are tracked and trigger GOAWAY(ENHANCE_YOUR_CALM) once they exceed max_concurrent_streams + 100, and new client stream ids must be strictly increasing. Set max_concurrent_streams <= 0 to restore the previous unbounded behavior.

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