CVE-2026-71850

What it actually does

In affected Hono versions 3.8.0 through 4.12.33, memo() from hono/jsx can cache server-side rendered JSX output based only on component props. Request-scoped values read implicitly during rendering, including JSX context via createContext()/useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage, are not included in the memoization comparison. On a warm server instance, a later request with comparator-equivalent props can receive HTML generated during an earlier user’s request. This can disclose sensitive rendered content such as account details, profile information, role-specific UI, or embedded request-scoped secrets such as CSRF tokens. Integrity and availability are not directly affected.

Why it matters to the business

The flaw can cause one user to see another user’s private page content when affected memoized server-rendered components are reused across requests. Although exploitation requires specific application patterns and matching render conditions, the consequence can include privacy breaches, exposure of account data, leakage of anti-forgery tokens, and regulatory or contractual reporting obligations. The issue is newly published, is not currently listed in CISA KEV, and has no known mature public exploitation, but applications using Hono JSX server-side rendering should still upgrade promptly because the bug can silently leak data through normal application responses.

How an attack unfolds

An attacker needs access to an application endpoint that renders Hono JSX on the server and uses memo() around a component whose output depends on request-scoped context rather than explicit props. First, a victim or privileged user causes the application to render the memoized component on a warm runtime instance, and the rendered HTML is retained. Later, the attacker requests the same route or component state with props that compare equal under the memo() comparator. Because request-scoped context is not part of the comparison, Hono can reuse the victim’s previously rendered HTML instead of rendering fresh content for the attacker’s request. The attacker then receives HTML that may contain another user’s data, role-specific content, or tokens embedded in the page. This is a logic/data-isolation flaw rather than a typical payload-driven injection vulnerability, so exploitation may look like ordinary authenticated traffic.

How to fix it

Upgrade Hono to version 4.12.34 or later. If immediate upgrade is not possible, remove memo() from server-rendered components that consume request-scoped values, or ensure all request-specific data that affects output is passed as explicit props participating in memo comparison. Avoid embedding sensitive request-scoped secrets in memoized server-rendered output. Review uses of hono/jsx memo() together with createContext()/useContext(), useRequestContext(), and getContext() to ensure cached output cannot cross request or user boundaries. Restart long-running application instances after patching to clear any retained memoized render results.

How to confirm the fix worked

Confirm dependency resolution shows Hono 4.12.34 or later in package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb, or the deployed artifact. Run application dependency checks such as npm ls hono, pnpm why hono, yarn why hono, or equivalent tooling for the runtime. Review server-rendered JSX code for memo() wrappers around components that read request-scoped context. Where practical, create a regression test with two simulated users rendering the same memoized component with equal props but different request context; the second response must not contain the first user’s data. After deployment, restart warm instances and verify the running build uses the patched Hono package, not only the source repository.

Typical attack path

1. Identify a Hono application using server-side JSX rendering and affected Hono versions from 3.8.0 through 4.12.33.
2. Find routes where components wrapped in hono/jsx memo() render request-specific data obtained through context APIs rather than through explicit props.
3. Trigger or wait for a victim, administrator, or other user to render the affected component on the same warm server instance.
4. Send a request that renders the same memoized component with comparator-equivalent props.
5. Receive cached HTML generated for the earlier request and inspect it for private data, role-specific content, CSRF tokens, or other request-scoped secrets.

How to detect it

This issue is difficult to detect retrospectively because exploitation can occur through normal application requests and does not require a distinctive malicious payload. Focus on exposure and symptom-based investigation. Review dependency manifests and deployed artifacts for affected Hono versions 3.8.0 through 4.12.33. Review source code for server-side JSX components that use memo() and read request-specific values through context APIs. In application logs, look for user reports, error traces, or session anomalies indicating that a response contained another user’s identifier, role, email, profile details, or CSRF token. If responses are sampled, cached, or captured by observability tooling, compare rendered HTML for the same route across different authenticated users and look for mismatched user-specific values. Web access logs may help correlate incidents by identifying near-adjacent requests to the same route on the same instance or worker from different users, especially where a privileged user request preceded a lower-privileged user request. There are no known public exploit strings, malware artifacts, or network signatures specific to this vulnerability.

• "hono": "3.8.
• "hono": "4.0.
• "hono": "4.1.
• "hono": "4.2.
• "hono": "4.3.
• "hono": "4.4.
• "hono": "4.5.
• "hono": "4.6.
• "hono": "4.7.
• "hono": "4.8.
• "hono": "4.9.
• "hono": "4.10.
• "hono": "4.11.
• "hono": "4.12.0"
• "hono": "4.12.1"
• "hono": "4.12.2"
• "hono": "4.12.3"
• "hono": "4.12.4"
• "hono": "4.12.5"
• "hono": "4.12.6"
• "hono": "4.12.7"
• "hono": "4.12.8"
• "hono": "4.12.9"
• "hono": "4.12.10"
• "hono": "4.12.11"
• "hono": "4.12.12"
• "hono": "4.12.13"
• "hono": "4.12.14"
• "hono": "4.12.15"
• "hono": "4.12.16"
• "hono": "4.12.17"
• "hono": "4.12.18"
• "hono": "4.12.19"
• "hono": "4.12.20"
• "hono": "4.12.21"
• "hono": "4.12.22"
• "hono": "4.12.23"
• "hono": "4.12.24"
• "hono": "4.12.25"
• "hono": "4.12.26"
• "hono": "4.12.27"
• "hono": "4.12.28"
• "hono": "4.12.29"
• "hono": "4.12.30"
• "hono": "4.12.31"
• "hono": "4.12.32"
• "hono": "4.12.33"
• from 'hono/jsx'
• from "hono/jsx"
• memo(
• useRequestContext(
• from 'hono/jsx-renderer'
• from "hono/jsx-renderer"
• getContext(
• from 'hono/context-storage'
• from "hono/context-storage"

What your security team should do

• Prioritize upgrading Hono to 4.12.34 or later in all applications using Hono JSX server-side rendering.
• Inventory code for imports from hono/jsx, hono/jsx-renderer, and hono/context-storage, especially components using memo() with request-scoped context.
• Temporarily remove or disable memoization around server-rendered components that display account, profile, role, permission, or token-derived content until the patch is deployed.
• Invalidate or rotate CSRF tokens or other short-lived page-embedded secrets if affected routes are confirmed to have exposed cross-user HTML.
• Add regression tests that render identical component props under different authenticated request contexts and assert no cross-user content reuse.
• Review access logs and support reports for unusual cases of users seeing another user’s data, while recognizing that exploitation may not produce distinctive technical indicators.
• Restart serverless warm pools, containers, and long-running Node/Bun/Deno/Workers instances after upgrade to eliminate retained memoized output.