Listen to this Post
How the CVE Works
The Body Limit Middleware in Hono is designed to cap incoming request body sizes to prevent excessive resource consumption. It performs this check by examining the `Content-Length` header sent by the client. If the declared `Content-Length` is below the configured maximum (maxSize), the middleware allows the request to proceed to the application handler without further validation.
This behavior is safe in standard runtime environments (Node.js, Deno, Bun) because the underlying HTTP transport enforces that the actual body size matches the declared Content-Length. If a client sends a body larger than the declared length, the transport layer rejects the request with a `400 Bad Request` error.
However, on AWS Lambda deployments (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge), the request body is fully buffered before being passed to the Lambda function. The Lambda adapter reconstructs the HTTP request from this buffered payload and copies the client’s `Content-Length` header verbatim into the reconstructed request object.
Because the adapter does not verify that the actual payload size matches the declared Content-Length, a client can send a request with a small `Content-Length` header (e.g., Content-Length: 100) while transmitting a much larger body (e.g., 10 MB). The middleware reads the small declared value, concludes the body is within the limit, and passes the request through. The handler then receives and processes the full oversized payload.
This bypass is possible only when `Transfer-Encoding` is absent; if `Transfer-Encoding: chunked` is present, the middleware falls back to a different (though also historically flawed) path. The vulnerability affects all applications deployed on AWS Lambda that rely on the Body Limit Middleware for request size capping.
DailyCVE Form:
Platform: AWS Lambda
Version: Hono < 4.12.25
Vulnerability: Content-Length trust bypass
Severity: Medium
date: 2025-09-12
Prediction: 2025-06-14 (fixed in v4.12.25)
What Undercode Say
Check current Hono version npm list hono Vulnerable versions: < 4.12.25 Fixed version: 4.12.25
Code snippet showing the vulnerable check:
// bodyLimit middleware - vulnerable logic
if (c.req.raw.headers.has("content-length")) {
const contentLength = parseInt(c.req.raw.headers.get("content-length") || "0", 10);
return contentLength > maxSize ? onError(c) : next(); // Trusts client-supplied value
}
Exploit example (curl):
Declare Content-Length: 100 but send 10MB of data curl -X POST https://your-api-gateway-url/prod/endpoint \ -H "Content-Length: 100" \ -H "Content-Type: application/json" \ --data-binary @/dev/zero 2>/dev/null | head -c 10485760
Detection (CloudWatch Logs):
Search for requests with mismatched Content-Length in Lambda logs aws logs filter-log-events \ --log-group-name /aws/lambda/your-function \ --filter-pattern '"Content-Length"' \ --region us-east-1
Exploit
An attacker can bypass the body size limit by sending a request with a small `Content-Length` header while transmitting a large payload. This can be done using any HTTP client that allows manual header control. The oversized request reaches the application handler, which processes the full payload (large JSON, multipart form data, etc.). The attack requires no authentication and can be launched remotely. The payload remains bounded by AWS Lambda’s platform request size limits (currently ~6 MB for synchronous invocations), so the attack manifests as increased per-request CPU and memory consumption rather than a full denial of service.
Protection
- Upgrade Hono to version 4.12.25 or later, which fixes the issue by ensuring the Body Limit Middleware no longer trusts the client-supplied `Content-Length` on AWS Lambda.
- If upgrade is not immediately possible, implement a custom middleware that reads and verifies the actual body size before processing:
// Custom body size verification middleware app.use('', async (c, next) => { const rawBody = await c.req.raw.clone().text(); const actualSize = Buffer.byteLength(rawBody, 'utf8'); const maxSize = 1024 1024; // 1MB if (actualSize > maxSize) { return c.text('Payload Too Large', 413); } // Reconstruct request with verified body c.req.raw = new Request(c.req.raw.url, { ...c.req.raw, body: rawBody }); await next(); }); - Deploy a Web Application Firewall (WAF) rule on API Gateway to reject requests where the actual payload size exceeds the declared
Content-Length. - Use Lambda function memory and timeout limits as a secondary defense to cap the maximum impact of oversized payloads.
Impact
- Bypass of configured body size limits: Attackers can send payloads larger than the intended
maxSize. - Increased CPU and memory consumption: Processing oversized payloads consumes additional resources per request.
- Increased AWS costs: Larger payloads lead to longer Lambda invocation durations and higher billed duration.
- Not a full denial of service: Lambda’s platform-level request size limits and invocation isolation prevent system-wide DoS.
- Affected environments: All Hono applications deployed on AWS Lambda (API Gateway v1/v2, ALB, VPC Lattice, Lambda@Edge) that use the Body Limit Middleware.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
