CVE-2025-59139

Executive Summary

CVE-2025-59139 is a vulnerability in the Hono web application framework (versions prior to 4.9.7) that allows attackers to bypass the configured request body size limit enforced by the bodyLimit middleware. The flaw arises from the middleware incorrectly prioritizing the Content-Length header over the Transfer-Encoding: chunked header, contrary to the HTTP specification (RFC 7230). By sending a request with both headers, an attacker can cause the middleware to ignore the actual body size, potentially leading to a Denial of Service (DoS) condition due to excessive memory or CPU consumption. The vulnerability has a CVSS score of 5.3 (Medium) and is currently unpatched in older versions. All users are advised to upgrade to Hono v4.9.7 immediately.

Supply Chain & Package Security

Hono is distributed via npm as the hono package. Organizations using Hono in their JavaScript/TypeScript applications should verify their dependency version and update to v4.9.7 or later. The vulnerability is present in the source code and affects all runtimes (Node.js, Deno, Bun, Cloudflare Workers, etc.) where Hono is deployed. No known malicious packages or typosquatting attacks have been reported in relation to this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: None
• Availability Impact: Low
• EPSS Score: 0.0% (Low probability of exploitation in the wild)

The threat level is considered Medium due to the low attack complexity and network-based vector, but the impact is limited to availability (DoS) with no data breach risk.

Deep Dive & Mechanics

The bodyLimit middleware in Hono is designed to restrict the size of incoming request bodies to prevent resource exhaustion. The vulnerability occurs because the middleware checks the Content-Length header to determine the body size, but fails to account for the Transfer-Encoding: chunked header. According to RFC 7230, when both headers are present, Transfer-Encoding takes precedence and Content-Length must be ignored. However, the vulnerable code uses Content-Length as the sole size indicator, allowing an attacker to send a small Content-Length value while the actual chunked body is much larger.

Attack Scenario:

1. Attacker sends an HTTP request with both Content-Length: 100 and Transfer-Encoding: chunked.
2. The bodyLimit middleware reads Content-Length (100 bytes) and allows the request.
3. The runtime processes the chunked body, which may be significantly larger (e.g., 100 MB).
4. The server consumes excessive memory and CPU, leading to a DoS condition.

The practical impact depends on the runtime and reverse proxy. Most standards-compliant runtimes (e.g., Node.js, Deno) and proxies (e.g., Nginx, Cloudflare) will reject such malformed requests with a 400 Bad Request before they reach the application. However, if the runtime or proxy does not enforce this, the vulnerability can be exploited.

Vulnerable vs. Patched Code

Vulnerable Code (prior to v4.9.7):

// bodyLimit middleware (simplified)
export const bodyLimit = (options) => {
  return async (c, next) => {
    const contentLength = parseInt(c.req.header('Content-Length') || '0', 10);
    if (contentLength > options.maxSize) {
      return c.text('Request body too large', 413);
    }
    await next();
  };
};

Patched Code (v4.9.7):

// bodyLimit middleware (fixed)
export const bodyLimit = (options) => {
  return async (c, next) => {
    const contentLength = parseInt(c.req.header('Content-Length') || '0', 10);
    const transferEncoding = c.req.header('Transfer-Encoding');
    // If Transfer-Encoding is present, ignore Content-Length per RFC 7230
    if (transferEncoding && transferEncoding.toLowerCase() === 'chunked') {
      // Allow the request, but the runtime will handle chunked encoding
      // The body size limit is enforced by the runtime or proxy
      return await next();
    }
    if (contentLength > options.maxSize) {
      return c.text('Request body too large', 413);
    }
    await next();
  };
};

The fix ensures that when Transfer-Encoding: chunked is present, the Content-Length header is ignored, aligning with the HTTP specification.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A target running Hono < 4.9.7 with bodyLimit middleware configured.
• Network access to the target.

Exploitation Steps:

1. Identify the target endpoint that uses bodyLimit.
2. Craft an HTTP request with both Content-Length and Transfer-Encoding: chunked headers.
3. Set Content-Length to a small value (e.g., 100) to bypass the limit.
4. Send a large chunked body (e.g., 100 MB) to cause resource exhaustion.

Example Request (using curl):

curl -X POST http://target.com/api/upload \
  -H "Content-Length: 100" \
  -H "Transfer-Encoding: chunked" \
  --data-binary @large_file.bin

Note: No public exploit code is available. The above is a conceptual demonstration.

Blue Team

Detection:

• Monitor for HTTP requests containing both Content-Length and Transfer-Encoding headers.
• Alert on requests where Content-Length is small but the actual body size is large.
• Use runtime-level monitoring to detect excessive memory or CPU usage.

Mitigation:

• Upgrade to Hono v4.9.7 or later.
• Deploy a reverse proxy (e.g., Nginx, Cloudflare) that rejects malformed requests with 400 Bad Request.
• Implement additional rate limiting and request size checks at the proxy level.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests with both Content-Length and Transfer-Encoding: chunked headers.
  • Requests where Content-Length value is significantly smaller than the actual body size.
  • High memory or CPU usage on the server during request processing.

• Log IOCs:

  • Server logs showing 413 Request Entity Too Large errors followed by resource exhaustion.
  • Proxy logs showing 400 Bad Request for malformed requests.

• File IOCs:

  • Large temporary files in the server's temp directory (if the runtime writes chunked data to disk).

Detection Engineering

YARA Rule

rule CVE_2025_59139_Hono_BodyLimit_Bypass {
  meta:
    description = "Detects HTTP requests with conflicting Content-Length and Transfer-Encoding headers targeting Hono bodyLimit bypass"
    author = "Valters IT"
    date = "2025-04-10"
    reference = "CVE-2025-59139"
    severity = "medium"
  strings:
    $content_length = /Content-Length:\s*\d+/i
    $transfer_encoding = /Transfer-Encoding:\s*chunked/i
  condition:
    all of them
}

Sigma Rule

title: Hono bodyLimit Bypass via Conflicting Headers
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests with both Content-Length and Transfer-Encoding headers, indicating a potential CVE-2025-59139 exploitation attempt.
author: Valters IT
date: 2025-04-10
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-59139
logsource:
  category: webserver
  product: generic
detection:
  selection:
    http.request.headers|contains:
      - 'Content-Length'
      - 'Transfer-Encoding'
  condition: selection
falsepositives:
  - Legitimate use of both headers in non-compliant clients
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-59139 Hono bodyLimit Bypass Attempt"; flow:to_server; content:"Content-Length"; http_header; content:"Transfer-Encoding"; http_header; pcre:"/Transfer-Encoding:\s*chunked/i"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Hono to version 4.9.7 or later.
2. If immediate upgrade is not possible, deploy a reverse proxy (e.g., Nginx, Cloudflare) that rejects requests with both Content-Length and Transfer-Encoding headers.
3. Monitor server logs for anomalous requests and resource usage.

Long-term Measures:

• Implement input validation and request size limits at multiple layers (proxy, application, runtime).
• Regularly update dependencies and subscribe to security advisories.
• Conduct penetration testing to identify similar vulnerabilities.

Workaround:

• Configure the runtime (e.g., Node.js --max-http-header-size) to reject malformed requests.
• Use a Web Application Firewall (WAF) to block requests with conflicting headers.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert