CVE-2026-44456

What it actually does

In Hono versions prior to 4.12.16, the bodyLimit() middleware can fail to enforce the configured maxSize when an HTTP request does not provide a usable Content-Length header, especially when Transfer-Encoding: chunked is used. Because the middleware cannot reliably determine the full request size up front, oversized request bodies may be passed to application handlers instead of being rejected with HTTP 413 Payload Too Large. This can allow attackers to bypass application-level request-size controls, causing handlers to process unexpectedly large bodies and potentially triggering excessive memory, CPU, storage, logging, downstream API, or parser workload depending on how the application handles request bodies.

Why it matters to the business

Applications relying on Hono bodyLimit() for request-size enforcement may accept requests they were designed to reject, which can increase infrastructure cost, degrade service performance, exhaust worker resources, or disrupt request handling under abuse. The issue is remotely reachable, requires no authentication, and has low attack complexity, but it is not currently listed in CISA KEV and has low EPSS, suggesting no broad public exploitation signal at this time. Organizations with internet-facing Hono services, serverless functions, edge workers, or APIs that process uploaded JSON, forms, files, webhooks, or large request bodies should still prioritize remediation because the flaw can be abused cheaply and at scale.

How an attack unfolds

An attacker identifies an application built with an affected Hono version that uses bodyLimit() to restrict request size. Instead of sending a normal request with an accurate Content-Length header, the attacker sends an oversized HTTP request using chunked transfer encoding or another pattern where Content-Length is missing, malformed, or not usable. Because vulnerable versions do not reliably enforce maxSize in this condition, the request can reach the application route handler. If the handler reads, parses, stores, forwards, or logs the full request body, the attacker can force the service to perform work that the size limit was intended to prevent. Repeated requests can amplify resource consumption, cause slowdowns, inflate logs or storage, trigger downstream failures, or bypass business logic that assumes oversized payloads are rejected.

How to fix it

Upgrade Hono to version 4.12.16 or later wherever the framework is used. If package manifests pin Hono directly, update the hono package to >=4.12.16 and regenerate lockfiles. If Hono is pulled in transitively through another framework, SDK, template, or platform adapter, update the parent dependency to a version that resolves Hono to 4.12.16 or later. As defense in depth, enforce request-size limits before the application layer where possible, including reverse proxies, API gateways, load balancers, ingress controllers, CDN/WAF rules, serverless platform limits, and runtime body parser limits. Configure limits to apply to chunked transfer requests as well as requests with Content-Length. Where large uploads are legitimate, use dedicated upload flows, streaming validation, object storage pre-signed URLs, and strict per-route limits rather than relying on a single generic body limit.

How to confirm the fix worked

Confirm installed Hono versions are 4.12.16 or later using package inventory, lockfile review, software composition analysis, or commands such as npm ls hono, pnpm why hono, yarn why hono, or bun pm ls where applicable. Functionally test affected routes by sending a body larger than the configured maxSize first with a normal Content-Length header and then with Transfer-Encoding: chunked; both should be rejected consistently with HTTP 413 or the configured rejection behavior before reaching application handlers. Review dependency lockfiles and built artifacts to ensure no deployed service still bundles an older Hono version. Also verify that upstream controls such as gateways or proxies reject oversized chunked requests before they reach the application.

Typical attack path

1. Discover a Hono-based HTTP endpoint that accepts request bodies, such as API, upload, webhook, or form-processing routes.
2. Confirm the endpoint appears to rely on request-size controls by sending an oversized request with a normal Content-Length header and observing a 413 response or rejection.
3. Resend an oversized body without a usable Content-Length header, commonly using Transfer-Encoding: chunked.
4. Observe whether the vulnerable service returns 200 or another application-level response instead of 413 Payload Too Large.
5. Repeat or scale the requests to force the application handler to parse, buffer, store, forward, or log oversized payloads.
6. Use the resulting behavior to bypass intended request-size limits or create operational degradation depending on the handler implementation.

How to detect it

To determine whether the issue was already exploited, review HTTP access logs, API gateway logs, CDN/WAF logs, reverse proxy logs, application logs, and APM traces for requests with Transfer-Encoding: chunked or missing Content-Length that were unusually large or took unusually long to process. Focus on POST, PUT, PATCH, and upload/webhook endpoints that returned 200, 201, 202, 204, 400, or 500 instead of 413 for payloads exceeding documented limits. Look for spikes in request duration, memory pressure, worker restarts, body parser errors, JSON parse failures, storage writes, downstream API calls, or log volume correlated with chunked requests. In cloud and serverless environments, correlate suspicious requests with increased invocation duration, timeout errors, out-of-memory events, concurrency spikes, or elevated egress/storage costs. Because this vulnerability does not create a unique file or process artifact by itself, detection is primarily behavioral and log-based.

• Transfer-Encoding: chunked
• Content-Length: 0
• Payload Too Large
• HTTP 413
• request entity too large
• body too large
• bodyLimit
• maxSize
• unexpected end of JSON input
• JSON.parse
• JavaScript heap out of memory
• Reached heap limit Allocation failed
• RangeError: Invalid string length
• POST
• PUT
• PATCH

What your security team should do

• Inventory all services, serverless functions, edge workers, and APIs that use Hono and identify versions earlier than 4.12.16.
• Prioritize internet-facing routes that accept POST, PUT, PATCH, file uploads, webhooks, JSON bodies, forms, or other attacker-controlled request bodies.
• Upgrade Hono to 4.12.16 or later and redeploy affected services.
• Add or verify request-size enforcement at the edge, gateway, ingress, or reverse-proxy layer, including explicit handling for Transfer-Encoding: chunked.
• Run regression tests that send oversized chunked requests and confirm they are rejected before route handlers execute.
• Monitor for abnormal volumes of chunked requests, large request bodies, unexpected 200 responses for oversized requests, elevated memory usage, increased request latency, or log/storage growth.
• Add dependency scanning policies that flag Hono versions below 4.12.16 in direct and transitive dependencies.