GHSA-hvrm-45r6-mjfj
MEDIUMhono/jsx does not isolate context per request, leading to cross-request data disclosure
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
hononpmDescription
Summary
hono/jsx did not isolate context values per request during server-side rendering. While an async component was suspended on await, its provided context value stayed observable to other requests rendering concurrently, so useContext() could return a value from a different in-flight request.
Details
During server-side rendering, context values were kept in a process-wide structure rather than scoped to each request's render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request's context.
This affects the usual ways request-scoped data is passed through a server-rendered JSX tree:
createContext()/useContext()- the
jsxRenderermiddleware anduseRequestContext()
It arises only when context is read after an await inside an async component while requests render concurrently. Reading context synchronously (before any await), purely synchronous rendering, and client-side (DOM) rendering are not affected.
Impact
Under concurrent requests, a response could be rendered with another request's context. A user may receive HTML rendered for a different user, and an authorization check performed after an await may be evaluated against another user's data.
This may lead to:
- disclosure of rendered output intended for another user
- authorization decisions made with the wrong request's context
- cross-request mixing of session or other request-scoped state
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | hono | ≥ 4.11.8&&< 4.12.27 | 4.12.27 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hono. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update hono to 4.12.27 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hvrm-45r6-mjfj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hvrm-45r6-mjfj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-hvrm-45r6-mjfj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hvrm-45r6-mjfj in your dependencies?
O3 detects GHSA-hvrm-45r6-mjfj across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.