CVE-2026-59895

What it actually does

CVE-2026-59895 is a server-side rendering cross-site scripting flaw in Hono's `hono/css` helper. In Hono versions 4.0.0 through versions before 4.12.27, `cx()` can combine plain string class names and incorrectly mark the resulting value as already escaped. If an application passes attacker-controlled data into `cx()` and then renders it into a JSX `class` or `className` attribute during SSR, the attacker can break out of the HTML attribute context and inject arbitrary markup or script. The vulnerability requires a vulnerable code path where untrusted input influences class names and a victim user visits the rendered page.

Why it matters to the business

Successful exploitation can allow an attacker to run JavaScript in a user's browser in the context of the affected application, potentially leading to session theft, account actions performed as the user, phishing overlays, data exposure from the page, or malicious redirects. The CVSS score is moderate and EPSS is currently low, and there is no known KEV listing or ransomware association, but affected applications should still be upgraded because the bug is easy to trigger where user-controlled class names are rendered server-side.

How an attack unfolds

An attacker first identifies a Hono-based application that renders JSX on the server and accepts user-controlled values that influence a CSS class name, such as a theme, style, component variant, profile field, query parameter, route parameter, or stored content field. The application passes that value into `cx()` from `hono/css`, then renders the result into a JSX `class` or `className` attribute. Because vulnerable Hono versions treat the composed class string as escaped without properly HTML-escaping plain string input, the attacker supplies a value containing quote characters and HTML or event-handler syntax. When the server renders the page, the malicious value escapes the class attribute and injects attacker-controlled markup. A victim who visits the page triggers the injected script or browser behavior, allowing the attacker to perform actions available to that user or steal sensitive browser-accessible data.

How to fix it

Upgrade Hono to version 4.12.27 or later. If package manifests use semver ranges, refresh lockfiles and redeploy so the runtime actually uses the fixed version. Audit SSR JSX code for imports from `hono/css`, especially calls to `cx()` where any argument can come from request parameters, cookies, headers, database content, user profiles, CMS fields, or other untrusted sources. As a defense-in-depth measure, do not pass untrusted values directly into class names; map user input to a strict allowlist of known class tokens. Ensure output encoding is applied according to HTML attribute context. Consider adding or tightening a Content Security Policy to reduce the impact of any residual XSS, but do not treat CSP as a substitute for upgrading.

How to confirm the fix worked

Confirm that all deployed applications and containers resolve Hono to 4.12.27 or later using package manager commands such as `npm ls hono`, `pnpm why hono`, `yarn why hono`, or software composition analysis. Inspect lockfiles such as `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, or `bun.lockb` to verify no vulnerable `hono` version from 4.0.0 through 4.12.26 remains. Search source code for `hono/css` and `cx(`, then verify that no untrusted input can reach JSX `class` or `className` attributes without allowlisting. In a non-production test environment, attempt to render a harmless attribute-breakout payload through any suspected className input and confirm it is encoded as text rather than interpreted as markup. After deployment, verify the running artifact or container image contains the updated package, not only the source repository.

Typical attack path

1. Find a public page or stored-content feature built with Hono server-side rendering.
2. Identify a parameter or field that influences a rendered CSS class name, variant, theme, or component state.
3. Submit a payload that includes attribute-breaking characters and injected HTML or JavaScript event handlers.
4. Wait for the vulnerable page to be rendered by the server using `cx()` from `hono/css`.
5. Induce a victim user to view the affected page, or rely on normal traffic to a stored malicious page.
6. Execute script in the victim's browser under the affected application's origin and abuse the victim's session or visible page data.

How to detect it

To determine whether this was already exploited, review HTTP access logs, reverse proxy logs, CDN/WAF logs, application request logs, and any audit logs for content/profile/theme/settings updates that later render on server-side pages. Focus on inputs that could influence visual style, CSS class, component variant, theme, color, layout, or stored user-generated content. Look for quote characters followed by HTML tags, event-handler attributes, JavaScript URLs, SVG payloads, or image error handlers in query strings, form posts, JSON bodies, cookies, referrers, and stored content fields. Correlate suspicious submissions with subsequent page views by privileged users or high-value accounts. Check browser-side telemetry, CSP violation reports, and WAF alerts for blocked or executed inline script, unexpected external script loads, or unusual redirects from affected pages. If exploitation is suspected, review account activity around the time of exposure for unauthorized setting changes, token creation, email/password changes, administrative actions, or abnormal API use from the victim's session.

• \"><script
• '"><script
• \" onmouseover=
• \" onerror=
• \" autofocus onfocus=
• \" onclick=
• '><img src=x onerror=
• \"><img src=x onerror=
• <svg/onload=
• <svg onload=
• javascript:alert(
• javascript:fetch(
• document.cookie
• localStorage.getItem
• sessionStorage.getItem
• new Image().src=
• fetch('http
• fetch(\"http
• eval(atob(
• String.fromCharCode(
• </style><script
• </textarea><script
• className=\"\"><
• class=\"\"><

What your security team should do

• Prioritize upgrading all Hono deployments to 4.12.27 or later, especially internet-facing SSR applications.
• Inventory applications using `hono/css` and identify code paths where request-controlled or user-stored data reaches `cx()` or JSX `className` attributes.
• Add static checks or code review rules that prohibit raw user input from being used as CSS class names without an allowlist mapping.
• Review web access logs and application logs for attribute-breakout and script-injection payloads in query strings, form bodies, headers, and stored content updates.
• If suspicious payloads are found, investigate affected user sessions, administrative actions, profile/content changes, and any unusual redirects or account changes following visits to vulnerable pages.
• Deploy or tighten CSP using nonces or hashes where practical to limit script execution impact, while still completing the package upgrade.
• Ensure dependency scanning covers JavaScript lockfiles and transitive dependencies so vulnerable Hono versions are not reintroduced.