| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 before 4.12.14 contains an html injection vulnerability in jsx server-side rendering that allows attackers to inject unintended html by using malformed attribute names. Attackers can craft specially crafted attribute keys containing characters like quotes or angle brackets to break html tag boundaries and inject arbitrary attributes or elements. |
| Hono before 4.12.12 does not validate cookie names on the write path in the setCookie(), serialize(), and serializeSigned() functions, allowing invalid characters such as control characters (e.g. \r or \n) when an application passes a user-controlled cookie name. This can produce malformed Set-Cookie header values. In modern runtimes such as Node.js and Cloudflare Workers, such invalid header values are rejected and cause a runtime error before the response is sent, so header injection or response splitting could not be reproduced; the issue primarily affects correctness and robustness, resulting in runtime errors (availability) rather than confirmed header injection. |
| Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.21, the ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped. 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 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.21, app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path. 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.18, Cache Middleware does not skip caching for responses that declare per-user variance via Vary: Authorization or Vary: Cookie. As a result, a response cached for one authenticated user may be served to subsequent requests from different users. This vulnerability is fixed in 4.12.18. |
| Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, the JSX renderer escapes style attribute object values for HTML but not for CSS. Untrusted input in a style object value or property name can therefore inject additional CSS declarations into the rendered style attribute. The impact is limited to CSS and does not allow JavaScript execution or HTML attribute breakout. This vulnerability is fixed in 4.12.18. |
| Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control. This vulnerability is fixed in 4.12.18. |
| 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 is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.16, bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413. This vulnerability is fixed in 4.12.16. |
| @hono/node-server allows running the Hono application on Node.js. Prior to version 1.19.10, when using @hono/node-server's static file serving together with route-based middleware protections (e.g. protecting /admin/*), inconsistent URL decoding can allow protected static resources to be accessed without authorization. In particular, paths containing encoded slashes (%2F) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served. This issue has been patched in version 1.19.10. |
| Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.12.4, when using serveStatic together with route-based middleware protections (e.g. app.use('/admin/*', ...)), inconsistent URL decoding allowed protected static resources to be accessed without authorization. The router used decodeURI, while serveStatic used decodeURIComponent. This mismatch allowed paths containing encoded slashes (%2F) to bypass middleware protections while still resolving to the intended filesystem path. 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.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.12.4, the setCookie() utility did not validate semicolons (;), carriage returns (\r), or newline characters (\n) in the domain and path options when constructing the Set-Cookie header. Because cookie attributes are delimited by semicolons, this could allow injection of additional cookie attributes 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. In versions 4.12.0 and 4.12.1, when using the AWS Lambda adapter (`hono/aws-lambda`) behind an Application Load Balancer (ALB), the `getConnInfo()` function incorrectly selected the first value from the `X-Forwarded-For` header. Because AWS ALB appends the real client IP address to the end of the `X-Forwarded-For` header, the first value can be attacker-controlled. This could allow IP-based access control mechanisms (such as the `ipRestriction` middleware) to be bypassed. Version 4.12.2 patches the issue. |
| Hono is a Web application framework that provides support for any JavaScript runtime. In versions from 1.1.0 to before 4.10.2, Hono’s JWT Auth Middleware does not provide a built-in aud (Audience) verification option, which can cause confused-deputy / token-mix-up issues: an API may accept a valid token that was issued for a different audience (e.g., another service) when multiple services share the same issuer/keys. This can lead to unintended cross-service access. Hono’s docs list verification options for iss/nbf/iat/exp only, with no aud support; RFC 7519 requires that when an aud claim is present, tokens MUST be rejected unless the processing party identifies itself in that claim. This issue has been patched in version 4.10.2. |
| 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. |
| 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. |
