{"id":"ANT-2026-08Y5Y8H4","aliases":["ANT-2026-7393V1MS","ANT-2026-7CVAC8Q1","ANT-2026-9W57Y1XN","JLSEC-2026-611"],"status":"published","title":"Unbounded HTTP/2 concurrent streams and Rapid Reset denial of service in HTTP.jl server","description":"### Description\n\nThe 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.@spawn`ed 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 \u003c max_stream_id`, which allowed a client to reuse the highest closed stream id once it had been cleaned up, including after `GOAWAY`.\n\n### Impact\n\nA 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.\n\n### Patches\n\nFixed 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 \u003c= 0` to restore the previous unbounded behavior.\n\nReported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.","facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2026-06-23T12:59:32.708Z","modified":"2026-07-21T14:00:03Z","fixes":[{"ecosystem":"Julia","package":"HTTP","fixed_in":["2.4.0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Julia","package":"HTTP","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.4.0"}]}]}],"references":[{"url":"https://github.com/JuliaWeb/HTTP.jl/commit/5796cae2d52bf4f7e5380b49fa66a9a0b801b7fd","tags":["web"]},{"url":"https://github.com/JuliaWeb/HTTP.jl/pull/1316","tags":["web"]}],"sources":{"osv":[{"id":"JLSEC-2026-611","title":"Unbounded HTTP/2 concurrent streams and Rapid Reset denial of service in HTTP.jl server","description":"### Description\n\nThe 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.@spawn`ed 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 \u003c max_stream_id`, which allowed a client to reuse the highest closed stream id once it had been cleaned up, including after `GOAWAY`.\n\n### Impact\n\nA 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.\n\n### Patches\n\nFixed 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 \u003c= 0` to restore the previous unbounded behavior.\n\nReported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.","status":"published","published":"2026-06-23T12:59:32.708Z","modified":"2026-07-21T14:00:03.568934651Z","updated_at":"2026-11-02T15:47:18.573531Z"}]}}