# RUSTSEC-2026-0304: Finished streaming calls keep reading a stalled request body indefinitely > Attackers can exhaust server resources by stalling streaming requests, causing memory and connection exhaustion in connectrpc servers. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not stated - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 21 Sep 2026 - **Also known as:** GHSA-jx5x-3mcr-qp8r ## What is RUSTSEC-2026-0304? RUSTSEC-2026-0304 is a denial of service vulnerability in connectrpc, published on 21 Sep 2026. It can be exploited over the network, with no action from the victim. ### Official description Affected versions of `connectrpc` start a background task to read the request body of every client-streaming and bidirectional-streaming call, before the interceptors or the handler run. A call can finish before it has consumed its request: the handler can return without reading all of its request stream, an interceptor can reject the call, or the request timeout can fire. The background task then keeps reading, with no time limit. If the client stops sending part-way through a message, or never sends the rest, the task, the partial message it has buffered (up to `max_message_size`, 4 MiB by default) and the HTTP/2 stream, or the HTTP/1.x connection, are held until the client finishes the stream or closes the connection. ## Impact A client can use this to exhaust the memory, tasks and file descriptors of a server. With the default limits of the built-in `Server`, one HTTP/2 connection can hold 200 stalled streams, about 800 MiB at the default message size, and the server does not limit the number of connections. A server that authenticates in Tower middleware, before the request reaches the service, is exposed only to callers with a valid credential. A server with no authentication, or one that authenticates in an interceptor, is exposed to any client. This advisory covers client-streaming and bidirectional-streaming calls only. ## Patches Versions 0.8.2 and 0.9.1 bound the wait. When the handler is gone, the reader frees the partial message and discards the rest of the body for at most 5 seconds and 1 MiB, then drops it, which resets the HTTP/2 stream or closes the HTTP/1.x connection. On `wasm32`, which has no clock, only the 1 MiB limit applies. Versions 0.2.0 to 0.7.0 contain the same reader and are not patched; upgrade to 0.8.2 or later. ## Workarounds Authenticate in Tower middleware rather than in an interceptor, so a request without a credential is rejected before any reader starts. Set `Server::with_max_connection_age`, which closes each connection, and every stalled body on it, once its age and the grace period have passed. Lowering `Limits::with_max_message_size` and `Server::with_max_concurrent_streams` reduces what one client can hold but does not release a stalled body. ## Which versions are affected by RUSTSEC-2026-0304? 1 open source package ship an affected version, including connectrpc. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `connectrpc` | crates.io | From 0.2.0 | 0.8.2, 0.9.1 | ## How do I fix RUSTSEC-2026-0304? Upgrade connectrpc to a fixed version for your release line: 0.8.2 or 0.9.1. ## Is RUSTSEC-2026-0304 being exploited? There is no known exploitation of RUSTSEC-2026-0304 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for RUSTSEC-2026-0304 and fix it if it is affected. What it is: RUSTSEC-2026-0304 is a denial of service vulnerability in connectrpc, published on 21 Sep 2026. It can be exploited over the network, with no action from the victim. Exploitation: There is no known exploitation of RUSTSEC-2026-0304 in the wild and no public exploit code. Affected packages and fixed versions: - connectrpc (crates.io): affected from 0.2.0; fixed in 0.8.2, 0.9.1 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/RUSTSEC-2026-0304/ (Markdown: https://insights.sbomify.com/RUSTSEC-2026-0304/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/RUSTSEC-2026-0304 --- From sbomify Insights: https://insights.sbomify.com/RUSTSEC-2026-0304/ Summaries are generated and may contain mistakes; the official description above is the record.