CVE-2026-54288: Hono Body Limit Bypass on AWS Lambda

Technical summary

The Body Limit Middleware in Hono relies on the Content-Length header to validate incoming request bodies against configured limits. On AWS Lambda platforms (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge), the request body is fully buffered before reaching the application. The Hono adapter constructs the request object using the client-supplied Content-Length header value without verifying it against the actual payload size. An attacker can craft a request with a falsified Content-Length header that declares a size well below the configured limit, while the HTTP body contains substantially more data. This mismatch allows the oversized body to bypass the middleware check. The vulnerability is classified as CWE-345 (Insufficient Verification of Data Authenticity).

Business impact

Organizations running Hono applications on AWS Lambda are at risk of denial of service attacks. An attacker could submit large payloads that bypass size restrictions, exhausting application memory, Lambda execution time, and potentially incurring unexpected AWS costs. In multi-tenant or SaaS deployments, this could degrade service quality for legitimate users. The impact is amplified in serverless environments where resource scaling and billing are tightly coupled.

Affected systems

Hono framework versions prior to 4.12.25 are vulnerable. The issue specifically affects deployments on AWS Lambda using API Gateway (v1 and v2), Application Load Balancer (ALB), VPC Lattice, or Lambda@Edge. Other JavaScript runtimes not exhibiting full body buffering behavior may not be affected in the same way, though the middleware logic remains problematic on any platform that trusts the Content-Length header.

Exploitability

The vulnerability requires no authentication or special privileges. An attacker needs only to send an HTTP request with a manipulated Content-Length header to an affected Hono endpoint, making exploitation straightforward. The attack is reliable because the underlying AWS Lambda infrastructure delivers the full body regardless of the declared header value. No user interaction is needed. The CVSS score of 6.5 reflects the moderate severity: while exploitability is trivial, the direct impact is limited to availability and potential information disclosure rather than code execution or authentication bypass.

Remediation

Upgrade Hono to version 4.12.25 or later. This patched version corrects the Body Limit Middleware to validate the actual body size rather than trusting the Content-Length header. Organizations should prioritize this update for all Hono applications running on AWS Lambda. Testing should confirm that body size limits are enforced correctly after the upgrade.

Patch guidance

Apply Hono version 4.12.25 or later. Verify the patch by checking your package lock file or running a dependency audit tool to ensure no intermediate dependencies are pulling in an older, vulnerable version. For teams using containerized Lambda deployments, rebuild images to include the patched version. For teams using Lambda layers, update the layer with the new Hono package. Testing should include requests with mismatched Content-Length headers to confirm they are now properly rejected or truncated according to policy.

Detection guidance

Monitor application logs for large request bodies that were accepted despite body size limit configurations. Watch for HTTP 413 (Payload Too Large) responses or application crashes related to memory exhaustion on Lambda functions. Examine CloudWatch metrics for unexplained CPU or memory spikes correlated with specific API endpoints. In WAF or reverse proxy logs, look for requests with unusually small Content-Length headers paired with large actual payload sizes. On the AWS side, check Lambda error rates, duration anomalies, and out-of-memory exceptions as indicators of active exploitation attempts.

Why prioritize this

Although the CVSS score is moderate (6.5), this vulnerability should be prioritized for Hono users on AWS Lambda because it directly attacks service availability in a high-impact environment. Serverless deployments are particularly vulnerable to resource exhaustion attacks due to auto-scaling costs and hard resource limits. The ease of exploitation—requiring only a single malformed HTTP request—and the likelihood of accidental or intentional triggering make this a practical risk. Organizations should plan patching within their next routine maintenance window, especially if their Lambda functions handle untrusted input.

Risk score, explained

The CVSS 3.1 score of 6.5 (Medium) accounts for: Network accessibility without authentication (AV:N, PR:N, UI:N), low attack complexity (AC:L), and impact limited to confidentiality and integrity rather than availability (C:L, I:L, A:N). However, the lack of an 'A:H' (high availability impact) in the vector may understate practical risk in serverless environments where resource exhaustion is a significant concern. Security teams should consider raising internal risk rating if their threat model emphasizes denial-of-service scenarios or if their Lambda functions are customer-facing.

Frequently asked questions