bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413.
For chunked / unknown-length requests, bodyLimit() wraps the body in a stream that counts bytes asynchronously, then runs the handler before the size decision is final. The 413 is only applied afterwards by checking c.error.
This lets the limit be bypassed when:
try/catch.In all three cases the handler returns 200 before the limit check completes (or its result is observed).
The fix is to enforce the size decision before next() runs, instead of retrofitting the response via c.error afterwards.
Applications relying on bodyLimit() as a hard boundary can be bypassed: oversized chunked requests can reach handler logic and return successful responses. Per-request data exposure is bounded by maxSize, but the documented guarantee — "oversized requests are rejected before business logic runs" — does not hold.
| Score | Percentile |
|---|---|
| 0.03% | 8.44% |
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 6.5 | 3.1 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-9vqf-7f2p-gf9v ↗ |
| CVE | CVE-2026-44456 ↗ |
| CWE id | Name |
|---|---|
| CWE-400 | Uncontrolled Resource Consumption |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | hono | < 4.12.16 | 4.12.16 | — |