GHSA-7ppr-r889-mcf2
HIGHblaze: Unbounded WebSocket message aggregation in http4s-blaze-server
Blast Radius
org.http4s:http4s-blaze-server_2.13☕org.http4s:http4s-blaze-server_2.13☕org.http4s:http4s-blaze-server_2.12☕org.http4s:http4s-blaze-server_3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
http4s-blaze-server aggregates the fragments of an incoming WebSocket
message with no limit on total size or fragment count. A client that
completes a WebSocket handshake can send an unterminated fragmented
message and drive unbounded heap growth in the server JVM, resulting in
denial of service via OutOfMemoryError.
Impact
Any http4s application serving WebSocket routes over
BlazeServerBuilder is affected; no non-default configuration is required,
and maxWebSocketBufferSize does not bound the aggregate (it bounds only
individual frames). A single connection sending continuation frames that
never set FIN forces the server to buffer every fragment until the heap is
exhausted, terminating the JVM with OutOfMemoryError on the blaze
selector thread. Small fragments amplify the cost through per-frame object
overhead, so a modest volume of wire bytes is sufficient. Where the
WebSocket endpoint is reachable without authentication the attacker is
unauthenticated and remote; where the handshake requires a principal, any
authenticated client can still trigger it.
Workarounds
- No blaze-server configuration bounds the aggregate;
maxWebSocketBufferSizeis not a mitigation. - Terminate/limit WebSocket traffic at a fronting layer that enforces message-size and fragment limits, or disable WebSocket routes.
- Longer term: blaze is EOL upstream; plan migration to a maintained backend (e.g. ember).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.http4s:http4s-blaze-server_2.13 | all versions | 0.23.18 |
| ☕Maven | org.http4s:http4s-blaze-server_2.13 | ≥ 1.0.0-M1&&< 1.0.0-M42 | 1.0.0-M42 |
| ☕Maven | org.http4s:http4s-blaze-server_2.12 | all versions | 0.23.18 |
| ☕Maven | org.http4s:http4s-blaze-server_3 | ≥ 1.0.0-M1&&< 1.0.0-M42 | 1.0.0-M42 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.http4s:http4s-blaze-server_2.13. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.http4s:http4s-blaze-server_2.13 to 0.23.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7ppr-r889-mcf2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7ppr-r889-mcf2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7ppr-r889-mcf2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7ppr-r889-mcf2 in your dependencies?
O3 detects GHSA-7ppr-r889-mcf2 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.