CVE-2026-71849: Information Exposure via Hop-by-Hop Header Leakage in Hono Proxy Helper

Hono is a web framework built on Web Standards with support for multiple JavaScript runtimes including Node.js, Deno, Bun, and Cloudflare Workers. Within this ecosystem, the Proxy Helper (hono/proxy) offers a proxy() utility designed to facilitate forwarding incoming HTTP requests to downstream origin servers. This component is commonly deployed in gateway layers, reverse proxies, and microservices architectures to simplify routing.

Between versions 4.7.0 and 4.12.33, the proxy() function in the Proxy Helper failed to handle connection-scoped headers in accordance with RFC 9110 Section 7.6.1. Specifically, the helper failed to inspect the incoming Connection header of origin responses dynamically, only removing a predefined static set of well-known hop-by-hop headers.

This architectural oversight results in the exposure of sensitive session-specific or internal metadata to unauthorized public clients. When an upstream server marks custom tracking headers or internal tokens as connection-scoped, the vulnerable proxy forwards these values instead of purging them, leading to a direct information leakage.

The root cause of this vulnerability lies in a protocol implementation defect related to HTTP/1.1 and modern proxy specifications. RFC 9110 Section 7.6.1 distinguishes between end-to-end headers, which must be delivered to the final recipient, and connection-scoped (hop-by-hop) headers, which apply only to a single transport link. Intermediaries must remove all hop-by-hop headers before forwarding an HTTP message.

Standard hop-by-hop headers such as Connection, Keep-Alive, and Transfer-Encoding are universally recognized and typically stripped by default. However, RFC 9110 also permits sender-defined custom hop-by-hop headers. These are dynamically listed as comma-separated values inside the Connection header field itself, signaling to the immediate receiver that they must not be forwarded.

The vulnerable implementation of hono/proxy relied exclusively on a static array named hopByHopHeaders. Because it only iterated over this hardcoded list, the proxy completely ignored the list of dynamic headers contained within the Connection response header value. Any custom header specified inside Connection: X-Custom-Header remained intact in the response headers and was subsequently forwarded to the public client.

In vulnerable versions of Hono, the proxy function within src/helper/proxy/index.ts fetched the response from the upstream origin and initialized a new Headers object. It then executed a static loop to remove the predefined headers, leaving all other custom fields untouched regardless of the Connection header configuration.

// Vulnerable logic path in Hono
const res = await (customFetch || fetch)(req)
const resHeaders = new Headers(res.headers)
 
// Only stripped the static, well-known hop-by-hop headers
hopByHopHeaders.forEach((header) => {
  resHeaders.delete(header)
})

The patch introduced in commit 720b566290793d4358bf39843adcb7cf4da4548f remediates the issue by dynamically parsing the Connection header before executing the static deletion block. The corrected logic retrieves the Connection value, tokenizes it by commas, trims whitespace, and applies a regex filter to prevent invalid headers from manipulating the execution flow before programmatically deleting them.

// Patched implementation in v4.12.34
const res = await (customFetch || fetch)(req)
const resHeaders = new Headers(res.headers)
 
// Remove headers listed in the response's own Connection header (RFC 9110 Section 7.6.1)
const connectionValue = resHeaders.get('connection')
if (connectionValue) {
  connectionValue
    .split(',')
    .map((h) => h.trim())
    .filter((h) => ALLOWED_TOKEN_PATTERN.test(h))
    .forEach((h) => resHeaders.delete(h))
}
 
hopByHopHeaders.forEach((header) => {
  resHeaders.delete(header)
})

Exploitation of CVE-2026-71849 does not require an active exploit payload or memory manipulation. Instead, it relies on passive observation of headers returned through the Hono proxy interface. The attack surface exists when the backend server utilizes custom connection-scoped headers to pass localized infrastructure details, routing identifiers, or authentication tokens.

The following flowchart illustrates the communication path and the exact point where data leakage occurs:

As shown in the flow, when the origin backend server includes a dynamic header in the Connection directive, Hono deletes the Connection header itself but leaves the referenced custom header active. An attacker querying the proxy endpoint simply inspects the response headers to gather sensitive structural details or credentials that were meant to remain within the internal network segment.

During regression analysis, researchers must evaluate the behavior of the ALLOWED_TOKEN_PATTERN validation regex. Under HTTP RFC 9110, valid header name characters include alphanumeric characters as well as specific symbols. If the regex is overly restrictive, certain custom headers used by backends (such as those containing underscores or specialized characters) might be skipped by the filter and erroneously forwarded to the client.

Another area of concern is proxy asymmetry. A robust gateway proxy should sanitize both incoming request headers from clients and outgoing response headers from backends. If the client-to-backend request path does not properly sanitize client-supplied hop-by-hop headers, it may create conditions conducive to HTTP request smuggling or cache poisoning against upstream servers.

Finally, handling duplicate headers across multiple lines represents a potential edge case. Different JavaScript runtime engines (Node.js, Bun, Deno) parse multiple instances of the Connection header differently, sometimes merging them and other times only retaining the last declared value. This parsing variance can lead to incomplete header stripping if the engine fails to extract all tokens.

The primary and most effective remediation strategy is to upgrade the hono package to version 4.12.34 or higher. This ensures that the dynamic header sanitization logic is natively enforced inside the proxy helper. Organizations should verify that their dependency files are updated and run fresh installations across all staging and production builds.

If upgrading immediately is not viable, developers should implement a manual wrapper around the proxy() helper function. This wrapper must intercept the returned response, parse the Connection header, and explicitly delete all listed headers from the response header collection before returning the object to the routing cycle.

// Example of a manual mitigation wrapper in Hono middleware
app.get('/proxy-route/*', async (c) => {
  const response = await proxy(`https://backend-origin/${c.req.path}`)
  const safeHeaders = new Headers(response.headers)
  
  const connectionHeader = safeHeaders.get('connection')
  if (connectionHeader) {
    connectionHeader.split(',').forEach((h) => {
      safeHeaders.delete(h.trim())
    })
  }
 
  return new Response(response.body, {
    status: response.status,
    headers: safeHeaders
  })
})