GHSA-crvj-82cr-hjcx

Description

### 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.