CVE-2026-84363: Hono: Query parser reads parameters after the URL fragment, causing cache-key and proxy interpretation differentials
Summary
Hono's query parsing does not stop at the URL fragment: a ? appearing after a # is treated as the start of a query string. As a result, the application can read request parameters that no other component involved in handling the request can see.
Details
A fragment is never part of the query, and every standard URL consumer — browsers, new URL(), reverse proxies — ignores everything from the first # onward. Hono's routing followed that rule; its query helpers did not.
For one and the same request, this produces an interpretation differential:
- A component in front of the application that inspects the query string — filtering rules, parameter allow/deny lists, access logging — observes no parameters, while the application reads and acts on them. - The cache middleware removed the fragment when building its cache key, so a response influenced by parameters carried inside the fragment could be stored under a key that did not reflect them and later returned to other users.
The same divergence reaches request validation and any middleware that reads query parameters.
This requires a request target containing a literal # to reach the application. Deployments on runtimes that normalise such a target — including Cloudflare Workers — are not affected, and neither are those behind an intermediary that strips the fragment.
Impact
An attacker can cause the application to act on parameters that components in front of it never observe.
This may lead to:
- filtering rules, allow/deny lists, and audit logging being blind to parameters the application still processes - a cached response being stored under a key that does not reflect the parameters used to produce it, and served to other users - stored cross-site scripting, where such a parameter is reflected into a cached HTML response without escaping
This issue affects applications that read query parameters and run on a runtime that passes a literal # through to the request URL.
Other sources
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.13.5, Hono's query helpers treat a question mark after a literal hash fragment as the start of a query string, so the application can read request parameters that browsers, new URL(), reverse proxies, filtering rules, parameter allow and deny lists, access logging, request validation, and other middleware do not observe. The Cache Middleware removes the fragment when building its cache key, allowing a response influenced by parameters inside the fragment to be stored under a key that omits those parameters and later served to other users. This can bypass filtering and auditing, poison cached responses, and enable stored cross-site scripting when an affected parameter is reflected into cached HTML without escaping. Exploitation requires a runtime and intermediary path that passes a literal hash character through to the request URL; Cloudflare Workers and intermediaries that strip fragments are not affected. This issue is fixed in version 4.13.5.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/honoto a version that resolves this vulnerability.Fixed in 4.13.5 - Upgrade
Upgrade
Honoto a version that resolves this vulnerability.Fixed in 4.13.5
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments using Hono before 4.13.5 are exposed only when the runtime and intermediary path pass a literal hash character through in the request URL. Cloudflare Workers and intermediaries that strip fragments are not affected.
What does an attacker need to exploit this issue?
An attacker must be able to send a request whose literal hash fragment reaches Hono and includes a question mark followed by parameters. Exploitation is more consequential where those parameters affect application behavior, filtering, logging, validation, or cacheable responses.
When can this lead to cache poisoning or stored cross-site scripting?
Cache poisoning can occur when Hono Cache Middleware stores a response influenced by parameters after the fragment under a cache key that omits those parameters. Stored cross-site scripting is possible if an affected parameter is reflected into cached HTML without escaping.
What should be done if upgrading cannot happen immediately?
Ensure the runtime or intermediary removes literal URL fragments before requests reach Hono. Review routes using query helpers and Cache Middleware, especially where query-controlled values are reflected into HTML or used for access controls, filtering, or validation.