Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
52 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details When rendering JSX elements to HTML strings, attribute values are escaped and attribute names are validated. However, element tag names were previously inserted into the output without validation. If a tag name contains characters such as <, , quotes, or whitespace, it may alter the structure of the generated HTML. For example, malformed tag names can: Break out of the intended element and introduce unintended HTML elements Inject attributes or event handlers into the rendered output This issue arises when untrusted input (such as query parameters or database content) is used as JSX tag names via jsx() or…
Recommended action: Upgrade to 4.12.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper handling of JSX attribute names in hono/jsx allows malformed attribute keys to corrupt the generated HTML output. When untrusted input is used as attribute keys during server-side rendering, specially crafted keys can break out of attribute or tag boundaries and inject unintended HTML. Details When rendering JSX elements to HTML strings, attribute values are escaped, but attribute names (keys) were previously inserted into the output without validation. If an attribute name contains characters such as ", , or whitespace, it can alter the structure of the generated HTML. For example, malformed attribute names can: Break out of the current attribute and introduce unintended additional attributes Break out of the current HTML tag and inject new elements into the output This issue arises when untrusted input (such as query parameters or form data) is used as JSX attribute keys during server-side rendering. Impact An attacker who can control attribute keys used in JSX…
Recommended action: Upgrade to 4.12.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A discrepancy between browser cookie parsing and parse() handling allows cookie prefix protections to be bypassed. Cookie names that are treated as distinct by the browser may be normalized to the same key by parse(), allowing attacker-controlled cookies to override legitimate ones. Details Browsers follow RFC 6265bis and only trim SP (0x20) and HTAB (0x09) from cookie names. Other characters, such as the non-breaking space (U+00A0), are preserved as part of the cookie name. For example, the browser treats the following cookies as distinct: However, parse() previously used JavaScript's trim(), which removes a broader set of characters including U+00A0. As a result, both names are normalized to: This mismatch allows attacker-controlled cookies with a U+00A0 prefix to shadow or override legitimate cookies when accessed via getCookie(). Impact An attacker who can set cookies (e.g., via a man-in-the-middle on a non-secure page or other injection vector) can bypass cookie prefix…
Recommended action: Upgrade to 4.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ipRestriction() does not canonicalize IPv4-mapped IPv6 client addresses (e.g. ::ffff:127.0.0.1) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior. Details The middleware classifies client addresses based on their textual form. Addresses containing ":" are treated as IPv6, including IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1. These addresses are not normalized to IPv4 before matching. As a result: IPv4 static rules (e.g. 127.0.0.1) do not match because the raw string differs IPv4 CIDR rules (e.g. 127.0.0.0/8, 10.0.0.0/8) are skipped because the address is treated as IPv6 For example, with: denyList: ['127.0.0.1'] a request from 127.0.0.1 may be represented as ::ffff:127.0.0.1 and bypass the deny rule. This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses. Impact Applications that rely…
Recommended action: Upgrade to 4.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cookie names are not validated on the write path when using setCookie(), serialize(), or serializeSigned() to generate Set-Cookie headers. While certain cookie attributes such as domain and path are validated, the cookie name itself may contain invalid characters. This results in inconsistent handling of cookie names between parsing (read path) and serialization (write path). Details When applications use setCookie(), serialize(), or serializeSigned() with a user-controlled cookie name, invalid values (e.g., containing control characters such as \r or \n) can be used to construct malformed Set-Cookie header values. For example: However, in modern runtimes such as Node.js and Cloudflare Workers, such invalid header values are rejected and result in a runtime error before the response is sent. As a result, the reported header injection / response splitting behavior could not be reproduced in these environments. Impact Applications that pass untrusted input as the cookie name to…
Recommended action: Upgrade to 4.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal issue in toSSG() allows files to be written outside the configured output directory during static site generation. When using dynamic route parameters via ssgParams, specially crafted values can cause generated file paths to escape the intended output directory. Details The static site generation process creates output files based on route paths derived from application routes and parameters. When ssgParams is used to provide values for dynamic routes, those values are used to construct output file paths. If these values contain traversal sequences (e.g. ..), the resulting output path may resolve outside the configured output directory. As a result, files may be written to unintended locations instead of being confined within the specified output directory. For example: In this case, the generated output path may resolve outside ./static, resulting in a file being written outside the intended output directory. Impact An attacker who can influence values…
Recommended action: Upgrade to 4.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The routing layer and serveStatic handle repeated slashes differently. For example: However, serveStatic may interpret both paths as the same file location (e.g., admin/secret.txt) and return the file. This inconsistency allows a request such as: to bypass middleware registered on /admin/ and access protected files. The issue has been fixed by rejecting paths that contain repeated slashes, ensuring consistent behavior between route matching and static file resolution. Impact An attacker can access static files that are intended to be protected by route-based middleware by using repeated slashes in the request…
Recommended action: Upgrade to 4.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using parseBody({ dot: true }) in HonoRequest, specially crafted form field names such as proto.x could create objects containing a proto property. If the parsed result is later merged into regular JavaScript objects using unsafe merge patterns, this may lead to prototype pollution in the target object. Details The parseBody({ dot: true }) feature supports dot notation to construct nested objects from form field names. In previous versions, the proto path segment was not filtered. As a result, specially crafted keys such as proto.x could produce objects containing proto properties. While this behavior does not directly modify Object.prototype within Hono itself, it may become exploitable if the parsed result is later merged into regular JavaScript objects using unsafe merge patterns. Impact Applications that merge parsed form data into regular objects using unsafe patterns (for example recursive deep merge utilities) may become vulnerable to prototype pollution.
Recommended action: Upgrade to 4.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details setCookie() builds the Set-Cookie header by concatenating option values. While the cookie value itself is URL-encoded, the domain and path options were previously interpolated without rejecting unsafe characters. Including ;, \r, or \n in these fields could result in unintended additional attributes (such as SameSite, Secure, Domain, or Path) being appended to the cookie header. Modern runtimes prevent full header injection via CRLF, so this issue is limited to attribute-level manipulation within a single Set-Cookie header. The issue has been fixed by rejecting these characters in the domain and path options. Impact An attacker may…
Recommended action: Upgrade to 4.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The SSE helper builds event frames by joining lines with \n. While multi-line data: fields are handled according to the SSE specification, the event, id, and retry fields previously allowed raw values without rejecting embedded CR/LF characters. Including CR/LF in these control fields could allow unintended additional fields (such as data:, id:, or retry:) to be injected into the event stream. The issue has been fixed by rejecting CR/LF characters in these fields. Impact An attacker could manipulate the structure of SSE event frames if an application passed user-controlled input directly into event, id, or retry. Depending on…
Recommended action: Upgrade to 4.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The routing layer preserved %2F as a literal string, while serveStatic decoded it into / before resolving the file path. Example: Request: /admin%2Fsecret.html - Router sees: /admin%2Fsecret.html → does not match /admin/ - Static handler resolves: /admin/secret.html As a result, static files under the configured static root could be served without triggering route-based protections. This only affects applications that both: - Protect subpaths using route-based middleware, and - Serve files from the same static root using serveStatic. This does not allow…
Recommended action: Upgrade to 4.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details In ALB environments, AWS appends the actual client IP address to the end of any existing X-Forwarded-For header value. However, the previous implementation of getConnInfo() extracted the leftmost IP address: If a client sent: ALB would forward: Since the implementation selected the first value, the spoofed IP address was trusted. This affected applications using: or any custom middleware relying on getConnInfo(c).remote.address for authorization decisions. The issue only affects deployments using the AWS Lambda adapter behind an ALB. API…
Recommended action: Upgrade to 4.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The basicAuth and bearerAuth middlewares previously used a comparison that was not fully timing-safe. The timingSafeEqual function used normal string equality (===) when comparing hash values. This comparison may stop early if values differ, which can theoretically cause small timing differences. The implementation has been updated to use a safer comparison method. Details The issue was caused by the use of normal string equality (===) when comparing hash values inside the timingSafeEqual function. In JavaScript, string comparison may stop as soon as a difference is found. This means the comparison time can slightly vary depending on how many characters match. Under very specific and controlled conditions, this behavior could theoretically allow timing-based analysis. The implementation has been updated to: - Avoid early termination during comparison - Use a constant-time-style comparison method Impact This issue is unlikely to be exploited in normal environments. It may only…
Recommended action: Upgrade to 4.11.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The issue is in the ErrorBoundary component (src/jsx/components.ts). ErrorBoundary previously forced certain rendered output paths to be treated as raw HTML, bypassing the library's default escaping behavior. This could result in unescaped rendering when developers pass user-controlled strings directly as children, or when fallbackRender returns user-controlled strings (for example, reflecting error messages that contain attacker input). This vulnerability is only exploitable when an application renders untrusted user input within ErrorBoundary without appropriate escaping or sanitization. Impact Successful exploitation may allow attackers to execute arbitrary JavaScript in the victim’s browser (reflected XSS).…
Recommended action: Upgrade to 4.11.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The vulnerability exists in the serve-static middleware used with the Cloudflare Workers adapter. When serving static assets, the middleware does not sufficiently validate or restrict user-supplied paths before resolving them against the Workers asset storage. As a result, an attacker may craft requests that access arbitrary keys beyond the intended static asset scope. This issue only affects applications running on Cloudflare Workers that use Serve static Middleware with user-controllable request paths. Impact This vulnerability may lead to information disclosure by allowing unauthorized access to internal assets or data stored in the Workers environment. The exposed data is limited to…
Recommended action: Upgrade to 4.11.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware’s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses. Impact This issue can lead to Web Cache…
Recommended action: Upgrade to 4.11.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
IP Restriction Middleware in Hono is vulnerable to an IP address validation bypass. The IPV4REGEX 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. Details The vulnerability exists in two components: 1. Permissive regex pattern: The IPV4REGEX (/^[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}$/) accepts octet values greater than 255 (e.g., 999). 2. Unsafe binary conversion: The convertIPv4ToBinary function does not validate octet ranges before performing bitwise operations. When an octet exceeds 255, it overflows into adjacent octets during the bit-shift calculation. For example, the IP address 1.2.2.355 is accepted and converts to the same binary value as 1.2.3.99: 355 = 256 + 99 = 0x163 After bit-shifting: (1 << 24) + (2 << 16) + (2 << 8) + 355 = 0x01020363 = 1.2.3.99 Impact An attacker can…
Recommended action: Upgrade to 4.11.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted. Details When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present. If the JWK did not specify an algorithm, the middleware fell back to using the alg value provided in the unverified JWT header. Because the alg field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs. The practical impact depends on application configuration, including which algorithms are accepted and…
Recommended action: Upgrade to 4.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the JWT header’s alg value to influence signature verification when the selected JWK did not explicitly specify an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted. Details When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present, but otherwise fell back to the alg value provided in the unverified JWT header. Because the alg field in a JWK is optional and often omitted in real-world JWKS configurations, this behavior could allow an attacker to control the algorithm used for verification. In some environments, this may lead to authentication or authorization bypass through crafted tokens. The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used for authorization decisions. Impact In affected…
Recommended action: Upgrade to 4.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in the CORS middleware allowed request Vary headers to be reflected into the response, enabling attacker-controlled Vary values and potentially affecting cache behavior. Details The middleware previously copied the Vary header from the request when origin was not set to "". Since Vary is a response header that should only be managed by the server, this could allow an attacker to influence caching behavior or cause inconsistent CORS handling. Most environments will see impact only when shared caches or proxies rely on the Vary header. The practical effect varies by configuration. Impact May cause cache key pollution and inconsistent CORS enforcement in certain setups. No direct confidentiality, integrity, or availability impact in default configurations. Resolution Update to the latest patched release. The CORS middleware has been corrected to handle Vary exclusively as a response header.
Recommended action: Upgrade to 4.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper Authorization in Hono (JWT Audience Validation) Hono’s JWT authentication middleware did not validate the aud (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up). The issue is addressed by adding a new verification.aud configuration option to allow RFC 7519–compliant audience validation. This change is classified as a security hardening improvement, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification. Recommended secure configuration You can enable RFC 7519–compliant audience validation using the new verification.aud option: Below is the original description by the reporter. For security reasons, it does not include PoC reproduction steps, as the vulnerability can be clearly understood from the technical description. --- The original description…
Recommended action: Upgrade to 4.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in the bodyLimit middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present. Details The middleware previously prioritized the Content-Length header even when a Transfer-Encoding: chunked header was also included. According to the HTTP specification, Content-Length must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit. Most standards-compliant runtimes and reverse proxies may reject such malformed requests with 400 Bad Request, so the practical impact depends on the runtime and deployment environment. Impact If body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests. Resolution The implementation has been updated to align with the HTTP…
Recommended action: Upgrade to 4.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in the getPath utility function could allow path confusion and potential bypass of proxy-level ACLs (e.g. Nginx location blocks). Details The original implementation relied on fixed character offsets when parsing request URLs. Under certain malformed absolute-form Request-URIs, this could lead to incorrect path extraction. Most standards-compliant runtimes and reverse proxies reject such malformed requests with a 400 Bad Request, so the impact depends on the application and environment. Impact If proxy ACLs are used to protect sensitive endpoints such as /admin, this flaw could have allowed unauthorized access. The confidentiality impact depends on what data is exposed: if sensitive administrative data is exposed, the impact may be High (CVSS 7.5); otherwise it may be Medium (CVSS 5.3). Resolution The implementation has been updated to correctly locate the first slash after "://", preventing such path confusion.
Recommended action: Upgrade to 4.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Bypass CSRF Middleware by a request without Content-Type herader. Details Although the csrf middleware verifies the Content-Type Header, Hono always considers a request without a Content-Type header to be safe. https://github.com/honojs/hono/blob/cebf4e87f3984a6a034e60a43f542b4c5225b668/src/middleware/csrf/index.ts#L76-L89 PoC Similarly, the fetch API does not add a Content-Type header for requests that do not include a Body. Impact Bypass csrf protection implemented with hono csrf middleware.
Recommended action: Upgrade to 4.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Hono CSRF middleware can be bypassed using crafted Content-Type header. Details MIME types are case insensitive, but isRequestedByFormElementRe only matches lower-case. https://github.com/honojs/hono/blob/b0af71fbcc6dbe44140ea76f16d68dfdb32a99a0/src/middleware/csrf/index.ts#L16-L17 As a result, attacker can bypass csrf middleware using upper-case form-like MIME type, such as "Application/x-www-form-urlencoded". PoC Impact Bypass csrf protection implemented with hono csrf middleware. Discussion I'm not sure that omitting csrf checks for Simple POST request is a good idea. CSRF prevention and CORS are different concepts even though CORS can prevent CSRF in some cases.
Recommended action: Upgrade to 4.5.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.