You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
chore(deps): update dependency hono to v4.13.11 [security] - #1207
The languageDetector middleware is vulnerable to algorithmic complexity denial of service when processing a crafted language tag containing a large number of hyphen-separated subtags.
Details
To implement progressive language-tag truncation, normalizeLanguage() repeatedly calls parts.slice(0, i).join('-') for every possible prefix. The total amount of string processing grows quadratically with the number of subtags.
Language values may come from a query parameter, cookie, Accept-Language header, or URL path, depending on the detector configuration. The default detector order enables query-string, cookie, and header detection, so applications using languageDetector() may expose this processing to unauthenticated requests.
Request-size limits reduce the maximum cost of a single request but do not eliminate the issue. Inputs accepted by common JavaScript runtimes can still cause noticeable synchronous event-loop blocking.
Impact
An attacker may repeatedly send requests containing long, hyphen-separated language tags, causing excessive CPU consumption and preventing unrelated requests from being processed.
The practical impact depends on the runtime's request-size limits, reverse-proxy configuration, and the detectors enabled by the application.
Resolution
The progressive lookup should avoid reconstructing every shorter prefix. The implementation can instead inspect the configured supported languages and select the longest value that matches the input at a hyphen boundary.
The Proxy Helper (hono/proxy) does not remove response headers named by the origin's Connection header. Headers that the origin marked as connection-scoped are therefore forwarded to clients.
Details
Per RFC 9110 Section 7.6.1, an intermediary must remove the header fields listed in a message's Connection header field before forwarding the message, in addition to the well-known hop-by-hop headers. The proxy() function removed the well-known hop-by-hop headers (including Connection itself) from origin responses, but did not remove the headers that the response's Connection header field designated as connection-scoped.
This issue arises when an application proxies responses from an origin that declares additional, non-standard headers as hop-by-hop via the Connection response header.
Impact
A client may receive response headers that the origin intended only for its immediate peer. This may lead to:
Disclosure of connection-scoped or internal metadata contained in such headers
This issue affects applications that use the Proxy Helper (hono/proxy) to forward responses from origins that list custom header names in their Connection response header. Applications whose origins only use the standard hop-by-hop headers are not affected.
memo() from hono/jsx retains the result of a server-side render and reuses it for later renders with comparator-equal props. Request-scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request.
Details
Components wrapped with memo() are compared by props alone. Values read implicitly during rendering do not participate: JSX Context through createContext() and useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage. The retained result lives as long as the wrapped component, so it outlives the request that produced it.
Per-request context isolation is not what fails: the current request's values are established correctly, but the memoized component is skipped before anything reads them.
This issue arises when a component wrapped in memo() obtains user- or request-specific data from an ambient context instead of through props.
Impact
A user may receive a response containing HTML rendered for another user, when both render the same memoized component with comparator-equal props on the same warm instance.
This may lead to:
Disclosure of another user's account or profile data
Disclosure of request-scoped secrets embedded in HTML, such as CSRF tokens
Exposure of role-specific content to users who should not receive it
Exploitation depends on the order in which renders populate the retained value and on both requests reaching the same warm instance.
This issue affects applications that render with hono/jsx on the server and wrap a component reading ambient request state in memo(). Applications that pass all request-specific values through props, or that do not use memo(), are unaffected. Client-side rendering is unaffected.
The fix released for CVE-2026-39408 does not cover every traversal sequence. toSSG() can still write files outside the configured output directory when a route parameter contains consecutive parent-directory segments.
Details
Static site generation builds each output path from the route path and the values supplied through ssgParams, then verifies that the result stays inside the output directory. That check normalizes the path with the same routine that built it, and the routine did not fully collapse runs of consecutive parent-directory segments. A value carrying enough of them produces a path the check accepts, but the filesystem resolves outside the output directory.
The earlier fix handled a single parent-directory segment, so it blocks the sequence reported at the time while leaving longer runs unhandled. The check also treated output directories that differ only in how they are rooted as equivalent.
This arises when an application generates a static site from route parameter values it does not fully control — slugs coming from a CMS, an API, or user submissions.
Impact
A value reaching ssgParams from an untrusted source can cause build output to be written outside the intended output directory, carrying whatever content the route handler produced.
This may lead to:
files being created or overwritten elsewhere in the build environment
generated artifacts or deployment output being altered
This affects build-time static site generation only; request-time routing is not affected. Applications whose ssgParams values are entirely developer-controlled are not affected.
Hono's query parsing does not stop at the URL fragment: a ? appearing after a # is treated as the start of a query string. As a result, the application can read request parameters that no other component involved in handling the request can see.
Details
A fragment is never part of the query, and every standard URL consumer — browsers, new URL(), reverse proxies — ignores everything from the first # onward. Hono's routing followed that rule; its query helpers did not.
For one and the same request, this produces an interpretation differential:
A component in front of the application that inspects the query string — filtering rules, parameter allow/deny lists, access logging — observes no parameters, while the application reads and acts on them.
The cache middleware removed the fragment when building its cache key, so a response influenced by parameters carried inside the fragment could be stored under a key that did not reflect them and later returned to other users.
The same divergence reaches request validation and any middleware that reads query parameters.
This requires a request target containing a literal # to reach the application. Deployments on runtimes that normalise such a target — including Cloudflare Workers — are not affected, and neither are those behind an intermediary that strips the fragment.
Impact
An attacker can cause the application to act on parameters that components in front of it never observe.
This may lead to:
filtering rules, allow/deny lists, and audit logging being blind to parameters the application still processes
a cached response being stored under a key that does not reflect the parameters used to produce it, and served to other users
stored cross-site scripting, where such a parameter is reflected into a cached HTML response without escaping
This issue affects applications that read query parameters and run on a runtime that passes a literal # through to the request URL.
hono/jsx does not HTML-escape a plain string placed directly as a child or fallback of Suspense or ErrorBoundary, as the only child of a Context.Provider, or as the root value of renderToString() / renderToReadableStream() from hono/jsx/dom/server. Such a string is emitted as markup instead of text.
Details
These paths stringify their input and treat the result as already-escaped HTML, so a plain string passes through unchanged. Notable cases:
Suspense: a string child, or a string fallback while a child suspends. With streaming, the fallback reaches the browser in the initial chunk.
ErrorBoundary: a string child alongside an asynchronous sibling. The all-synchronous case was fixed in 4.11.7 (GHSA-9r54-q6cx-xmh5).
Context.Provider: a single string child. Multiple children are escaped.
hono/jsx/dom/server: a string, or an array containing strings, passed as the root.
A lone {children} forwarded by a wrapper component is enough to reach these paths. Strings wrapped in an element, values from raw() or the html helper, and client-side rendering with hono/jsx/dom are not affected.
Impact
An attacker who controls a string rendered in an affected position can inject arbitrary HTML into the server-rendered page, leading to cross-site scripting under the application's origin.
This issue affects applications that render untrusted strings directly in one of the positions above during server-side rendering.
serveStatic decodes the request path a second time after Hono has already decoded it for routing. A crafted request can be routed as one path and served as another, so middleware mounted on a static prefix does not run for a file under that prefix.
Details
Hono decodes the request path once before routing. serveStatic decoded it again before resolving the file. With a malformed percent-encoded sequence, the first decode leaves part of the path encoded, the router matches the encoded form, and the second decode resolves the real directory. The file is still resolved inside the configured root; this is not a traversal outside it.
Impact
An unauthenticated attacker may reach static files without the middleware on their prefix running, for example an authentication check. This affects applications that mount middleware on part of the directory served by serveStatic. Applications that serve only public files are not affected.
serveStatic decodes the request path a second time, leading to bypass of middleware on static paths
Affects: hono/serve-static and the adapters built on it (hono/bun, hono/deno, hono/cloudflare-workers, @hono/bun, @hono/deno, @hono/cloudflare-workers). Fixes serveStatic decoding an already-decoded path, where a crafted request could be routed as one path and served as another, skipping middleware mounted on a static prefix. GHSA-5r4p-p66f-jhc7
serveStatic now rejects request paths that still contain % after decoding. To serve files whose names contain a literal %, set allowPercentInPath: true.
The runtime adapters are now published as their own packages: @hono/bun, @hono/deno, @hono/cloudflare-workers, @hono/aws-lambda, @hono/lambda-edge, @hono/netlify, @hono/vercel, and @hono/service-worker. @hono/deno is also on JSR.
hono/<adapter> still works in v4 but is deprecated and will be removed in v5. Migrating is an import change:
- import { serveStatic } from 'hono/bun'+ import { serveStatic } from '@hono/bun'
hono/cloudflare-pages is deprecated without a replacement package; Cloudflare recommends Workers with static assets.
What's Changed
chore: migrate the package manager from bun to pnpm in #5433
chore(package.json): invoke package scripts through pnpm instead of bun in #5434
This release includes a fix for the following security issue:
hono/jsx renders plain strings unescaped in boundary components, leading to XSS
Affects: Suspense, ErrorBoundary, and Context.Provider in hono/jsx, and renderToString() / renderToReadableStream() in hono/jsx/dom/server. Fixes missing HTML escaping for a plain string placed directly as a child or fallback of these components, or as the root value of the server rendering functions, so untrusted strings could be emitted as markup. GHSA-hxh3-vqpv-xpqv
Users who render untrusted strings inside Suspense, ErrorBoundary, or Context.Provider, or pass them directly to hono/jsx/dom/server, are strongly encouraged to upgrade to this version.
This release includes fixes for the following security issues:
Query parser reads parameters after the URL fragment, causing cache-key and proxy interpretation differentials
Affects: Cache Middleware and applications behind a proxy, WAF, or logging layer that inspects query strings. Fixes query parsing that did not stop at the URL fragment, so a ? after a # was treated as the start of a query string and the application could read parameters that the other component never saw. GHSA-crvj-82cr-hjcx
Incomplete fix for CVE-2026-39408: toSSG() still writes files outside the output directory
Affects: toSSG() for Static Site Generation. Fixes a path normalization gap where consecutive parent-directory segments in ssgParams values were not fully collapsed, bypassing the containment check added in 4.12.12. GHSA-gqvv-2mrq-wpjv
Unbounded dot-notation nesting in parseBody() can cause memory exhaustion
Affects: parseBody() when dot-notation parsing is enabled. Fixes unbounded expansion of dot-separated field names, where a small request body could allocate a disproportionately large object graph and concurrent requests could exhaust the heap. GHSA-g6gw-c38x-mqfc
Users who use Cache Middleware, deploy behind a proxy or WAF that inspects query strings, use Static Site Generation, or use parseBody({ dot: true }) are strongly encouraged to upgrade to this version.
The highlight of this release is performance: a batch of low-level optimizations makes the core request/response path significantly faster — up to 1.25x on common routes in our benchmark. This release also adds first-class support for the HTTP QUERY method, defined in RFC 10008, a new Method Not Allowed middleware, and more.
Performance improvements
This release includes a series of small optimizations: skipping unnecessary Headers allocations, replacing regex tests with indexOf, allocating internal state lazily, and more.
Here is benchmarks/fetch comparing v4.12 and v4.13 (ROUNDS=5 ./compare.sh, Bun 1.4.0, Apple Silicon — each measurement runs in a fresh process, and the variant order is reversed every round to avoid warm-up bias):
Benchmark
v4.12
v4.13
Speedup
ping — GET /
165.83 ns
163.99 ns
1.01x
query — GET /id/1?name=bun
674.40 ns
616.99 ns
1.09x
json — GET /user
528.99 ns
422.44 ns
1.25x
body — POST /json
1.16 µs
1.00 µs
1.15x
The individual changes:
perf(context): iterate the header record with for..in#5118
The QUERY method — a safe, idempotent method that carries a request body — is now a first-class citizen in Hono. You can define QUERY handlers with app.query():
The built-in middleware has been updated to handle QUERY requests properly:
Cache Middleware
The Cache Middleware now caches QUERY responses. Following RFC 10008 Section 2.7, the cache key incorporates a SHA-256 digest of the request content and its representation metadata, so different query bodies are cached separately:
Note: To support this, the internal cache key format has changed for all methods, including GET. Cached entries are now stored under an internal URL of the form /.hono/cache?__hono_cache_key=.... If you purge cache entries by URL outside of the middleware (e.g. calling caches.delete() with the original request URL), you will need to update that logic. Existing cache entries stored with the old format will simply be re-fetched.
ETag Middleware
The ETag Middleware now handles conditional requests for QUERY, returning 304 Not Modified when If-None-Match matches.
CORS Middleware
The CORS Middleware now includes QUERY in the default Access-Control-Allow-Methods, which is now GET, HEAD, PUT, POST, DELETE, PATCH, QUERY. If you specify allowMethods explicitly, nothing changes for you.
The new Method Not Allowed Middleware returns a 405 Method Not Allowed response with a proper Allow header when the request path matches a registered route but the method does not:
import{methodNotAllowed}from'hono/method-not-allowed'constapp=newHono()app.use(methodNotAllowed({ app }))app.get('/hello',(c)=>c.text('Hello!'))app.post('/hello',(c)=>c.text('Posted!'))// PUT /hello -> 405 Method Not Allowed// Allow: GET, HEAD, POST
You can customize the response with the onMethodNotAllowed option:
app.use(methodNotAllowed({
app,onMethodNotAllowed: (c,methods)=>c.json({error: 'Method Not Allowed'},405,{Allow: methods.join(', ')}),}))
RegExpRouter throws UnsupportedPathError at registration time
The RegExpRouter now detects unsupported path combinations when routes are registered, instead of at the first matching request. This means misconfigured routes fail fast at startup rather than at runtime. As a bonus, registration plus the first match is roughly 20% faster.
hono/utils/headers has been synced with the IANA HTTP Field Name Registry, adding newly registered fields such as Accept-Query. Thanks @akahoshi1421!
The JWT and JWK middleware now accept a realm option for the WWW-Authenticate challenge on 401 responses, and challenge values are properly escaped. Thanks @arhxam!
JSX: useRef and RefObject are now aligned with React 19. Note that this is a type-level change — RefObject<T> is now { current: T }, so type a nullable ref as RefObject<T | null>, and pass useRef(undefined) instead of useRef(). Thanks @ashunar0!
JSX: a function component can now return an array of children without throwing during server-side rendering. Thanks @natsuki-engr!
The Compress Middleware now sets Vary: Accept-Encoding on negotiated responses. Thanks @arhxam!
All changes
perf(hono-base): avoid rest parameter in fetch by @yusukebe in #5113
perf(context): iterate the header record with for..in by @yusukebe in #5118
perf(url/request): replace regex tests with indexOf by @yusukebe in #5121
perf(context): skip Headers creation when there are no headers to merge by @yusukebe in #5122
perf(urls): refactor tryDecodeURIComponent by @yusukebe in #5158
chore(benchmarks): correct src path on Windows, add json and middleware cases by @kibertoad in #5173
perf(context): drop the throwaway env field initializer by @kibertoad in #5174
perf(request): allocate #validatedData lazily by @kibertoad in #5175
perf(request): probe the body cache without allocating by @kibertoad in #5176
chore(benchmarks): stabilize measurements by forcing mitata batching by @yusukebe in #5183
perf(hono-base): restore the rest parameter in fetch by @yusukebe in #5184
perf(context): restore the env field initializer by @yusukebe in #5186
This release includes fixes for the following security issues:
memo() retains SSR output across requests, leading to cross-user data disclosure
Affects: hono/jsx (server-side rendering). Fixes memo() reusing a retained render result across requests when props compare equal, where a component reading request-scoped values from ambient context — useContext(), useRequestContext(), or getContext() — could serve HTML rendered for another user's request, disclosing account data or request-scoped secrets such as CSRF tokens. GHSA-f23p-vx2j-j53r
ReDoS in CORS middleware via Access-Control-Request-Headers
Affects: hono/cors. Fixes a whitespace-tolerant regular expression with quadratic backtracking used to parse the Access-Control-Request-Headers preflight header when allowHeaders is not configured (the default), where a single preflight request carrying a long whitespace run could consume seconds of CPU and stall request processing. GHSA-8j4g-w8fx-2239
Algorithmic complexity DoS in Language Middleware
Affects: hono/language. Fixes quadratic string processing in language-tag normalization, where a crafted language tag with a large number of hyphen-separated subtags — supplied via a query parameter, cookie, or Accept-Language header — could cause excessive CPU consumption and block the event loop. GHSA-54fx-42gc-7vw4
Proxy Helper does not remove response headers listed in the Connection header
Affects: hono/proxy. Fixes proxy() forwarding response headers that the origin's Connection header designates as connection-scoped, where headers intended only for the immediate peer — per RFC 9110 Section 7.6.1 — could be exposed to clients, disclosing connection-scoped or internal metadata. GHSA-79qm-7rj5-m7r9
Users who use hono/jsx for server-side rendering, hono/cors, hono/language, or hono/proxy are strongly encouraged to upgrade to this version.
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer TIP This summary will be updated as you push new changes.
renovateBot
changed the title
chore(deps): update dependency hono to v4.13.5 [security]
chore(deps): update dependency hono to v4.13.7 [security]
Oct 7, 2026
renovateBot
changed the title
chore(deps): update dependency hono to v4.13.7 [security]
chore(deps): update dependency hono to v4.13.11 [security]
Oct 20, 2026
Superseded by #1217, which has been merged into staging. The dependency updates proposed here are covered by the merged refresh through matching or newer versions, or removal of the obsolete dependency/toolchain. Closing this stale dependency-update PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
4.12.27→4.13.11Hono: Algorithmic Complexity DoS in Language Middleware
CVE-2026-71848 / GHSA-54fx-42gc-7vw4
More information
Details
Summary
The
languageDetectormiddleware is vulnerable to algorithmic complexity denial of service when processing a crafted language tag containing a large number of hyphen-separated subtags.Details
To implement progressive language-tag truncation,
normalizeLanguage()repeatedly callsparts.slice(0, i).join('-')for every possible prefix. The total amount of string processing grows quadratically with the number of subtags.Language values may come from a query parameter, cookie,
Accept-Languageheader, or URL path, depending on the detector configuration. The default detector order enables query-string, cookie, and header detection, so applications usinglanguageDetector()may expose this processing to unauthenticated requests.Request-size limits reduce the maximum cost of a single request but do not eliminate the issue. Inputs accepted by common JavaScript runtimes can still cause noticeable synchronous event-loop blocking.
Impact
An attacker may repeatedly send requests containing long, hyphen-separated language tags, causing excessive CPU consumption and preventing unrelated requests from being processed.
The practical impact depends on the runtime's request-size limits, reverse-proxy configuration, and the detectors enabled by the application.
Resolution
The progressive lookup should avoid reconstructing every shorter prefix. The implementation can instead inspect the configured supported languages and select the longest value that matches the input at a hyphen boundary.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Hono: Proxy Helper does not remove response headers listed in the
ConnectionheaderCVE-2026-71849 / GHSA-79qm-7rj5-m7r9
More information
Details
Summary
The Proxy Helper (
hono/proxy) does not remove response headers named by the origin'sConnectionheader. Headers that the origin marked as connection-scoped are therefore forwarded to clients.Details
Per RFC 9110 Section 7.6.1, an intermediary must remove the header fields listed in a message's
Connectionheader field before forwarding the message, in addition to the well-known hop-by-hop headers. Theproxy()function removed the well-known hop-by-hop headers (includingConnectionitself) from origin responses, but did not remove the headers that the response'sConnectionheader field designated as connection-scoped.This issue arises when an application proxies responses from an origin that declares additional, non-standard headers as hop-by-hop via the
Connectionresponse header.Impact
A client may receive response headers that the origin intended only for its immediate peer. This may lead to:
This issue affects applications that use the Proxy Helper (
hono/proxy) to forward responses from origins that list custom header names in theirConnectionresponse header. Applications whose origins only use the standard hop-by-hop headers are not affected.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Hono:
memo()retains SSR output across requests, leading to cross-user data disclosureCVE-2026-71850 / GHSA-f23p-vx2j-j53r
More information
Details
Summary
memo()fromhono/jsxretains the result of a server-side render and reuses it for later renders with comparator-equal props. Request-scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request.Details
Components wrapped with
memo()are compared by props alone. Values read implicitly during rendering do not participate: JSX Context throughcreateContext()anduseContext(),useRequestContext()fromhono/jsx-renderer, andgetContext()fromhono/context-storage. The retained result lives as long as the wrapped component, so it outlives the request that produced it.Per-request context isolation is not what fails: the current request's values are established correctly, but the memoized component is skipped before anything reads them.
This issue arises when a component wrapped in
memo()obtains user- or request-specific data from an ambient context instead of through props.Impact
A user may receive a response containing HTML rendered for another user, when both render the same memoized component with comparator-equal props on the same warm instance.
This may lead to:
Exploitation depends on the order in which renders populate the retained value and on both requests reaching the same warm instance.
This issue affects applications that render with
hono/jsxon the server and wrap a component reading ambient request state inmemo(). Applications that pass all request-specific values through props, or that do not usememo(), are unaffected. Client-side rendering is unaffected.Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Hono: Incomplete fix for CVE-2026-39408:
toSSG()still writes files outside the output directoryCVE-2026-84365 / GHSA-gqvv-2mrq-wpjv
More information
Details
Summary
The fix released for CVE-2026-39408 does not cover every traversal sequence.
toSSG()can still write files outside the configured output directory when a route parameter contains consecutive parent-directory segments.Details
Static site generation builds each output path from the route path and the values supplied through
ssgParams, then verifies that the result stays inside the output directory. That check normalizes the path with the same routine that built it, and the routine did not fully collapse runs of consecutive parent-directory segments. A value carrying enough of them produces a path the check accepts, but the filesystem resolves outside the output directory.The earlier fix handled a single parent-directory segment, so it blocks the sequence reported at the time while leaving longer runs unhandled. The check also treated output directories that differ only in how they are rooted as equivalent.
This arises when an application generates a static site from route parameter values it does not fully control — slugs coming from a CMS, an API, or user submissions.
Impact
A value reaching
ssgParamsfrom an untrusted source can cause build output to be written outside the intended output directory, carrying whatever content the route handler produced.This may lead to:
This affects build-time static site generation only; request-time routing is not affected. Applications whose
ssgParamsvalues are entirely developer-controlled are not affected.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Hono: Query parser reads parameters after the URL fragment, causing cache-key and proxy interpretation differentials
CVE-2026-84363 / GHSA-crvj-82cr-hjcx
More information
Details
Summary
Hono's query parsing does not stop at the URL fragment: a
?appearing after a#is treated as the start of a query string. As a result, the application can read request parameters that no other component involved in handling the request can see.Details
A fragment is never part of the query, and every standard URL consumer — browsers,
new URL(), reverse proxies — ignores everything from the first#onward. Hono's routing followed that rule; its query helpers did not.For one and the same request, this produces an interpretation differential:
The same divergence reaches request validation and any middleware that reads query parameters.
This requires a request target containing a literal
#to reach the application. Deployments on runtimes that normalise such a target — including Cloudflare Workers — are not affected, and neither are those behind an intermediary that strips the fragment.Impact
An attacker can cause the application to act on parameters that components in front of it never observe.
This may lead to:
This issue affects applications that read query parameters and run on a runtime that passes a literal
#through to the request URL.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
hono/jsx renders plain strings unescaped in boundary components, leading to XSS
CVE-2026-93981 / GHSA-hxh3-vqpv-xpqv
More information
Details
Summary
hono/jsxdoes not HTML-escape a plain string placed directly as a child orfallbackofSuspenseorErrorBoundary, as the only child of aContext.Provider, or as the root value ofrenderToString()/renderToReadableStream()fromhono/jsx/dom/server. Such a string is emitted as markup instead of text.Details
These paths stringify their input and treat the result as already-escaped HTML, so a plain string passes through unchanged. Notable cases:
Suspense: a string child, or a stringfallbackwhile a child suspends. With streaming, the fallback reaches the browser in the initial chunk.ErrorBoundary: a string child alongside an asynchronous sibling. The all-synchronous case was fixed in 4.11.7 (GHSA-9r54-q6cx-xmh5).Context.Provider: a single string child. Multiple children are escaped.hono/jsx/dom/server: a string, or an array containing strings, passed as the root.A lone
{children}forwarded by a wrapper component is enough to reach these paths. Strings wrapped in an element, values fromraw()or thehtmlhelper, and client-side rendering withhono/jsx/domare not affected.Impact
An attacker who controls a string rendered in an affected position can inject arbitrary HTML into the server-rendered page, leading to cross-site scripting under the application's origin.
This issue affects applications that render untrusted strings directly in one of the positions above during server-side rendering.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Hono:
serveStaticdecodes the request path a second time, leading to bypass of middleware on static pathsCVE-2026-111757 / GHSA-5r4p-p66f-jhc7
More information
Details
Summary
serveStaticdecodes the request path a second time after Hono has already decoded it for routing. A crafted request can be routed as one path and served as another, so middleware mounted on a static prefix does not run for a file under that prefix.Details
Hono decodes the request path once before routing.
serveStaticdecoded it again before resolving the file. With a malformed percent-encoded sequence, the first decode leaves part of the path encoded, the router matches the encoded form, and the second decode resolves the real directory. The file is still resolved inside the configured root; this is not a traversal outside it.Impact
An unauthenticated attacker may reach static files without the middleware on their prefix running, for example an authentication check. This affects applications that mount middleware on part of the directory served by
serveStatic. Applications that serve only public files are not affected.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
honojs/hono (hono)
v4.13.11Compare Source
Security fixes
serveStaticdecodes the request path a second time, leading to bypass of middleware on static pathsAffects:
hono/serve-staticand the adapters built on it (hono/bun,hono/deno,hono/cloudflare-workers,@hono/bun,@hono/deno,@hono/cloudflare-workers). FixesserveStaticdecoding an already-decoded path, where a crafted request could be routed as one path and served as another, skipping middleware mounted on a static prefix. GHSA-5r4p-p66f-jhc7serveStaticnow rejects request paths that still contain%after decoding. To serve files whose names contain a literal%, setallowPercentInPath: true.The same fix ships in
@hono/node-serverv2.1.3.v4.13.10Compare Source
Adapters are now separate packages
The runtime adapters are now published as their own packages:
@hono/bun,@hono/deno,@hono/cloudflare-workers,@hono/aws-lambda,@hono/lambda-edge,@hono/netlify,@hono/vercel, and@hono/service-worker.@hono/denois also on JSR.hono/<adapter>still works in v4 but is deprecated and will be removed in v5. Migrating is an import change:hono/cloudflare-pages is deprecated without a replacement package; Cloudflare recommends Workers with static assets.
What's Changed
cr.ymlby the pnpm migration in #54561.0.0-rc.1in #5459adapters/*in #5466Full Changelog: honojs/hono@v4.13.9...v4.13.10
v4.13.9Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.8...v4.13.9
v4.13.8Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.7...v4.13.8
v4.13.7Compare Source
Security fixes
This release includes a fix for the following security issue:
hono/jsxrenders plain strings unescaped in boundary components, leading to XSSAffects:
Suspense,ErrorBoundary, andContext.Providerinhono/jsx, andrenderToString()/renderToReadableStream()inhono/jsx/dom/server. Fixes missing HTML escaping for a plain string placed directly as a child orfallbackof these components, or as the root value of the server rendering functions, so untrusted strings could be emitted as markup. GHSA-hxh3-vqpv-xpqvUsers who render untrusted strings inside
Suspense,ErrorBoundary, orContext.Provider, or pass them directly tohono/jsx/dom/server, are strongly encouraged to upgrade to this version.v4.13.6Compare Source
What's Changed
editorconfig-checkerin #5336Full Changelog: honojs/hono@v4.13.5...v4.13.6
v4.13.5Compare Source
Security fixes
This release includes fixes for the following security issues:
Query parser reads parameters after the URL fragment, causing cache-key and proxy interpretation differentials
Affects: Cache Middleware and applications behind a proxy, WAF, or logging layer that inspects query strings. Fixes query parsing that did not stop at the URL fragment, so a
?after a#was treated as the start of a query string and the application could read parameters that the other component never saw. GHSA-crvj-82cr-hjcxIncomplete fix for CVE-2026-39408:
toSSG()still writes files outside the output directoryAffects:
toSSG()for Static Site Generation. Fixes a path normalization gap where consecutive parent-directory segments inssgParamsvalues were not fully collapsed, bypassing the containment check added in 4.12.12. GHSA-gqvv-2mrq-wpjvUnbounded dot-notation nesting in
parseBody()can cause memory exhaustionAffects:
parseBody()when dot-notation parsing is enabled. Fixes unbounded expansion of dot-separated field names, where a small request body could allocate a disproportionately large object graph and concurrent requests could exhaust the heap. GHSA-g6gw-c38x-mqfcUsers who use Cache Middleware, deploy behind a proxy or WAF that inspects query strings, use Static Site Generation, or use
parseBody({ dot: true })are strongly encouraged to upgrade to this version.v4.13.4Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.3...v4.13.4
v4.13.3Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.2...v4.13.3
v4.13.2Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.1...v4.13.2
v4.13.1Compare Source
What's Changed
New Contributors
Full Changelog: honojs/hono@v4.13.0...v4.13.1
v4.13.0Compare Source
Hono v4.13.0 is now available!
The highlight of this release is performance: a batch of low-level optimizations makes the core request/response path significantly faster — up to 1.25x on common routes in our benchmark. This release also adds first-class support for the HTTP QUERY method, defined in RFC 10008, a new Method Not Allowed middleware, and more.
Performance improvements
This release includes a series of small optimizations: skipping unnecessary
Headersallocations, replacing regex tests withindexOf, allocating internal state lazily, and more.Here is
benchmarks/fetchcomparing v4.12 and v4.13 (ROUNDS=5 ./compare.sh, Bun 1.4.0, Apple Silicon — each measurement runs in a fresh process, and the variant order is reversed every round to avoid warm-up bias):ping—GET /query—GET /id/1?name=bunjson—GET /userbody—POST /jsonThe individual changes:
for..in#5118indexOf#5121Headerscreation when there are no headers to merge #5122tryDecodeURIComponent#5158#validatedDatalazily #5175In addition, the RegExpRouter rewrite described below makes route registration plus the first match roughly 20% faster.
Thanks @kibertoad for the contributions!
First-class QUERY method support
The QUERY method — a safe, idempotent method that carries a request body — is now a first-class citizen in Hono. You can define QUERY handlers with
app.query():Thanks @shellhaki!
QUERY support across built-in middleware
The built-in middleware has been updated to handle QUERY requests properly:
Cache Middleware
The Cache Middleware now caches QUERY responses. Following RFC 10008 Section 2.7, the cache key incorporates a SHA-256 digest of the request content and its representation metadata, so different query bodies are cached separately:
Note: To support this, the internal cache key format has changed for all methods, including GET. Cached entries are now stored under an internal URL of the form
/.hono/cache?__hono_cache_key=.... If you purge cache entries by URL outside of the middleware (e.g. callingcaches.delete()with the original request URL), you will need to update that logic. Existing cache entries stored with the old format will simply be re-fetched.ETag Middleware
The ETag Middleware now handles conditional requests for QUERY, returning
304 Not ModifiedwhenIf-None-Matchmatches.CORS Middleware
The CORS Middleware now includes QUERY in the default
Access-Control-Allow-Methods, which is nowGET, HEAD, PUT, POST, DELETE, PATCH, QUERY. If you specifyallowMethodsexplicitly, nothing changes for you.Thanks @usualoma and @Cherry!
Method Not Allowed Middleware
The new Method Not Allowed Middleware returns a
405 Method Not Allowedresponse with a properAllowheader when the request path matches a registered route but the method does not:You can customize the response with the
onMethodNotAllowedoption:Thanks @usualoma!
RegExpRouter throws
UnsupportedPathErrorat registration timeThe RegExpRouter now detects unsupported path combinations when routes are registered, instead of at the first matching request. This means misconfigured routes fail fast at startup rather than at runtime. As a bonus, registration plus the first match is roughly 20% faster.
Thanks @usualoma!
Other improvements
hono/utils/headershas been synced with the IANA HTTP Field Name Registry, adding newly registered fields such asAccept-Query. Thanks @akahoshi1421!realmoption for theWWW-Authenticatechallenge on401responses, and challenge values are properly escaped. Thanks @arhxam!useRefandRefObjectare now aligned with React 19. Note that this is a type-level change —RefObject<T>is now{ current: T }, so type a nullable ref asRefObject<T | null>, and passuseRef(undefined)instead ofuseRef(). Thanks @ashunar0!Vary: Accept-Encodingon negotiated responses. Thanks @arhxam!All changes
fetchby @yusukebe in #5113indexOfby @yusukebe in #5121tryDecodeURIComponentby @yusukebe in #5158envfield initializer by @kibertoad in #5174#validatedDatalazily by @kibertoad in #5175fetchby @yusukebe in #5184envfield initializer by @yusukebe in #5186Full Changelog: honojs/hono@v4.12.34...v4.13.0
Thank you to all contributors!
v4.12.34Compare Source
Security fixes
This release includes fixes for the following security issues:
memo()retains SSR output across requests, leading to cross-user data disclosureAffects:
hono/jsx(server-side rendering). Fixesmemo()reusing a retained render result across requests when props compare equal, where a component reading request-scoped values from ambient context —useContext(),useRequestContext(), orgetContext()— could serve HTML rendered for another user's request, disclosing account data or request-scoped secrets such as CSRF tokens. GHSA-f23p-vx2j-j53rReDoS in CORS middleware via
Access-Control-Request-HeadersAffects:
hono/cors. Fixes a whitespace-tolerant regular expression with quadratic backtracking used to parse theAccess-Control-Request-Headerspreflight header whenallowHeadersis not configured (the default), where a single preflight request carrying a long whitespace run could consume seconds of CPU and stall request processing. GHSA-8j4g-w8fx-2239Algorithmic complexity DoS in Language Middleware
Affects:
hono/language. Fixes quadratic string processing in language-tag normalization, where a crafted language tag with a large number of hyphen-separated subtags — supplied via a query parameter, cookie, orAccept-Languageheader — could cause excessive CPU consumption and block the event loop. GHSA-54fx-42gc-7vw4Proxy Helper does not remove response headers listed in the
ConnectionheaderAffects:
hono/proxy. Fixesproxy()forwarding response headers that the origin'sConnectionheader designates as connection-scoped, where headers intended only for the immediate peer — per RFC 9110 Section 7.6.1 — could be exposed to clients, disclosing connection-scoped or internal metadata. GHSA-79qm-7rj5-m7r9Users who use
hono/jsxfor server-side rendering,hono/cors,hono/language, orhono/proxyare strongly encouraged to upgrade to this version.v4.12.33Compare Source
What's Changed
@hono/node-serverin #5167Full Changelog: honojs/hono@v4.12.32...v4.12.33
v4.12.32Compare Source
What's Changed
Object.create(null)when parsing query, headers, and params in #5161Full Changelog: honojs/hono@v4.12.31...v4.12.32
v4.12.31Compare Source
What's Changed
@ts-expect-errorby @yusukebe in #5130parseBody()by @yusukebe in #5131cloneRawRequestby @yusukebe in #51330by @yusukebe in #5135Full Changelog: honojs/hono@v4.12.30...v4.12.31
v4.12.30Compare Source
What's Changed
Full Changelog: honojs/hono@v4.12.29...v4.12.30
v4.12.29Compare Source
What's Changed
compatibilityDateby @yusukebe in #5100Configuration
📅 Schedule: (UTC)
🚦 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.