EUVD-2026-54580
GHSA-f23p-vx2j-j53r
Severity by source
AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N
AC:H reflects the timing/instance race requirement; PR:L because exploitation occurs in authenticated user sessions; UI:R because a second user must make a request; C:H only as no writes or availability effects are possible.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
Hono is a Web application framework that provides support for any JavaScript runtime. From 3.8.0 to 4.12.33, memo() from hono/jsx retains the result of a server side render and reuses it for later renders with comparator equal props, and request scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request. Components wrapped with memo() are compared by props alone; values read implicitly during rendering, such as JSX Context through createContext() and useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage, do not participate, and the retained result lives as long as the wrapped component, so it outlives the request that produced it. A user may receive a response containing HTML rendered for another user when both render the same memoized component with comparator equal props on the same warm instance, which may disclose another user's account or profile data, disclose request scoped secrets embedded in HTML such as CSRF tokens, or expose role specific content to users who should not receive it. This issue is fixed in version 4.12.34.
AnalysisAI
Cross-user HTML disclosure in Hono's server-side rendering affects all applications using hono/jsx with memo()-wrapped components that read request-scoped context. On a warm server instance, when two requests share comparator-equal props, the memoized render from the first request is served to the second user verbatim - bypassing per-request context isolation for values obtained via createContext()/useContext(), useRequestContext(), or getContext(). This can leak another user's profile data, CSRF tokens embedded in HTML, or role-gated content. No public exploit or CISA KEV listing exists at time of analysis; the vendor released a confirmed fix in v4.12.34.
Technical ContextAI
Hono is a lightweight, multi-runtime JavaScript web framework (CPE: cpe:2.3:a:honojs:hono:*:*:*:*:*:*:*:*) supporting Cloudflare Workers, Bun, Deno, and Node.js. The vulnerability is rooted in CWE-488 (Exposed Data Element to Wrong Session): the memo() higher-order component in hono/jsx was designed to cache SSR output for performance, storing the rendered JSX tree in a closure-captured variable (computed) and invalidating it only when props change via the propsAreEqual comparator. Request-scoped ambient context - provided by createContext()/useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage - is read during rendering but is invisible to the memoization key. The fix at commit 0c45036 removes SSR-path memoization entirely: the wrapper now calls component(props) on every render, eliminating the cross-request state retention while preserving the propsAreEqual hook solely for the DOM renderer.
RemediationAI
Upgrade hono to version 4.12.34 or later (npm install hono@4.12.34 or npm install hono@latest). The patch is confirmed at https://github.com/honojs/hono/commit/0c45036d6b0ddf42ab2fa44639dc8710825d5c0f and the release is tagged at https://github.com/honojs/hono/releases/tag/v4.12.34. If an immediate upgrade is not feasible, the most effective compensating control is to refactor any memo()-wrapped components that read request-scoped context: move all per-request values (user identity, CSRF tokens, role data) into props explicitly, ensuring they participate in the memoization comparison - this carries the trade-off of increased prop-drilling and potentially more frequent re-renders. Alternatively, remove memo() entirely from any component that reads ambient context; this eliminates the caching benefit but fully restores correct per-request isolation with no functional side effects. Do not rely on rate limiting or request throttling as mitigation; the race condition can occur between legitimate concurrent users on any busy warm instance.
The adapter @hono/node-server allows you to run your Hono application on Node.js. Rated high severity (CVSS 7.5), this v
Hono, a web framework, prior to version 4.6.5 is vulnerable to bypass of cross-site request forgery (CSRF) middleware by
Quadratic-complexity denial of service in Hono's `languageDetector` middleware (versions 4.12.0-4.12.33) allows unauthen
Hono is a Web application framework that provides support for any JavaScript runtime. Rated medium severity (CVSS 5.3),
@hono/node-server is an adapter that allows users to run Hono applications on Node.js. Rated medium severity (CVSS 5.3),
Hono is a Web application framework that provides support for any JavaScript runtime. Rated medium severity (CVSS 5.0),
Hono is a web framework written in TypeScript. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploita
Hono is a Web application framework that provides support for any JavaScript runtime. [CVSS 8.2 HIGH]
Hono versions before 4.11.4 allow JWT algorithm confusion attacks through improper algorithm validation in the JWK/JWKS
Hono before version 4.11.4 contains a JWT algorithm confusion vulnerability in its JWK/JWKS verification middleware that
Hono's `proxy()` function in the `hono/proxy` Proxy Helper leaks connection-scoped response headers to downstream client
Hono versions prior to 4.12.4 suffer from an authentication bypass in serveStatic when combined with route-based middlew
Same weakness CWE-488 – Exposure of Data Element to Wrong Session
View allShare
External POC / Exploit Code
Leaving vuln.today