CVE-2025-59139: Hono Web Framework DoS Vulnerability

CVE-2025-59139 Overview

CVE-2025-59139 is a request body size limit bypass in Hono, a lightweight web application framework supporting multiple JavaScript runtimes. The bodyLimit middleware in versions prior to 4.9.7 prioritized the Content-Length header even when a conflicting Transfer-Encoding: chunked header was present. RFC 7230 requires implementations to ignore Content-Length in this scenario. Attackers can exploit this discrepancy to submit oversized request bodies that bypass configured size safeguards. The flaw is tracked as CWE-400 (Uncontrolled Resource Consumption).

Critical Impact
Attackers can bypass bodyLimit protections and send oversized request bodies, causing denial of service through excessive memory or CPU consumption in downstream handlers.

Affected Products

Hono framework versions prior to 4.9.7
Applications running Hono on Node.js runtimes
Deployments where Hono bodyLimit middleware acts as the primary request size safeguard

Discovery Timeline

2025-09-12 - CVE-2025-59139 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-59139

Vulnerability Analysis

Hono's bodyLimit middleware enforces a maximum request body size to protect applications from resource exhaustion. In affected versions, the middleware inspected the Content-Length header first and used its value to decide whether the request exceeded the configured maxSize. When a request contained both Content-Length and Transfer-Encoding: chunked, the middleware trusted Content-Length and skipped chunked-stream measurement. An attacker could send a small Content-Length value alongside a chunked body of arbitrary size, bypassing the size check entirely. The oversized body then reached application logic, potentially exhausting memory or CPU during parsing and processing.

The practical impact depends on the runtime and any upstream reverse proxy. Standards-compliant runtimes typically reject conflicting headers with 400 Bad Request, limiting exploitation. Deployments without strict proxy validation remain exposed.

Root Cause

The root cause is non-conformance with RFC 7230 header precedence rules. The middleware logic evaluated Content-Length unconditionally when the header was present, without checking for the co-existence of Transfer-Encoding. This design decision conflicts with the HTTP specification, which states that Transfer-Encoding must take precedence and Content-Length must be ignored when both are supplied.

Attack Vector

Exploitation requires an unauthenticated remote attacker to send an HTTP request containing both a spoofed Content-Length header below the configured limit and a Transfer-Encoding: chunked body carrying oversized data. No user interaction is required.

typescript

// Patched logic in src/middleware/body-limit/index.ts
return next()

const hasTransferEncoding = c.req.raw.headers.has('transfer-encoding')
const hasContentLength = c.req.raw.headers.has('content-length')

// RFC 7230: If both Transfer-Encoding and Content-Length are present,
// Transfer-Encoding takes precedence and Content-Length should be ignored
if (hasTransferEncoding && hasContentLength) {
  // Both headers present - follow RFC 7230 and ignore Content-Length
  // This might indicate request smuggling attempt
}

if (hasContentLength && !hasTransferEncoding) {
  // Only Content-Length present - we can trust it
  const contentLength = parseInt(c.req.raw.headers.get('content-length') || '0', 10)
  return contentLength > maxSize ? onError(c) : next()
}

// Transfer-Encoding present (chunked) or no length headers
let size = 0
const rawReader = c.req.raw.body.getReader()

Source: Hono commit 605c705

Detection Methods for CVE-2025-59139

Indicators of Compromise

HTTP requests containing both Content-Length and Transfer-Encoding: chunked headers reaching Hono services
Sudden spikes in Node.js process memory or CPU consumption correlated with inbound POST or PUT traffic
Application logs showing request bodies larger than the configured bodyLimit maxSize being processed

Detection Strategies

Inspect access logs and reverse proxy telemetry for requests carrying conflicting length and transfer-encoding headers
Alert on Hono application errors related to memory allocation failures or event-loop stalls during request handling
Baseline expected request body sizes per endpoint and flag deviations that reach handler code despite bodyLimit middleware being active

Monitoring Recommendations

Enable structured logging on reverse proxies to capture full request headers for HTTP smuggling analysis
Track the Hono package version deployed across services using software composition analysis tooling
Monitor runtime health metrics such as heap utilization and event-loop latency to identify resource exhaustion attempts early

How to Mitigate CVE-2025-59139

Immediate Actions Required

Upgrade Hono to version 4.9.7 or later across all Node.js and edge runtime deployments
Audit reverse proxy configurations to ensure malformed requests with conflicting headers are rejected with 400 Bad Request
Review application endpoints that rely on bodyLimit as a safeguard and confirm no additional bypass paths exist

Patch Information

The issue is resolved in Hono v4.9.7. The fix updates src/middleware/body-limit/index.ts to align with RFC 7230, ensuring Transfer-Encoding takes precedence over Content-Length. Reference the GitHub Security Advisory GHSA-92vj-g62v-jqhh and the upstream commit for full details.

Workarounds

Deploy an RFC-compliant reverse proxy such as NGINX or a WAF in front of Hono services to reject requests containing both Content-Length and Transfer-Encoding headers
Enforce per-endpoint body size limits at the runtime or infrastructure layer as defense-in-depth
Restrict inbound request methods and content types where large payloads are not expected

bash

# Upgrade Hono to the patched version
npm install hono@^4.9.7

# Verify installed version
npm ls hono