Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-08-07T19:18:54.240Z",
  "pubdate": "2026-08-07T19:18:54.240Z",
  "executiveSummary": "An information disclosure vulnerability exists in the Hono web application framework from version 3.8.0 to 4.12.33, specifically within the memo() function provided by hono/jsx.\nThe vulnerability arises because the component caching mechanism retains server-side render results based strictly on explicit props comparison, failing to account for request-scoped values and implicit context reads.\nAs a result, a warm server instance can inadvertently reuse and serve cached HTML fragments containing sensitive data from a previous user's request to a different user, provided the component props evaluate as equal.\nThe impact includes the exposure of user-specific profile data, leaked request-scoped secrets such as CSRF tokens embedded within the HTML, and the unauthorized display of role-specific interface elements.\nAttackers do not require special privileges to trigger this vulnerability, but successful exploitation relies on timing, shared warm application instances, and cache collisions across concurrent or sequential user requests.\nThe vulnerability has been addressed and resolved in version 4.12.34.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the memo() utility function located in hono/jsx. When components are wrapped with memo(), the rendering engine caches the generated server-side HTML and reuses it for subsequent render passes whenever the component's explicit props satisfy the equality comparator.\nHowever, the comparison logic fails to incorporate request-scoped values that are read implicitly during the rendering phase. This includes JSX Context elements accessed via createContext() and useContext(), request-scoped helpers such as useRequestContext() from hono/jsx-renderer, and execution context storage accessed via getContext() from hono/context-storage.\nBecause these implicit dependencies are excluded from the prop comparison, the retained memoized result persists across requests, effectively outliving the specific request lifecycle that initially generated it. If a warm server instance processes a request from User A, caching a memoized component containing User A's private data, a subsequent request from User B for the same component with matching props will be served the cached payload intended for User A.\nThe attack flow proceeds as follows: 1) User A initiates a request that renders a memoized component utilizing request-scoped data, populating the cache with sensitive HTML. 2) The server stores this rendered output against the component's prop signature. 3) User B subsequently issues a request that evaluates to the same component props on the same warm server instance. 4) The Hono framework bypasses re-rendering and returns the cached HTML containing User A's data to User B.\nThe affected component is the memo() function in hono/jsx, impacting all Hono framework installations ranging from version 3.8.0 up to and including version 4.12.33.\nExploitation does not require authentication or elevated privileges; standard network exposure to the vulnerable web application is sufficient. The payload behavior consists of leaked sensitive markup rather than malicious code execution."
}