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

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
hono (source)	4.7.5 → 4.11.10

---

Hono has Body Limit Middleware Bypass

CVE-2025-59139 / GHSA-92vj-g62v-jqhh

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-92vj-g62v-jqhh
• https://nvd.nist.gov/vuln/detail/CVE-2025-59139
• https://github.com/honojs/hono/commit/605c70560b52f13af10379f79b76717042fafe8d
• https://github.com/advisories/GHSA-92vj-g62v-jqhh

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono Improper Authorization vulnerability

CVE-2025-62610 / GHSA-m732-5p4w-x69g

More information

Details

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:

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-m732-5p4w-x69g
• https://github.com/honojs/hono/commit/45ba3bf9e3dff8e4bd85d6b47d4b71c8d6c66bef
• https://nvd.nist.gov/vuln/detail/CVE-2025-62610
• https://github.com/advisories/GHSA-m732-5p4w-x69g

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono vulnerable to Vary Header Injection leading to potential CORS Bypass

GHSA-q7jf-gf43-6x6p

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-q7jf-gf43-6x6p
• https://github.com/honojs/hono/commit/d9b8b4b73b4f997994f2764013207365fe711282
• https://github.com/advisories/GHSA-q7jf-gf43-6x6p

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono JWK Auth Middleware has JWT algorithm confusion when JWK lacks "alg" (untrusted header.alg fallback)

CVE-2026-22818 / GHSA-3vhc-576x-3qv4

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-3vhc-576x-3qv4
• https://nvd.nist.gov/vuln/detail/CVE-2026-22818
• https://github.com/honojs/hono/commit/190f6e28e2ca85ce3d1f2f54db1310f5f3eab134
• https://github.com/advisories/GHSA-3vhc-576x-3qv4

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono JWT Middleware's JWT Algorithm Confusion via Unsafe Default (HS256) Allows Token Forgery and Auth Bypass

CVE-2026-22817 / GHSA-f67f-6cw9-8mq4

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-f67f-6cw9-8mq4
• https://nvd.nist.gov/vuln/detail/CVE-2026-22817
• https://github.com/honojs/hono/commit/cc0aa7ae327ed84cc391d29086dec2a3e44e7a1f
• https://github.com/advisories/GHSA-f67f-6cw9-8mq4

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono IPv4 address validation bypass in IP Restriction Middleware allows IP spoofing

CVE-2026-24398 / GHSA-r354-f388-2fhh

More information

Details

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

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-r354-f388-2fhh
• https://github.com/honojs/hono/commit/edbf6eea8e6c26a3937518d4ed91d8666edeec37
• https://github.com/honojs/hono/releases/tag/v4.11.7
• https://nvd.nist.gov/vuln/detail/CVE-2026-24398
• https://github.com/advisories/GHSA-r354-f388-2fhh

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono cache middleware ignores "Cache-Control: private" leading to Web Cache Deception

CVE-2026-24472 / GHSA-6wqw-2p9w-4vw4

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-6wqw-2p9w-4vw4
• https://github.com/honojs/hono/commit/12c511745b3f1e7a3f863a23ce5f921c7fa805d1
• https://github.com/honojs/hono/releases/tag/v4.11.7
• https://nvd.nist.gov/vuln/detail/CVE-2026-24472
• https://github.com/advisories/GHSA-6wqw-2p9w-4vw4

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono has an Arbitrary Key Read in Serve static Middleware (Cloudflare Workers Adapter)

CVE-2026-24473 / GHSA-w332-q679-j88p

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-w332-q679-j88p
• https://github.com/honojs/hono/commit/cf9a78db4d0a19b117aee399cbe9d3a6d9bfd817
• https://github.com/honojs/hono/releases/tag/v4.11.7
• https://nvd.nist.gov/vuln/detail/CVE-2026-24473
• https://github.com/advisories/GHSA-w332-q679-j88p

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono vulnerable to XSS through ErrorBoundary component

CVE-2026-24771 / GHSA-9r54-q6cx-xmh5

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-9r54-q6cx-xmh5
• https://nvd.nist.gov/vuln/detail/CVE-2026-24771
• https://github.com/honojs/hono/commit/2cf60046d730df9fd0aba85178f3ecfe8212d990
• https://github.com/advisories/GHSA-9r54-q6cx-xmh5

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Hono added timing comparison hardening in basicAuth and bearerAuth

GHSA-gq3j-xvxp-8hrf

More information

Details

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

References

• https://github.com/honojs/hono/security/advisories/GHSA-gq3j-xvxp-8hrf
• https://github.com/honojs/hono/commit/91def7cab654bad5eecc9270e6620d577971ff5e
• https://github.com/honojs/hono/releases/tag/v4.11.10
• https://github.com/advisories/GHSA-gq3j-xvxp-8hrf

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

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

