Hono CVE-2026-71849

Two simultaneous conditions must hold: (1) the application must use Hono version 4.7.0-4.12.33 and invoke the proxy() function from hono/proxy to forward responses from a backend origin, and (2) that origin must include one or more non-standard header names in its Connection response header field (e.g., Connection: x-backend-token, x-internal-id), a non-default behavior not present in most standard HTTP origins. Applications proxying origins that only use standard hop-by-hop headers - as explicitly stated in the advisory - are not affected. No authentication is required to receive the leaked headers since the client is the natural recipient of the proxied response (PR:N). Exploitation is further limited by the need for the attacker to be in a position to observe or receive the proxied HTTP response and to know or infer which non-standard headers may be present.

The NVD-assigned CVSS 3.7 (Low) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N accurately reflects the constrained nature of this flaw. High attack complexity (AC:H) is warranted because exploitation depends on the origin server actively declaring non-standard headers as hop-by-hop via its Connection response field, which is not typical behavior in default deployments. The confidentiality impact is limited to connection-scoped or internal metadata headers, not bulk data exfiltration. No EPSS data was provided in the intelligence; KEV status is absent and no POC exploit code is known, both consistent with the low severity rating. The practical risk is narrow: organizations running Hono as a proxy in front of origins that use custom Connection-designated headers face a compliance gap and potential metadata leakage, while those proxying standard origins are entirely unaffected. This is a correctness and defense-in-depth issue rather than an urgent exploitation priority; the primary driver for patching is RFC compliance and eliminating any possibility of internal header leakage.

A client issues a request through a Hono-based proxy to an origin server; the origin responds with Connection: x-internal-session alongside the header X-Internal-Session: <token>, intending the session token to be discarded by the intermediary. Because the unpatched proxy() function does not parse the Connection field to strip named headers, the client receives X-Internal-Session: <token> directly, potentially exposing backend session context or internal routing metadata. No POC exploit code has been identified at time of analysis.