CVE-2026-126357: Authentication Bypass via Mount Path Transformation in Hono

Hono is a lightweight web application framework designed to operate across JavaScript runtimes conforming to Web Standards, including Cloudflare Workers, Deno, Bun, and Node.js. A core architectural feature of Hono is the ability to compose applications by mounting independent Web Standard request handlers, third-party routers, or Hono sub-applications under a designated path prefix using app.mount() or the mount() middleware.

When the primary Hono application delegates an incoming HTTP request to a mounted handler, it must strip the mount prefix from the request URL so the sub-application can route the request relative to its own root. Prior to version 4.13.16, the prefix removal and URL reconstruction implementation contained two distinct flaws that caused the outer router and the mounted sub-application to evaluate different normalized paths for the same HTTP request.

Classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel), this discrepancy arises when authentication or authorization middleware is registered on the outer Hono application to protect specific subpaths inside a mounted application (for example, protecting /api/admin/* on an application mounted at /api). Because the outer router evaluates the raw or single-decoded path before prefix transformation, while the inner mounted application evaluates the path after prefix slicing and WHATWG URL re-normalization, an attacker can craft requests that evade the outer middleware filter but resolve to the protected inner path upon reaching the mounted handler.

The vulnerability stems from two separate logical defects in how Hono calculates the mount prefix length and reconstructs the Request object passed to the mounted handler.

Defect 1: Static Route-Pattern Length Slicing

In Hono versions prior to 4.13.16, both src/hono-base.ts and src/middleware/mount/index.ts determined how many characters to strip from the incoming request path by measuring the character length of the route pattern string (mergedPath.length) rather than the character length of the actual runtime segment matched by the router. When a mount path is static (such as /api), the pattern length and the matched prefix length are identical (4). However, when a mount prefix includes dynamic route parameters (such as /:tenant or /api/:version), the static string length of the pattern diverges from the length of the parameter supplied in the HTTP request.

For example, the pattern /:tenant has a static length of 8 characters. If a client sends a request where the :tenant parameter is only 1 character long (e.g., /a/...), the mount handler still strips 8 characters from the front of the pathname. This removes /a plus the subsequent 6 characters of the inner path. An attacker can insert arbitrary padding segments at the beginning of the inner path so that the outer router fails to match security middleware bound to /:tenant/admin/*, while the 8-character slice removes the padding and delivers /admin/* directly to the mounted application.

Defect 2: WHATWG URL Re-Normalization of Decoded Pathnames

Starting in version 4.12.21, Hono reconstructed the forwarded URL by taking the decoded request pathname (this.getPath(request) or c.req.path), slicing off the mount prefix, and assigning the resulting decoded string directly to the .pathname property of a new URL(request.url) instance.

According to the WHATWG URL Standard implemented across JavaScript runtimes, assigning a string to url.pathname invokes the URL path setter state machine. This state machine treats both forward slashes (/) and backslashes (\) as path segment delimiters, converts all backslashes into forward slashes, and resolves relative dot segments (. and ..) by collapsing the preceding path segment.

When an incoming request contains percent-encoded backslashes (%5C) or double-encoded dot segments (%252e%252e), Hono's outer router decodes %5C into a literal \ character during initial path extraction. Because Hono's router only splits segments on forward slashes (/), it treats foo\.. or ..%5Cadmin as a single literal segment name and does not trigger middleware attached to /api/admin/*. However, when the mount handler assigns this decoded string containing a literal \ back into url.pathname, the runtime's WHATWG URL parser normalizes \ to / and collapses the .. traversal segment. The mounted sub-application subsequently receives a normalized Request targeting /admin/*.

Prior to commit 34f90432a1794b28e52802670efcd01963f716d6, the default replaceRequest implementation in src/hono-base.ts (and its counterpart in src/middleware/mount/index.ts) used static pattern length calculation and mutated url.pathname using the decoded path:

// Vulnerable implementation prior to 4.13.16
replaceRequest ||= (() => {
  const mergedPath = mergePath(this._basePath, path)
  // BUG 1: Uses static length of the route pattern (e.g., "/:tenant".length === 8)
  const pathPrefixLength = mergedPath === '/' ? 0 : mergedPath.length
  return (request) => {
    const url = new URL(request.url)
    // BUG 2: this.getPath(request) returns a decoded pathname.
    // Assigning a decoded pathname containing '\' or '..' back to url.pathname
    // triggers WHATWG URL normalization and directory traversal resolution.
    url.pathname = this.getPath(request).slice(pathPrefixLength) || '/'
    return new Request(url, request)
  }
})()

The patch in version 4.13.16 resolves both issues by introducing two dedicated utility modules: src/utils/mount.ts and stripPathPrefix in src/utils/url.ts.

First, getPathPrefixLength in src/utils/mount.ts inspects the router match results (c.req[GET_MATCH_RESULT]) at runtime to compute the exact length of the matched prefix string, accounting for dynamic parameter values and rejecting ambiguous wildcard or duplicate parameter configurations:

// Patched dynamic prefix length calculation in src/utils/mount.ts
// Extracts actual matched parameter values from the router match result
// rather than relying on the static template string length.

Second, stripPathPrefix in src/utils/url.ts avoids assigning decoded paths back to url.pathname. Instead, it advances segment-by-segment through the raw URL pathname (url.pathname) in parallel with the decoded pathname up to the matched prefixLength, and slices the raw path directly:

// Patched prefix stripping in src/utils/url.ts
export const stripPathPrefix = (
  rawPath: string,
  decodedPath: string,
  prefixLength: number
): string => {
  if (rawPath.at(-1) === '/' && decodedPath.at(-1) !== '/') {
    rawPath = rawPath.slice(0, -1)
  }
  let index = 0
  for (
    let i = decodedPath.indexOf('/');
    i !== -1 && i < prefixLength;
    i = decodedPath.indexOf('/', i + 1)
  ) {
    index = rawPath.indexOf('/', index + 1)
    if (index === -1) {
      return '/'
    }
  }
  // Returns a slice of rawPath, preserving percent-encoding such as %5C
  // so new URL() does not reinterpret decoded backslashes as path separators.
  return rawPath.slice(index) || '/'
}

Fix Completeness Assessment

The fix addresses both root causes comprehensively. By mapping slash boundaries between decodedPath and rawPath and slicing rawPath, any percent-encoded characters (%5C, %2e) remain percent-encoded when assigned to url.pathname, preventing the WHATWG URL setter from converting %5C into / or collapsing .. segments that were not already present in the raw URL. Furthermore, validating mount route patterns at registration time prevents edge-case parameter misalignments.

Exploitation requires no authentication or special privileges, provided the target Hono application protects routes inside a mounted sub-application using outer Hono middleware. Depending on how the application is configured, an attacker can leverage either the dynamic prefix length discrepancy or the backslash traversal normalization.

Attack Vector 1: Dynamic Mount Prefix Slicing Bypass

Consider a multi-tenant Hono application that applies authentication middleware to /:tenant/admin/* on the main router and mounts an internal application at /:tenant:

import { Hono } from 'hono'
 
const internalApp = new Hono()
internalApp.get('/admin/secret', (c) => c.text('Confidential Admin Data'))
 
const app = new Hono()
app.all('/:tenant/admin/*', authMiddleware)
app.mount('/:tenant', internalApp.fetch)

Here, the mount pattern /:tenant has a static length of 8 characters. An unauthenticated attacker sends the following request:

GET /a/publi/admin/secret HTTP/1.1
Host: target.example.com

1. The outer router matches the request path /a/publi/admin/secret against the middleware pattern /:tenant/admin/*. Here, :tenant is `

The primary impact of CVE-2026-126357 is the bypass of authentication, authorization, rate-limiting, or access-control middleware applied at the outer Hono router level when protecting subpaths served by a mounted application.

Scope and Preconditions

Applications are only vulnerable if they meet two structural conditions:

1. The application uses app.mount() or the mount() middleware to delegate routing to a sub-application or secondary request handler.
2. Security controls (such as JWT verification, session checks, or IP allowlisting) are enforced via middleware on the outer Hono instance targeting specific subpaths within the mount prefix, rather than being enforced across the entire mount prefix (app.use('/api/*', auth)) or inside the mounted sub-application itself.

Note that Attack Vector 1 (dynamic prefix slicing) affects all Hono versions prior to 4.13.16 when dynamic parameters are used in the mount path. Attack Vector 2 (backslash and traversal normalization via decoded path assignment) specifically affects Hono versions from 4.12.21 through 4.13.15 across any static or dynamic mount prefix.

CVSS v3.1 Breakdown

The vulnerability is assigned a CVSS v3.1 base score of 5.3 (Medium) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). While the official vector records a Low Confidentiality impact (C:L) and no Integrity impact (I:N) under baseline assumptions, the concrete impact in production environments depends entirely on the functionality exposed by the bypassed inner routes. If the protected inner endpoints perform administrative state changes or expose sensitive tenant data, the practical confidentiality and integrity impact for that deployment increases accordingly.

Official Patch

The vulnerability is resolved in Hono version 4.13.16. Development and operations teams should upgrade the hono package to 4.13.16 or later immediately using their runtime package manager:

# npm
npm install hono@^4.13.16
 
# pnpm
pnpm update hono
 
# bun
bun update hono
 
# yarn
yarn upgrade hono

Defense-in-Depth and Workarounds

In environments where an immediate upgrade to 4.13.16 cannot be deployed, the following architectural mitigations eliminate the attack surface:

• Enforce Authentication Inside the Mounted Application: Attach authentication and authorization middleware directly to the mounted sub-application instance rather than relying on the outer router to filter subpaths before mounting.
• Scope Outer Middleware to the Entire Mount Prefix: If the entire mounted application requires authentication, bind the outer middleware to the root mount prefix (e.g., app.use('/api/*', authMiddleware)) rather than a nested subpath (app.use('/api/admin/*', authMiddleware)).
• Avoid Dynamic Parameters in Mount Prefixes: Replace parameterized mount paths (such as app.mount('/:tenant', subApp)) with static mount prefixes until the package is updated.
• Normalize and Filter at the Edge: Configure upstream reverse proxies, CDNs, or Web Application Firewalls (WAFs) to reject HTTP requests containing percent-encoded backslashes (%5C, %5c), literal backslashes (\), or encoded directory traversal sequences (%2e%2e, %252e%252e) in the URI path.