Skip to main content

Hono CVE-2026-44456

MEDIUM
Uncontrolled Resource Consumption (CWE-400)
2026-05-06 https://github.com/honojs/hono GHSA-9vqf-7f2p-gf9v
6.5
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.5 MEDIUM
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
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

Lifecycle Timeline

3
Source Code Evidence Fetched
May 07, 2026 - 00:15 vuln.today
Analysis Generated
May 07, 2026 - 00:15 vuln.today
CVE Published
May 06, 2026 - 23:50 nvd
MEDIUM 6.5

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 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.

Share

CVE-2026-44456 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy