CVE-2026-71850: 
JavaScript vulnerability analysis and mitigation

CVE-2026-71850 is a cross-user data disclosure vulnerability in the Hono web application framework's memo() function from hono/jsx. When used for server-side rendering (SSR), memo() retains and reuses rendered HTML output across requests when props compare as equal, without accounting for request-scoped context values, potentially serving one user's rendered HTML to another user. The vulnerability affects Hono versions >= 3.8.0 and < 4.12.34 (npm package hono). It was published on August 3, 2026, and added to the GitHub Advisory Database on August 7, 2026. It carries a CVSS v3.1 base score of 4.8 (Moderate) (Github Advisory, Hono Security Advisory).

The root cause is classified as CWE-488 (Exposure of Data Element to Wrong Session). The memo() function in src/jsx/base.ts cached the rendered output of a component and reused it for subsequent renders when props were deemed equal by a comparator function, but it did not consider ambient request-scoped values obtained via createContext()/useContext(), useRequestContext() from hono/jsx-renderer, or getContext() from hono/context-storage. Because the memoized component is skipped entirely on a cache hit, the current request's context values are never read — the retained HTML from a prior request is returned instead. The fix (commit 0c45036) removes the caching logic entirely from the SSR path, making memo() a pass-through wrapper that always invokes the component function, while preserving the DOM_MEMO marker for the DOM renderer (Hono Security Advisory, Fix Commit).

Successful exploitation can cause a user to receive an HTTP response containing HTML rendered for a different user's request, when both users trigger rendering of the same memoized component with props that compare as equal on the same warm server instance. This may disclose another user's account or profile data, expose request-scoped secrets embedded in HTML (such as CSRF tokens), or reveal role-specific content to unauthorized users. There is no integrity or availability impact; the vulnerability is purely a confidentiality issue affecting server-side rendered Hono applications (Github Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported. The EPSS score is approximately 0.00164 (very low probability of exploitation in the near term). Exploitation is opportunistic and depends on timing: two users must concurrently or sequentially hit the same warm server instance, rendering the same memoized component with comparator-equal props, with the second user receiving the first user's cached HTML. No CISA KEV catalog listing has been identified for this CVE (Github Advisory, Feedly).

1. Identify a vulnerable target: Locate a Hono application (versions 3.8.0–4.12.33) that uses hono/jsx for server-side rendering and wraps a component reading ambient context (e.g., useContext(), useRequestContext(), or getContext()) with memo().
2. Trigger an initial render: As User A (authenticated), send a request that causes the memoized component to render and cache HTML containing User A's data (e.g., profile information, CSRF token, or role-specific content).
3. Send a concurrent or subsequent request: As User B, send a request to the same endpoint with props that compare as equal to User A's props (e.g., identical or structurally equivalent component props), targeting the same warm server instance before the cached result is invalidated.
4. Receive cross-user HTML: Because memo() returns the cached render result without invoking the component, User B's response contains HTML rendered with User A's request-scoped context values, disclosing User A's data.

Note: Exploitation requires both requests to reach the same warm server instance and is timing-dependent. No public exploit tooling is known. (Hono Security Advisory)

• Logs: Unexpected user-specific data (usernames, account IDs, CSRF tokens) appearing in server access logs or application logs for requests from different authenticated users accessing the same endpoint.
• Application Behavior: User reports of seeing another user's name, profile data, or account information on pages that should be personalized; CSRF token mismatches causing form submission failures for users who received another user's token.
• Network: Responses to requests from User B containing HTML fragments referencing User A's session-specific identifiers or personal data, detectable via response content inspection or anomaly detection on rendered output.

No specific file system, registry, or process-level IOCs are associated with this vulnerability, as exploitation occurs entirely within the application's rendering logic. (Hono Security Advisory)

Upgrade the hono npm package to version 4.12.34 or later, which removes the SSR caching behavior from memo() entirely. As a workaround for applications that cannot immediately upgrade, avoid wrapping components that read ambient request-scoped context (via useContext(), useRequestContext(), or getContext()) with memo(); instead, pass all request-specific values explicitly through props. Applications that do not use hono/jsx for server-side rendering, or that do not use memo(), are not affected (Hono Release v4.12.34, Github Advisory).

The advisory was published by Hono maintainer yusukebe and credited reporter raster0x2a for discovering the issue. The fix was released as part of Hono v4.12.34, which also addressed three other security issues (ReDoS in CORS middleware, algorithmic complexity DoS in Language Middleware, and a proxy header leak). No significant broader media coverage or notable community controversy has been identified beyond the standard advisory and release notes (Hono Release v4.12.34, Hono Security Advisory).