v4.11.9

Compare Source

v4.11.8

Compare Source

What's Changed

• fix(jsx): preserve context when using await before html helper by @​kaigritun in #​4662
• fix(bearer-auth): make auth-scheme case-insensitive by @​bytaesu in #​4659

New Contributors

• @​kaigritun made their first contribution in #​4662

Full Changelog: honojs/hono@v4.11.7...v4.11.8

v4.11.7

Compare Source

Security Release

This release includes security fixes for multiple vulnerabilities in Hono and related middleware. We recommend upgrading if you are using any of the affected components.

Components

IP Restriction Middleware

Fixed an IPv4 address validation bypass that could allow IP-based access control to be bypassed under certain configurations.

Cache Middleware

Fixed an issue where responses marked with Cache-Control: private or no-store could be cached, potentially leading to information disclosure on some runtimes.

Serve Static Middleware (Cloudflare Workers adapter)

Fixed an issue that could allow unintended access to internal asset keys when serving static files with user-controlled paths.

hono/jsx ErrorBoundary

Fixed a reflected Cross-Site Scripting (XSS) issue in the ErrorBoundary component that could occur when untrusted strings were rendered without proper escaping.

Recommendation

Users are encouraged to upgrade to this release, especially if they:

• Use IP Restriction Middleware
• Use Cache Middleware on Deno, Bun, or Node.js
• Use Serve Static Middleware with user-controlled paths on Cloudflare Workers
• Render untrusted data inside ErrorBoundary components

Security Advisories & CVEs

• IP Restriction Middleware – IPv4 address validation bypass

  • Advisory: GHSA-r354-f388-2fhh
  • CVE: CVE-2026-24398

• Cache Middleware ignores Cache-Control: private

  • Advisory: GHSA-6wqw-2p9w-4vw4
  • CVE: CVE-2026-24472

• Serve Static Middleware (Cloudflare Workers adapter) – Arbitrary key read

  • Advisory: GHSA-w332-q679-j88p
  • CVE: CVE-2026-24473

• hono/jsx ErrorBoundary – Cross-Site Scripting (XSS)

  • Advisory: GHSA-9r54-q6cx-xmh5
  • CVE: Pending

---

Full Changelog: honojs/hono@v4.11.6...v4.11.7

v4.11.6

Compare Source

What's Changed

• refactor: use unique symbol for more accurate typing. by @​usualoma in #​4651
• docs: align CODE_OF_CONDUCT.md wording with Contributor Covenant by @​sano-suguru in #​4630
• fix(sse): handle \r and \r\n line endings in writeSSE by @​AprilNEA in #​4644
• feat(bun): export getBunServer by @​artemtam in #​4626

New Contributors

• @​sano-suguru made their first contribution in #​4630
• @​AprilNEA made their first contribution in #​4644
• @​artemtam made their first contribution in #​4626

Full Changelog: honojs/hono@v4.11.5...v4.11.6

v4.11.5

Compare Source

What's Changed

