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

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
hono (source)	4.11.9 → 4.11.10

GitHub Vulnerability Alerts

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:

1. 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).
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 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

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

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)

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

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.

---

Release Notes

honojs/hono (hono)

v4.11.10

Compare Source

What's Changed

• fix: fixed to be more properly timing safe (Merge commit from fork 91def7c)

Full Changelog: honojs/hono@v4.11.9...v4.11.10

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, 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.