Hono is a Web application framework that provides support for any JavaScript runtime. From 3.8.0 to 4.12.33, memo() from hono/jsx retains the result of a server side render and reuses it for later renders with comparator equal props, and request scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request. Components wrapped with memo() are compared by props alone; values read implicitly during rendering, such as JSX Context through createContext() and useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage, do not participate, and the retained result lives as long as the wrapped component, so it outlives the request that produced it. A user may receive a response containing HTML rendered for another user when both render the same memoized component with comparator equal props on the same warm instance, which may disclose another user's account or profile data, disclose request scoped secrets embedded in HTML such as CSRF tokens, or expose role specific content to users who should not receive it. This issue is fixed in version 4.12.34.
### Summary
The built-in CORS middleware (`hono/cors`) parses the attacker-controlled `Access-Control-Request-Headers` request header during a preflight (`OPTIONS`) request using a regular expression whose running time is quadratic in the input length. A single request carrying a long run of whitespace can consume seconds of CPU, and repeated requests can render the service unresponsive. This parsing runs under the default configuration.
### Details
On a CORS preflight, when `allowHeaders` is not configured - the default - the middleware reflects and parses the `Access-Control-Request-Headers` value. The parser used a whitespace-tolerant regular expression whose backtracking makes the work grow quadratically (O(n²)) with the length of the value when it contains a long whitespace sequence without a delimiter.
Because the header value is bounded only by the deployment's maximum HTTP header size, a single preflight can block request processing for a noticeable amount of time; on runtimes that share one execution thread across requests, this stalls concurrent requests as well. No authentication, special origin, or user interaction is required.
This issue arises for any application using `cors()` with the default (or an empty) `allowHeaders`. Applications that set a non-empty `allowHeaders` do not reach the affected path.
### Impact
An unauthenticated attacker can send preflight requests that each consume disproportionate CPU relative to their size, degrading or denying service. This is a denial-of-service issue only; it does not expose or modify data.
A cross-site scripting (XSS) vulnerability exists in honojs hono versions from 4.0.0 up to but not including 4.12.27. The cx() function in hono/css composes class names from plain strings but marks them as already escaped without properly HTML-escaping input. This allows untrusted className values used in JSX class attributes during server-side rendering to inject arbitrary markup. The issue is fixed in version 4.12.27.
Hono versions before 4.10.3 have a vulnerability in their CORS middleware where the Vary header from incoming requests is copied into responses. This can allow attackers to inject arbitrary Vary header values, potentially causing cache key pollution and inconsistent CORS enforcement in shared cache or proxy environments. The issue is fixed in version 4.10.3.
Hono before 4.10.3 contains a flaw in its CORS middleware: when the origin is not set to "*", the middleware copies the Vary header from the incoming request into the response. Because Vary is a response header that should be managed by the server, an attacker can supply arbitrary Vary values that are reflected into the response, potentially causing cache key pollution and inconsistent CORS enforcement in environments that rely on shared caches or proxies.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.25, the Body Limit Middleware trusts the request's Content-Length header to decide whether a body is within the limit. On AWS Lambda (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge) the body is delivered fully buffered and the adapter builds the request with the client-declared Content-Length, which need not match the actual payload. A client can declare a tiny Content-Length while sending a much larger body, slipping past the limit. This vulnerability is fixed in 4.12.25.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.25, with credentials: true and no explicit origin (the default wildcard), the CORS Middleware reflects the request's Origin and sends Access-Control-Allow-Credentials: true. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins. This vulnerability is fixed in 4.12.25.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.25, on AWS Lambda, the ALB single-header response and the VPC Lattice v2 response join multiple Set-Cookie headers into one comma-separated value. Because commas also appear inside cookie attributes (for example Expires dates), clients cannot split the value back into individual cookies and silently drop or misparse them. This vulnerability is fixed in 4.12.25.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.21, the jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request. This vulnerability is fixed in 4.12.21.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.21, the serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes. This vulnerability is fixed in 4.12.21.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.16, Improper handling of JSX element tag names in hono/jsx allowed unvalidated tag names to be directly inserted into the generated HTML output. When untrusted input is used as a tag name via the programmatic jsx() or createElement() APIs during server-side rendering, specially crafted values may break out of the intended element context and inject unintended HTML. This vulnerability is fixed in 4.12.16.
Hono versions prior to 4.12.18 have a vulnerability in their JSX server-side rendering where untrusted input in style object values or property names can inject additional CSS declarations. This CSS injection does not allow JavaScript execution or HTML attribute breakout but can manipulate page visuals, cause phishing overlays, or trigger outbound requests via CSS resource references. The vulnerability is fixed in version 4.12.18.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.12, a path handling inconsistency in serveStatic allows protected static files to be accessed by using repeated slashes (//) in the request path. When route-based middleware (e.g., /admin/*) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass. This vulnerability is fixed in 4.12.12.
Hono versions prior to 4.12.7 have a prototype pollution vulnerability related to the parseBody({ dot: true }) feature. This feature allows dot notation in form field names to create nested objects, but does not filter the __proto__ key, enabling crafted input like __proto__.x to create objects with __proto__ properties. While Hono itself does not directly modify Object.prototype, unsafe merging of parsed results into other objects can lead to prototype pollution.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.12.4, when using streamSSE() in Streaming Helper, the event, id, and retry fields were not validated for carriage return (\r) or newline (\n) characters. Because the SSE protocol uses line breaks as field delimiters, this could allow injection of additional SSE fields within the same event frame if untrusted input was passed into these fields. This issue has been patched in version 4.12.4.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.11.7, a Cross-Site Scripting (XSS) vulnerability exists in the `ErrorBoundary` component of the hono/jsx library. Under certain usage patterns, untrusted user-controlled strings may be rendered as raw HTML, allowing arbitrary script execution in the victim's browser. Version 4.11.7 patches the issue.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.11.7, Serve static Middleware for the Cloudflare Workers adapter contains an information disclosure vulnerability that may allow attackers to read arbitrary keys from the Workers environment. Improper validation of user-controlled paths can result in unintended access to internal asset keys. Version 4.11.7 contains a patch for the issue.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.11.7, Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as `Cache-Control: private` or `Cache-Control: no-store`, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users. Version 4.11.7 has a patch for the issue.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.11.7, IP Restriction Middleware in Hono is vulnerable to an IP address validation bypass. The `IPV4_REGEX` pattern and `convertIPv4ToBinary` function in `src/utils/ipaddr.ts` do not properly validate that IPv4 octet values are within the valid range of 0-255, allowing attackers to craft malformed IP addresses that bypass IP-based access controls. Version 4.11.7 contains a patch for the issue.