• fix(client): exclude $all from ClientRequest type by @​paveg in #​4611
• refactor(jwks): mark allowedAlgorithms, so the user can pass a `const… by @​nikeee in #​4641
• feat(jwt): export AlgorithmTypes by @​yusukebe in #​4642

New Contributors

• @​paveg made their first contribution in #​4611
• @​nikeee made their first contribution in #​4641

Full Changelog: honojs/hono@v4.11.4...v4.11.5

v4.11.4

Compare Source

Security

Fixed a JWT algorithm confusion issue in the JWT and JWK/JWKS middleware.

Both middlewares now require an explicit algorithm configuration to prevent the verification algorithm from being influenced by untrusted JWT header values.

If you are using the JWT or JWK/JWKS middleware, please update to the latest version as soon as possible.

JWT middleware

import { jwt } from 'hono/jwt'

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

JWK/JWKS middleware

import { jwk } from 'hono/jwk'

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

For more details, see the Security Advisory.

• GHSA-f67f-6cw9-8mq4
• GHSA-3vhc-576x-3qv4

What's Changed

• test(utils/jwt): add missing algorithm types in jwa.test.ts by @​flathill404 in #​4607
• chore: bump @hono/eslint-config and enable curly rule by @​yusukebe in #​4620
• docs(bun/websocket): Fixed a typo in hono/bun deprecation message and updated test. by @​Itsnotaka in #​4618
• test: support alg option for JWT middleware by @​yusukebe in #​4624

New Contributors

• @​flathill404 made their first contribution in #​4607
• @​Itsnotaka made their first contribution in #​4618

Full Changelog: honojs/hono@v4.11.3...v4.11.4

v4.11.3

Compare Source

What's Changed

• fix(types): fix middleware union type merging in MergeMiddlewareResponse by @​yusukebe in #​4602

Full Changelog: honojs/hono@v4.11.2...v4.11.3

v4.11.2

Compare Source

What's Changed

• docs: improve grammar in contributing documentation by @​Ishiezz in #​4581
• fix(validator): preserve literal union types in input type inference by @​yusukebe in #​4583
• chore: bump typescript-go preview for accurate benchmarking by @​sushichan044 in #​4586
• refactor(hono-base): add type annotations by @​yusukebe in #​4591
• refactor(client): refactor HonoURL types by @​yusukebe in #​4592
• perf(types): reduce Simplify in ToSchema by @​yusukebe in #​4597
• perf(types): optimize MergeMiddlewareResponse type by @​yusukebe in #​4598

New Contributors

• @​Ishiezz made their first contribution in #​4581

Full Changelog: honojs/hono@v4.11.1...v4.11.2

v4.11.1

Compare Source

What's Changed

• fix(types): fix app.on method array type inference by @​kosei28 in #​4578

Full Changelog: honojs/hono@v4.11.0...v4.11.1

v4.11.0

Compare Source

Release Notes

Hono v4.11.0 is now available!

This release includes new features for the Hono client, middleware improvements, and an important type system fix.

Type System Fix for Middleware

We've fixed a bug in the type system for middleware. Previously, app did not have the correct type with pathless handlers:

const app = new Hono()
  .use(async (c, next) => {
    await next()
  })
  .get('/a', async (c, next) => {
    await next()
  })
  .get((c) => {
    return c.text('Hello')
  })

// app's type was incorrect

This has now been fixed.

Thanks @​kosei28!

Typed URL for Hono Client

You can now pass the base URL as the second type parameter to hc to get more precise URL types:

const client = hc<typeof app, 'http://localhost:8787'>(
  'http://localhost:8787/'
)

const url = client.api.posts.$url()
// url is TypedURL with precise type information
// including protocol, host, and path

This is useful when you want to use the URL as a type-safe key for libraries like SWR.

Thanks @​miyaji255!

Custom NotFoundResponse Type

You can now customize the NotFoundResponse type using module augmentation. This allows c.notFound() to return a typed response:

import { Hono, TypedResponse } from 'hono'

declare module 'hono' {
  interface NotFoundResponse
    extends Response,
      TypedResponse<{ error: string }, 404, 'json'> {}
}

const app = new Hono()
  .get('/posts/:id', async (c) => {
    const post = await getPost(c.req.param('id'))
    if (!post) {
      return c.notFound()
    }
    return c.json({ post }, 200)
  })
  .notFound((c) => c.json({ error: 'not found' }, 404))

Now the client can correctly infer the 404 response type.

Thanks @​miyaji255!

tryGetContext Helper

The new tryGetContext() helper in the Context Storage middleware returns undefined instead of throwing an error when the context is not available:

import { tryGetContext } from 'hono/context-storage'

const context = tryGetContext<Env>()
if (context) {
  // Context is available
  console.log(context.var.message)
}

Thanks @​AyushCoder9!

Custom Query Serializer

You can now customize how query parameters are serialized using the buildSearchParams option:

const client = hc<AppType>('http://localhost', {
  buildSearchParams: (query) => {
    const searchParams = new URLSearchParams()
    for (const [k, v] of Object.entries(query)) {
      if (v === undefined) continue
      if (Array.isArray(v)) {
        v.forEach((item) => searchParams.append(`${k}[]`, item))
      } else {
        searchParams.set(k, v)
      }
    }
    return searchParams
  },
})

Thanks @​bolasblack!

New features

• feat(types): make Hono client's $url return the exact URL type #​4502
• feat(types): enhance NotFoundHandler to support custom NotFoundResponse type #​4518
• feat(timing): add wrapTime to simplify usage #​4519
• feat(pretty-json): support force option #​4531
• feat(client): add buildSearchParams option to customize query serialization #​4535
• feat(context-storage): add optional tryGetContext helper #​4539
• feat(secure-headers): add CSP report-to and report-uri directive support #​4555
• fix(types): replace schema-based path tracking with CurrentPath parameter #​4552

All changes

• chore: update esbuild to version 0.27.1 by @​kosei28 in #​4571
• fix(hono/jsx): display blank when children is nullish by @​techfish-11 in #​4573
• feat(types): make Hono client's $url return the exact URL type by @​miyaji255 in #​4502
• feat(types): enhance NotFoundHandler to support custom NotFoundResponse type by @​miyaji255 in #​4518
• feat(timing): add wrapTime to simplify usage by @​PassiDel in #​4519
• feat(pretty-json): support force option by @​missinglink in #​4531
• feat(context-storage): Add optional tryGetContext helper to context-storage middleware by @​AyushCoder9 in #​4539
• feat(client): add buildSearchParams option to customize query serialization by @​bolasblack in #​4535
• feat(secure-headers): Add CSP report-to and report-uri directive support by @​cruzz77 in #​4555
• fix(types): replace schema-based path tracking with CurrentPath parameter by @​kosei28 in #​4552
• Next by @​yusukebe in #​4574

New Contributors

• @​missinglink made their first contribution in #​4531
• @​bolasblack made their first contribution in #​4535
• @​cruzz77 made their first contribution in #​4555

Full Changelog: honojs/hono@v4.10.8...v4.11.0

v4.10.8

Compare Source

What's Changed

• chore: bump linter and formatter by @​ryuapp in #​4568
• chore: bump github actions by @​ryuapp in #​4569
• fix(linear-router): incorrect path matching by @​cromery in #​4567
• docs(cookie): update outdated RFC links by @​AyushCoder9 in #​4557
• feat(csrf): Support async IsAllowedOriginHandler by @​baseballyama in #​4558
• feat(csrf): Support async IsAllowedSecFetchSiteHandler by @​baseballyama in #​4559

New Contributors

• @​cromery made their first contribution in #​4567
• @​AyushCoder9 made their first contribution in #​4557
• @​baseballyama made their first contribution in #​4558

Full Changelog: honojs/hono@v4.10.7...v4.10.8

v4.10.7

Compare Source

What's Changed

• fix(validator): fix incomplete types and wrong tests by @​EdamAme-x in #​4521
• refactor(types): delete type NotSpecified and StrictVerifyOptions by @​ysknsid25 in #​4525
• fix: add JSX type for hono/jsx/dom by @​ssssota in #​4534
• fix(adapter/bun): fix TypeError: null is not an object (#​4429) by @​brenc in #​4538
• chore: add config version to bun.lock by @​yusukebe in #​4548

New Contributors

• @​ysknsid25 made their first contribution in #​4525
• @​brenc made their first contribution in #​4538

Full Changelog: honojs/hono@v4.10.6...v4.10.7

v4.10.6

Compare Source

Deperecated

bearer-auth options

The following options are deprecated and will be removed in a future version:

• noAuthenticationHeaderMessage => use noAuthenticationHeader.message
• invalidAuthenticationHeaderMessage => use invalidAuthenticationHeader.message
• invalidTokenMessage => use invalidToken.message

What's Changed

• feat(aws-lambda): handle AWS Lattice events by @​anho in #​4451
• feat(secure-headers): support CSP TrustedTypePolicy by @​RosApr in #​4500
• feat: Improve auth middlewares by @​MathurAditya724 in #​4485

New Contributors

• @​anho made their first contribution in #​4451

Full Changelog: honojs/hono@v4.10.5...v4.10.6

v4.10.5

Compare Source

What's Changed

• docs(CONTRIBUTING): use bun instead of yarn in local development setup by @​taichi-1 in #​4503
• docs: grammar issue by @​WuMingDao in #​4508
• fix(utils/url): make _getQueryParam search behind question mark by @​tuzi3040 in #​4507
• fix(jsx): self-close wrapped empty tags by @​jakelee8 in #​4511
• chore: improve private field removal by @​BlankParticle in #​4513
• fix(middleware/cache): skip caching when Vary: * is present by @​pHo9UBenaA in #​4504

New Contributors

• @​taichi-1 made their first contribution in #​4503
• @​WuMingDao made their first contribution in #​4508
• @​tuzi3040 made their first contribution in #​4507
• @​jakelee8 made their first contribution in #​4511
• @​pHo9UBenaA made their first contribution in #​4504

Full Changelog: honojs/hono@v4.10.4...v4.10.5

v4.10.4

Compare Source

What's Changed

• chore: add a monochrome logo image by @​yusukebe in #​4487
• chore: fix the monochrome logo by @​yusukebe in #​4488
• fix(secure-headers): proposed features typo spelling mistake by @​RosApr in #​4494
• fix(types): preserve handler response typing in createHandlers by @​s-junio in #​4492

New Contributors

• @​RosApr made their first contribution in #​4494
• @​s-junio made their first contribution in #​4492

Full Changelog: honojs/hono@v4.10.3...v4.10.4

v4.10.3

Compare Source

Securiy Fix

A security issue in the CORS middleware has been fixed. In some cases, a request header could affect the Vary response header. Please update to the latest version if you are using the CORS middleware.

What's Changed

• fix(aws-lambda): serve microsoft office files as binary in lambda handler by [@​matthiasfeist](https://redirect.github.com/mat

✂ Note

PR body was truncated to here.