CVE-2026-54288

What it actually does

Hono versions prior to 4.12.25 can incorrectly enforce Body Limit Middleware limits in AWS Lambda-based deployments because the middleware trusts the client-supplied Content-Length header instead of validating the actual buffered request body size. In affected deployment paths such as API Gateway v1/v2, Application Load Balancer, VPC Lattice, and Lambda@Edge, the platform may deliver the full body to the Lambda function while the Hono adapter constructs the request using the declared Content-Length value. An unauthenticated remote client can send a large payload while declaring a small Content-Length value, causing the request to pass middleware size checks that were intended to reject it. The likely impacts are bypass of application-layer body size policy, unexpected processing of oversized request bodies, increased memory/compute consumption, and possible downstream application logic issues where request size assumptions are security-relevant.

Why it matters to the business

Applications relying on Hono's Body Limit Middleware for upload, API, or request-size enforcement may accept requests that should have been rejected. This can increase cloud execution costs, degrade service performance, bypass data-submission controls, and expose downstream handlers, parsers, storage layers, or business workflows to oversized input. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or ransomware association, but internet-facing serverless APIs are easy to reach and the fix is straightforward, so affected services should be upgraded during the next normal patch cycle or sooner for endpoints that process uploads, JSON bodies, forms, webhooks, or untrusted API requests.

How an attack unfolds

An attacker identifies an application using Hono with Body Limit Middleware on an AWS Lambda-backed ingress path. They craft an HTTP request whose actual body is larger than the configured application limit but set the Content-Length header to a small value that appears compliant. The AWS front end buffers and forwards the request body to Lambda, and the Hono adapter constructs the request object using the client-declared Content-Length rather than independently measuring the actual body. The Body Limit Middleware then evaluates the misleading header and allows the request to continue. The oversized body reaches downstream route handlers, parsers, validation logic, or storage operations, potentially causing policy bypass, excessive processing, increased Lambda duration and memory pressure, or application-specific integrity and confidentiality effects depending on what the endpoint does with the body.

How to fix it

Upgrade Hono to version 4.12.25 or later wherever Body Limit Middleware is used, especially in AWS Lambda deployments behind API Gateway v1/v2, Application Load Balancer, VPC Lattice, or Lambda@Edge. Update direct and transitive dependency locks, rebuild artifacts, and redeploy serverless functions or edge bundles so the fixed package is actually running. If immediate upgrade is not possible, add compensating request-size enforcement at the earliest available layer, such as API Gateway/ALB request limits where applicable, AWS WAF body-size rules, Lambda handler-level validation that measures the actual received body size, and strict route-specific upload limits. Do not rely solely on Content-Length for body-size enforcement. Review endpoints that parse JSON, multipart forms, file uploads, webhooks, or other attacker-controlled bodies and ensure downstream code safely handles oversized input.

How to confirm the fix worked

Confirm that all deployed application artifacts resolve Hono to 4.12.25 or later by checking package manifests, lockfiles, software composition analysis results, and built deployment bundles. Validate running deployments, not only source repositories, because serverless artifacts may contain vendored dependencies. Perform a negative test against representative Lambda-backed routes: send a request with an actual body larger than the configured limit while declaring a smaller Content-Length value, and verify that the application rejects it before route handler processing. Confirm that compensating controls, if used, reject oversized bodies independently of the client-supplied Content-Length header. Review CI/CD dependency scans and runtime logs after redeployment to ensure older Hono versions are no longer present.

Typical attack path

1. Discover or target an internet-accessible API, webhook, upload route, or form endpoint implemented with Hono and deployed on AWS Lambda through API Gateway, ALB, VPC Lattice, or Lambda@Edge.
2. Determine or guess that the endpoint is protected by request body size limits.
3. Send a request with a small declared Content-Length header but an actual payload larger than the configured Body Limit Middleware threshold.
4. Rely on the AWS Lambda adapter behavior to deliver the full buffered body while Hono evaluates the misleading header value.
5. Cause the oversized payload to be accepted by the Hono middleware and processed by downstream application code.
6. Use the bypass to trigger excessive compute/memory use, bypass upload or API policy controls, or exploit application-specific behavior exposed by unexpectedly large input.

How to detect it

To determine whether this was already exploited, review AWS ingress and application logs for requests where the declared Content-Length was small but the actual payload processed by the application was large. Useful sources include API Gateway access logs and execution logs, ALB access logs, Lambda CloudWatch logs, Lambda REPORT lines, AWS WAF logs, application request logs, and any route-level telemetry that records body size, upload size, parsing errors, request duration, or memory usage. Look for oversized requests that received 2xx or application-level success responses despite configured body limits, spikes in Lambda duration or max memory used on body-processing endpoints, parser errors following unusually large bodies, repeated requests with suspiciously low Content-Length values, and increased invocation cost or throttling correlated with POST, PUT, or PATCH routes. Because there are no public reports of exploitation and no known actor-specific tradecraft for this issue, detection should focus on behavioral anomalies rather than fixed malware or infrastructure indicators.

• hono@4.12.24
• hono@4.12.23
• hono@4.12.22
• hono@4.12.21
• hono@4.12.20
• "Content-Length: 0"
• "Content-Length: 1"
• "Content-Length: 2"
• "Content-Length: 10"
• "Content-Length: 100"
• "Max Memory Used:"
• "Task timed out"
• "PayloadTooLargeError"
• "entity.too.large"
• "request entity too large"

What your security team should do

• Inventory Hono applications and prioritize those deployed on AWS Lambda through API Gateway v1/v2, ALB, VPC Lattice, or Lambda@Edge.
• Upgrade Hono to 4.12.25 or later and redeploy all affected serverless functions, edge bundles, and containers.
• Prioritize internet-facing endpoints that accept uploads, JSON bodies, forms, webhooks, or other large untrusted request payloads.
• Add or verify request-size limits at an upstream control point such as AWS WAF, API Gateway, or ALB where feasible.
• Add application-level validation that measures actual body size rather than trusting Content-Length.
• Search recent access and application logs for mismatches between declared Content-Length and observed body size, unusually large request bodies that returned success, or spikes in Lambda duration, memory use, throttling, and cost around body-processing endpoints.
• Update dependency monitoring rules to flag Hono versions earlier than 4.12.25.