Hono CVE-2026-71850

Exploitation requires four concurrent conditions: (1) the Hono application uses hono/jsx for server-side rendering; (2) at least one component is wrapped with memo() and reads per-user or per-request data via createContext()/useContext(), useRequestContext(), or getContext() rather than through props; (3) two requests with comparator-equal props hit the same warm server instance in sequence - the cache must be populated by the first render before the second request arrives; and (4) per the CVSS PR:L vector, the attacker must be an authenticated low-privilege user. Applications that use memo() only on purely static or prop-driven components are not affected. Client-side-only rendering is explicitly unaffected per the advisory. This is a non-default misconfiguration: the vulnerable pattern (memo() combined with ambient context reads) must be actively present in application code and is not introduced by Hono itself out of the box.

The official CVSS 3.1 score of 4.8 (Medium) accurately reflects realistic exploitation difficulty: AV:N confirms the attack surface is the network, but AC:H flags a timing dependency - both requests must reach the same warm server instance with matching props, which is not reliably controllable by an external attacker. PR:L indicates authenticated low-privilege users are the relevant exploitation context, and UI:R acknowledges that a second user interaction is required to populate the cache. Despite C:H confidentiality impact, the combination of AC:H and PR:L appropriately constrains the effective risk score. There is no CISA KEV listing and no public PoC identified, so real-world exploitation is likely opportunistic on dense shared-instance deployments (e.g., serverless platforms where hot instances serve many users) rather than targeted. EPSS data was not included in the provided intelligence, so probability-based exploitation likelihood cannot be quantified. The highest-risk scenario is a high-traffic application using memo() on authenticated UI components where many users share similar props - in that environment, cross-user leakage of CSRF tokens or PII is practically achievable without sophisticated attack tooling.

User A authenticates and requests a page that renders a memo()-wrapped component displaying their username and a CSRF token, both sourced from hono/context-storage. User B subsequently sends a request to the same endpoint on the same warm server instance with props that match User A's (e.g., a shared layout component with identical static props). Because the memoized render from User A's request remains cached in the component closure, the server returns User A's HTML - including their CSRF token and profile data - to User B. No public PoC is available, but the vulnerability is mechanically straightforward on high-traffic deployments where warm instances serve multiple concurrent users.