Description

Hono is a Web application framework that provides support for any JavaScript runtime. From 4.7.0 to 4.12.33, the Proxy Helper proxy() function in hono/proxy does not remove response headers named by the origin's Connection header. Per RFC 9110 Section 7.6.1, an intermediary must remove the header fields listed in a message's Connection header field before forwarding the message, in addition to the well known hop by hop headers, but the proxy() function only removed the well known hop by hop headers, including Connection itself, from origin responses. A client may therefore receive response headers that the origin intended only for its immediate peer, disclosing connection scoped or internal metadata contained in such headers, when an application proxies responses from an origin that declares additional, non standard headers as hop by hop via the Connection response header. This issue is fixed in version 4.12.34.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-08-07T19:18:54.100Z",
  "pubdate": "2026-08-07T19:18:54.100Z",
  "executiveSummary": "A vulnerability exists in the Hono web application framework, specifically within the Proxy Helper proxy() function located in hono/proxy, affecting versions 4.7.0 through 4.12.33. The vulnerability is classified as a hop-by-hop header leakage issue resulting from non-compliance with HTTP/1.1 RFC 9110 specifications. The impact of this security flaw involves the unauthorized disclosure of connection-scoped or internal metadata contained within response headers that the origin intended solely for its immediate peer. Attackers can exploit this behavior when an application proxies responses from an origin that declares additional, non-standard headers as hop-by-hop via the Connection response header. The risk implications include the potential exposure of sensitive internal infrastructure details, routing metadata, or session-specific configuration parameters. Attacker capabilities are limited to passive or active observation of responses returned by the proxy when interacting with upstream origins that utilize custom Connection header declarations. Exploitation requirements mandate that the Hono application utilizes the vulnerable proxy() function to forward responses from an origin server that specifies custom headers within the Connection response header field.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper implementation of HTTP message forwarding mechanics within the Proxy Helper proxy() function in hono/proxy. According to RFC 9110 Section 7.6.1, an intermediary must remove any header fields listed within a message's Connection header field before forwarding the message to downstream clients, in addition to stripping well-known hop-by-hop headers. While the proxy() function correctly removed standard hop-by-hop headers—including the Connection header itself—from origin responses, it failed to parse and remove the specific response headers explicitly named within the origin's Connection header value.\nThe vulnerable component is the proxy() function residing in hono/proxy. Affected versions span from 4.7.0 up to and including 4.12.33. Network exposure is inherent to any deployment utilizing Hono as an API gateway, reverse proxy, or application proxy that handles inbound client requests and forwards outbound responses from upstream origin servers.\nThe step-by-step attack flow proceeds as follows: First, a client initiates an HTTP request through the Hono application acting as a proxy. Second, the Hono proxy forwards the request to an upstream origin server and receives the resulting HTTP response. Third, the origin server returns a response containing a Connection header that lists additional, non-standard headers intended to be hop-by-hop (e.g., Connection: custom-internal-header), alongside the data payload and the custom-internal-header itself. Fourth, the vulnerable proxy() function strips the well-known hop-by-hop headers and the Connection header, but fails to parse the comma-delimited list of headers specified inside the Connection header. Fifth, the proxy forwards the complete response, including the unstripped custom-internal-header, directly to the client. Finally, the client receives connection-scoped or internal metadata that was never intended to traverse the intermediary proxy.\nPost-exploitation impact is characterized by the leakage of internal metadata, which may facilitate further reconnaissance against the upstream origin infrastructure or expose sensitive operational parameters."
}