GHSA-458j-xx4x-4375

What it actually does

The flaw is an HTML injection / cross-site scripting weakness in hono/jsx server-side rendering. Affected versions of the hono npm package improperly handle JSX attribute names, allowing unsafe attribute names to be emitted into rendered HTML. If attacker-controlled input can influence JSX attribute names or object keys that are spread into JSX attributes during SSR, the attacker may be able to inject unexpected HTML attributes or script-capable markup into the server-rendered response. The practical impact depends on how an application uses hono/jsx and whether untrusted data reaches attribute-name construction paths.

Why it matters to the business

Applications using affected versions of hono for JSX server-side rendering may expose users to malicious content in trusted web pages. Successful exploitation can lead to session theft, account actions performed in a victim’s browser, credential phishing, or data exposure visible to the victim session. The CVSS score is moderate and there is no known KEV listing or public exploit maturity indicated, but web-facing applications should still remediate because XSS-class bugs can become high-impact when they affect authenticated workflows, administrative interfaces, or high-traffic pages.

How an attack unfolds

An attacker first identifies an application that uses vulnerable versions of hono/jsx for server-side rendering and finds a route where user-controlled data is used to build JSX attributes, commonly through dynamic attribute names or object spread into JSX elements. The attacker submits crafted input that is interpreted as an attribute name rather than treated safely as data. When the server renders the JSX to HTML, the malformed attribute name is emitted into the response, allowing the attacker to inject additional HTML or event-handler-like behavior depending on browser parsing and the surrounding markup. A victim then loads the affected page and the browser processes the injected markup in the context of the vulnerable site, enabling actions such as stealing tokens accessible to script, modifying page content, redirecting users, or performing same-origin requests as the victim.

How to fix it

Upgrade the hono npm package to version 4.12.14 or later. Rebuild and redeploy all applications, containers, and serverless artifacts that bundle the vulnerable dependency. If immediate upgrade is not possible, avoid using untrusted data as JSX attribute names, prevent spreading untrusted objects directly into JSX props, enforce strict allowlists for permitted attribute names, and sanitize or reject user-controlled keys before rendering. Continue to rely on context-aware output encoding, HttpOnly/SameSite cookies, and a restrictive Content Security Policy as defense-in-depth, but do not treat these controls as a substitute for upgrading.

How to confirm the fix worked

Confirm package resolution shows hono at 4.12.14 or later in package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and deployed artifacts. Run dependency scanners against source repositories and built images to ensure no vulnerable transitive or bundled copy remains. Review SSR code paths for dynamic JSX attribute names, object spreads into JSX elements, or helper functions that convert request-controlled objects into props. Add regression tests that render crafted attribute-name payloads and verify the output does not introduce executable attributes, additional markup, or malformed HTML. For web-facing applications, validate with an authenticated and unauthenticated DAST pass against routes that reflect or store user-supplied content.

Typical attack path

1. Identify a web application using affected hono npm versions with hono/jsx server-side rendering.
2. Locate a page or endpoint where untrusted input influences JSX attribute names, dynamic props, or spread attributes.
3. Craft a payload that abuses improper JSX attribute-name handling to inject unsafe HTML attributes or markup into the rendered response.
4. Deliver the payload through a URL parameter, form field, stored profile/content field, API request, or other application-specific input path.
5. Induce a victim to view the server-rendered page or wait for normal user/admin access if the payload is stored.
6. Execute browser-side actions in the victim’s session, such as content spoofing, session/token theft where accessible, phishing, or same-origin requests.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse proxy logs, WAF alerts, application request logs, and error logs for requests to SSR-rendered routes containing suspicious HTML attribute-name or event-handler payloads. Focus on parameters, form bodies, JSON keys, and stored content fields that may become JSX props or attribute names. Look for payloads attempting to break out of attribute context, inject event handlers, introduce script-capable elements, or use encoded variants of these strings. Also review rendered-response telemetry if available, CSP violation reports, browser security reports, and frontend error monitoring for unexpected inline event handlers, blocked script execution, or anomalous redirects. If stored content can be rendered through hono/jsx, inspect recent user-generated records for malicious attribute-like keys or HTML fragments. No named threat actors or known exploitation campaigns are associated with this advisory in the provided data.

• onerror=
• onload=
• onclick=
• onmouseover=
• autofocus onfocus=
• javascript:
• <script
• </script>
• <img
• <svg
• <iframe
• srcdoc=
• xlink:href=
• %3Cscript
• %3Cimg
• %3Csvg
• %22%20onerror%3D
• %27%20onerror%3D
• &#x3c;script
• &#60;script

What your security team should do

• Prioritize upgrading hono to 4.12.14 or later in all applications that use hono/jsx SSR, especially internet-facing or authenticated applications.
• Search code for untrusted object spread into JSX props and dynamic attribute-name generation, and refactor to use explicit allowlisted props.
• Add dependency checks in CI/CD to block vulnerable hono versions from being reintroduced.
• Deploy or tighten Content Security Policy, HttpOnly cookies, SameSite cookie attributes, and anti-CSRF controls to reduce browser-side exploitation impact.
• Review access logs, application logs, and web telemetry for unusual payloads containing JSX/HTML attribute injection patterns against SSR routes.
• If suspicious payloads are found, investigate affected user sessions, administrative actions, credential resets, and downstream same-origin requests around the time of exposure.