Executive brief
Hono's web framework incorrectly processes URL query parameters that appear after a hash fragment (#), allowing applications to read parameters that security proxies, WAFs, and logging systems cannot see. This causes cached responses to be served with incomplete cache keys and can lead to stored XSS vulnerabilities when parameters are reflected without escaping.
Technical details
Hono's query parsing implementation does not follow standard URL semantics: it processes query parameters (introduced by ?) that appear after the URL fragment (#), whereas all standard URL consumers (browsers, new URL(), reverse proxies) correctly discard everything after the first #. The vulnerability is rooted in Hono's query helpers not aligning with its routing layer. Attack preconditions require the runtime to pass literal # characters to the application (affected runtimes include Node.js; Cloudflare Workers normalize fragments and are unaffected). An attacker can craft URLs like `/page#?admin=true` to inject parameters invisible to upstream WAFs, access control filters, and audit logging. In cached deployments, responses influenced by these hidden parameters are stored under cache keys that do not reflect them, leading to cache poisoning and potential XSS when parameters are reflected without escaping. The fix was released in version 4.13.5.
Affected products
- Hono hono < 4.13.5
Timeline
- 2026-08-26: disclosed
- 2026-08-26: patched: Version 4.13.5 released
- 2026-09-08: advisory