CVE-2026-126357: Hono: `mount()` and `app.mount()` can forward a path that bypasses middleware scoped inside the mount prefix
Summary
mount() and app.mount() remove the mount prefix from the request path and forward the rest to the mounted application. Two mistakes in that step let a crafted request reach a route of the mounted application that the outer application protects with path-scoped middleware, such as an authentication check on /app/admin/. The outer application routes on the original path, so the middleware does not run.
Details
1. Dynamic prefix (all affected versions): for a mount such as /api/:tenant/, the prefix was removed by the length of the route pattern, not of the matched prefix. A request with a longer or shorter first segment is cut in the middle, so /api/a/xxxxx/admin/secret reaches the mounted application as /admin/secret. 2. Re-normalization (since 4.12.21): the forwarded path was built from the decoded request path and assigned to url.pathname, which turns a decoded backslash into / and collapses ... /app/public%5C..%5Cadmin/secret reaches the mounted application as /admin/secret.
The fix removes the prefix segment by segment from the raw pathname, using the matched parameter values for its length. Route patterns that cannot be handled safely now throw: duplicate parameter names and a wildcard inside the last segment such as /assets. A trailing slash in an app.mount() prefix no longer removes an extra segment.
Impact
An unauthenticated client can reach a route of a mounted application that the outer application protects with path-scoped middleware.
This affects applications that use mount() or app.mount() and rely on middleware registered on a sub-path inside the mount prefix for authentication or authorization.
Workarounds
Register the authentication middleware inside the mounted application.
Other sources
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.13.16, mount() and app.mount() can remove a dynamic mount prefix using the route-pattern length rather than the matched-prefix length, allowing a crafted path to be forwarded as a protected inner route while the outer application routes the original path. Since 4.12.21, rebuilding the forwarded URL from the decoded pathname can also convert a decoded backslash to a slash and collapse parent-directory segments, again causing the mounted application to receive a protected path. An unauthenticated client can use either applicable path transformation to reach a mounted route without authentication or authorization middleware scoped to a subpath inside the mount prefix. This issue is fixed in version 4.13.16.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/honoto a version that resolves this vulnerability.Fixed in 4.13.16 - Upgrade
Upgrade
Honoto a version that resolves this vulnerability.Fixed in 4.13.16 - Configuration
Register authentication middleware inside the mounted application rather than relying on path-scoped middleware in the outer application.
Hono mounted application authentication middleware placement = inside the mounted application
Event History
Frequently Asked Questions
Which deployments are exposed in practice?
Exposure requires a Hono application that uses mount() or app.mount() and relies on middleware scoped to an outer path, while the mounted application can serve a corresponding route. For example, an outer authentication check for /app/admin/* is bypassable if the mounted application can be made to receive /admin/secret.
What does an attacker need to exploit this?
The supplied vector is network-reachable and requires no privileges or user interaction. The attacker must be able to send a crafted request to a vulnerable mount configuration and know or identify a reachable route in the mounted application.
Are both dynamic and static mount prefixes affected in the same way?
No. Dynamic prefixes such as /api/:tenant/* are affected by incorrect prefix-length removal in all affected versions. The decoded-path re-normalization issue applies since 4.12.21 and can affect mounts such as /app when encoded backslashes and dot segments are used.
What request forms are relevant for detection or temporary filtering?
For dynamic mounts, requests with manipulated first path segments can cause the forwarded path to begin at a protected mounted route, such as /api/a/xxxxx/admin/secret reaching /admin/secret. For the re-normalization issue, encoded backslashes and traversal segments are relevant, such as /app/public%5C..%5Cadmin/secret.