chore(deps): update dependency hono to v4.11.7 [security] #182
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.10.4→4.11.7GitHub Vulnerability Alerts
CVE-2026-22817
Summary
A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the JWT header’s
algvalue 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
algfield if present, but otherwise fell back to thealgvalue provided in the unverified JWT header.Because the
algfield 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 authorizationbypass 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
algoption 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)
After (patched configuration)
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
algfield if present. If the JWK did not specify an algorithm, the middleware fell back to using thealgvalue provided in the unverified JWT header.Because the
algfield 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
algoption is now required when using the JWK/JWKS middleware, and symmetric (HS*) algorithms are no longer accepted in this context.Before (vulnerable configuration)
After (patched configuration)
CVE-2026-24398
Summary
IP Restriction Middleware in Hono is vulnerable to an IP address validation bypass. The
IPV4_REGEXpattern andconvertIPv4ToBinaryfunction insrc/utils/ipaddr.tsdo 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:
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).convertIPv4ToBinaryfunction 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.355is accepted and converts to the same binary value as 1.2.3.99:355=256 + 99=0x163(1 << 24) + (2 << 16) + (2 << 8) + 355=0x01020363=1.2.3.99Impact
An attacker can bypass IP-based restrictions by crafting malformed IP addresses:
1.2.3.0/24is blocked, an attacker can use1.2.2.355(or similar) to bypass the restriction.This is exploitable when the application relies on client-provided IP addresses (e.g.,
X-Forwarded-For header) for access control decisions.Affected Components
src/utils/ipaddr.ts:IPV4_REGEX,convertIPv4ToBinary,distinctRemoteAddrCVE-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: privateorCache-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
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
Release Notes
honojs/hono (hono)
v4.11.7Compare 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.
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: privateorno-storecould 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
ErrorBoundaryFixed a reflected Cross-Site Scripting (XSS) issue in the
ErrorBoundarycomponent that could occur when untrusted strings were rendered without proper escaping.Recommendation
Users are encouraged to upgrade to this release, especially if they:
ErrorBoundarycomponentsSecurity Advisories & CVEs
IP Restriction Middleware – IPv4 address validation bypass
Cache Middleware ignores
Cache-Control: privateServe Static Middleware (Cloudflare Workers adapter) – Arbitrary key read
hono/jsx
ErrorBoundary– Cross-Site Scripting (XSS)Full Changelog: honojs/hono@v4.11.6...v4.11.7
v4.11.6Compare Source
v4.11.5Compare Source
What's Changed
AlgorithmTypesby @yusukebe in #4642New Contributors
Full Changelog: honojs/hono@v4.11.4...v4.11.5
v4.11.4Compare 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
JWK/JWKS middleware
For more details, see the Security Advisory.
What's Changed
@hono/eslint-configand enable curly rule by @yusukebe in #4620algoption for JWT middleware by @yusukebe in #4624New Contributors
Full Changelog: honojs/hono@v4.11.3...v4.11.4
v4.11.3Compare Source
What's Changed
Full Changelog: honojs/hono@v4.11.2...v4.11.3
v4.11.2Compare Source
What's Changed
HonoURLtypes by @yusukebe in #4592SimplifyinToSchemaby @yusukebe in #4597MergeMiddlewareResponsetype by @yusukebe in #4598New Contributors
Full Changelog: honojs/hono@v4.11.1...v4.11.2
v4.11.1Compare Source
What's Changed
Full Changelog: honojs/hono@v4.11.0...v4.11.1
v4.11.0Compare 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,
appdid not have the correct type with pathless handlers: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
hcto get more precise URL types: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
NotFoundResponsetype using module augmentation. This allowsc.notFound()to return a typed response:Now the client can correctly infer the 404 response type.
Thanks @miyaji255!
tryGetContext Helper
The new
tryGetContext()helper in the Context Storage middleware returnsundefinedinstead of throwing an error when the context is not available:Thanks @AyushCoder9!
Custom Query Serializer
You can now customize how query parameters are serialized using the
buildSearchParamsoption:Thanks @bolasblack!
New features
All changes
New Contributors
Full Changelog: honojs/hono@v4.10.8...v4.11.0
v4.10.8Compare Source
What's Changed
IsAllowedOriginHandlerby @baseballyama in #4558IsAllowedSecFetchSiteHandlerby @baseballyama in #4559New Contributors
Full Changelog: honojs/hono@v4.10.7...v4.10.8
v4.10.7Compare Source
What's Changed
NotSpecifiedandStrictVerifyOptionsby @ysknsid25 in #4525bun.lockby @yusukebe in #4548New Contributors
Full Changelog: honojs/hono@v4.10.6...v4.10.7
v4.10.6Compare Source
Deperecated
bearer-auth options
The following options are deprecated and will be removed in a future version:
noAuthenticationHeaderMessage=> usenoAuthenticationHeader.messageinvalidAuthenticationHeaderMessage=> useinvalidAuthenticationHeader.messageinvalidTokenMessage=> useinvalidToken.messageWhat's Changed
New Contributors
Full Changelog: honojs/hono@v4.10.5...v4.10.6
v4.10.5Compare Source
What's Changed
Vary: *is present by @pHo9UBenaA in #4504New Contributors
Full Changelog: honojs/hono@v4.10.4...v4.10.5
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.
This PR was generated by Mend Renovate. View the repository job log.