Hono CVE-2026-44456
MEDIUMSeverity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Lifecycle Timeline
3Blast Radius
ecosystem impact- 27 npm packages depend on hono (15 direct, 12 indirect)
Ecosystem-wide dependent count for version 4.12.16.
DescriptionGitHub Advisory
Summary
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.
Details
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:
- the handler does not read the body,
- the handler reads only the first chunk(s) and returns, or
- the handler reads the body but swallows the read error in
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.
Impact
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.
Credits
- @lalalala5678 (slow chunked / early return variants)
- @Jvr2022 (error handling bypass)
AnalysisAI
Hono's bodyLimit() middleware fails to reliably enforce maxSize restrictions on chunked or unknown-length HTTP requests (Transfer-Encoding: chunked), allowing oversized payloads to reach application handlers and return HTTP 200 instead of 413 Payload Too Large. Versions prior to 4.12.16 are vulnerable when handlers do not fully read the request body, read only initial chunks before returning, or catch and suppress read errors. This bypasses the documented guarantee that oversized requests are rejected before business logic execution.
Technical ContextAI
Hono is a lightweight web framework for JavaScript/TypeScript runtime environments. The bodyLimit() middleware is designed as a critical security gate to enforce request size constraints. The vulnerability stems from asynchronous stream byte-counting logic that processes chunked Transfer-Encoding requests. When Content-Length is unavailable (chunked transfer), bodyLimit() wraps the request body stream in a counting wrapper and invokes the next handler via next() before the size validation completes. The size violation is only checked afterward via c.error inspection, creating a race condition. The underlying issue is classified as CWE-400 (Uncontrolled Resource Consumption), where the resource (request body size) is not enforced at the boundary before handler execution. This affects all npm/hono package versions below 4.12.16.
RemediationAI
Upgrade Hono to version 4.12.16 or later immediately. The fix relocates size enforcement to occur synchronously before next() invocation, eliminating the race condition. Apply the patch via npm update hono or equivalent package manager command. For applications unable to upgrade immediately, implement compensating controls: (1) add explicit request size validation in handler entry points before reading req.body; (2) configure upstream load balancers or reverse proxies (nginx, Apache, AWS ALB) to enforce request size limits at the network boundary before forwarding to Hono application; (3) disable chunked transfer encoding if business requirements permit (configure reverse proxy to buffer and add Content-Length header); (4) set aggressive socket timeouts to limit slow-read attacks. Each workaround has trade-offs: handler-level validation duplicates logic, proxy enforcement adds latency, disabling chunked encoding reduces streaming capability, and tight timeouts may affect legitimate slow clients. The GitHub security advisory at https://github.com/honojs/hono/security/advisories/GHSA-9vqf-7f2p-gf9v provides detailed patch context.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-9vqf-7f2p-gf9v