CVE-2026-44455

What it actually does

This is a server-side rendering HTML injection vulnerability in Hono's JSX support before version 4.12.16. When an application passes untrusted data as a JSX element tag name through the programmatic jsx() or createElement() APIs, Hono fails to properly validate or constrain the tag name before emitting HTML. A crafted tag-name value can break out of the intended element context and inject arbitrary HTML into the rendered response. In practical terms, this can become reflected or stored cross-site scripting depending on how the affected application sources and persists the tag-name input. The CVSS profile indicates network exploitability, high attack complexity, no privileges required, user interaction required, changed scope, and limited confidentiality and integrity impact.

Why it matters to the business

Applications using vulnerable Hono JSX server-side rendering patterns may expose users to malicious page content, credential phishing, session-token theft where cookies or tokens are accessible to script, unauthorized actions performed in a victim browser, or content tampering. The risk is lower than a default remote code execution issue because exploitation requires a specific unsafe coding pattern and user interaction, and there is no known CISA KEV listing or public exploit maturity reported. However, Hono is commonly used in modern JavaScript edge and server applications, so organizations should still prioritize identifying exposed SSR paths that accept user-controlled element names and upgrade affected packages.

How an attack unfolds

An attacker first identifies an application built with Hono that performs server-side rendering using hono/jsx and accepts user-controlled input that is later used as a JSX tag name through jsx() or createElement(). The attacker crafts a tag-name payload designed to terminate or escape the intended element name and introduce attacker-controlled HTML, such as a script-bearing construct or event-handler-based markup. The payload is delivered through a route parameter, query parameter, form field, API request, stored profile/content field, or other input source that the application renders. When a victim visits the affected page or otherwise triggers rendering of the malicious value, the server emits HTML containing the injected content. The victim's browser interprets that content in the context of the vulnerable application origin, allowing the attacker to run browser-side actions such as reading accessible page data, modifying displayed content, redirecting the user, or attempting to steal credentials or tokens not protected by browser controls.

How to fix it

Upgrade Hono to version 4.12.16 or later wherever hono/jsx is used. If package manifests pin Hono directly, update the hono package to >=4.12.16 and regenerate lockfiles; if Hono is included transitively, update the parent package or force an override/resolution to a fixed Hono version after compatibility testing. As defense in depth, do not allow untrusted input to define JSX element tag names; map user-provided values to a strict allowlist of known safe tag names instead. Reject tag names containing characters outside a conservative pattern such as letters, digits, and a small set of explicitly required safe separators. Avoid programmatic createElement()/jsx() calls with raw request, profile, CMS, or API-provided values as the tag parameter. Maintain contextual output encoding and deploy a restrictive Content Security Policy to reduce browser-side impact if HTML injection occurs.

How to confirm the fix worked

Confirm dependency inventories, package manifests, lockfiles, container images, and deployed artifacts show Hono version 4.12.16 or later. Search code for imports from hono/jsx and programmatic use of jsx() or createElement(), then verify the first argument is constant or selected from a strict allowlist rather than directly derived from request/query/body/path parameters or persisted user content. Add a regression test that renders a malicious tag-name candidate and confirms it is rejected, sanitized, or not emitted as executable/interpretable HTML. Use software composition analysis and CI dependency checks to prevent reintroduction of Hono versions below 4.12.16.

Typical attack path

1. Identify a Hono application endpoint that performs server-side rendering with hono/jsx.
2. Find an input path where user-controlled data can influence a JSX tag name passed to jsx() or createElement().
3. Craft a malformed tag-name value that breaks out of the intended element context and injects unintended HTML.
4. Deliver the payload through a reflected request parameter or store it in application-managed content that will later be rendered.
5. Induce a user to view the affected page or wait for normal users to access the stored content.
6. Leverage injected HTML or script-capable markup in the victim browser to phish, redirect, alter content, or access data available to the page context.

How to detect it

To determine whether this was already exploited, review web access logs, CDN/WAF logs, reverse proxy logs, application request logs, and application error logs for suspicious HTML or script-like strings submitted to endpoints that perform server-side rendering. Focus on parameters, route segments, JSON body fields, form fields, and stored user-content update actions that could affect rendered component or element names. Look for attempts to inject closing brackets, event handlers, script-capable SVG/MathML markup, iframes, meta refresh tags, JavaScript URLs, or image error handlers. If the application stores user-generated display configuration or content, inspect those records through normal administrative/export tooling for embedded HTML fragments in fields expected to contain tag/component names. Browser telemetry, CSP violation reports, EDR web-session telemetry, and SIEM events may show secondary effects such as blocked inline script execution, unexpected outbound requests from user browsers, credential-phishing redirects, or anomalous same-origin actions immediately after visiting affected pages. There are no named threat actors, KEV listing, or known mature exploit reports in the provided intelligence, so detection should be behavior- and payload-focused rather than actor-specific.

• <script
• </script
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• <iframe
• </iframe
• <svg
• </svg
• <math
• </math
• <img
• srcdoc=
• <meta
• http-equiv="refresh"
• data:text/html
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• </

What your security team should do

• Inventory all JavaScript, TypeScript, edge, and server-side rendering services that depend on Hono, including containerized and serverless deployments.
• Upgrade Hono to 4.12.16 or later and redeploy affected applications after testing.
• Prioritize review of routes that render user-generated content, route parameters, search parameters, CMS fields, profile fields, or API-provided display components through hono/jsx.
• Search source code for jsx( and createElement( usage and verify user input cannot control the tag-name argument except through a strict allowlist.
• Add SCA policy gates to fail builds using Hono versions earlier than 4.12.16.
• Deploy or tighten Content Security Policy, HttpOnly/Secure/SameSite cookie attributes, and anti-phishing controls to reduce XSS impact.
• Review web access logs and application logs for suspicious HTML/script fragments in parameters or stored content fields, especially before the upgrade window.