CVE-2026-126358: Hono: RegExpRouter skips wildcard middleware for some route sets and for paths with an encoded line terminator
Summary
RegExpRouter, which the default SmartRouter selects for most applications, skipped wildcard middleware in three cases, so a route handler ran without the middleware registered for it:
1. Middleware whose parameter is written with the explicit default pattern, such as /api/:tenant{[^/]+}/admin/, was not applied to a route written as /api/:tenant/admin/:id. (since 4.13.0) 2. Middleware on /admin/ was not applied to a route registered on /admin for paths under /admin/. (since 4.1.4) 3. For a path with an encoded line terminator (%0A, %0D, %E2%80%A8, %E2%80%A9), no wildcard pattern matched, so the request reached the not-found handler without any wildcard middleware. (since 4.4.0)
TrieRouter, LinearRouter and PatternRouter apply the middleware in all three cases.
Details
RegExpRouter decides at registration time which wildcard middleware covers which route. In cases 1 and 2 it treated patterns that match the same requests as different ones. In case 3 the compiled wildcard did not match line terminators.
The fix derives the coverage from the structure of the registered paths and lets wildcards match line terminators. It also corrects other differences from the other routers (a wildcard in the middle of a path with parameters, duplicate middleware, middleware on static routes), and rejects custom patterns that can match the empty string, such as {[0-9]}, with UnsupportedPathError. PreparedRegExpRouter data must be regenerated.
Impact
An unauthenticated client can reach a route handler, or the not-found handler, without the authentication or authorization middleware registered on a wildcard path.
This affects applications that use RegExpRouter, directly or through the default SmartRouter, and rely on wildcard middleware for authentication or authorization.
Workarounds
Use new Hono({ router: new TrieRouter() }).
Other sources
Hono is a Web application framework that provides support for any JavaScript runtime. From 4.1.4 until 4.13.16, RegExpRouter can omit wildcard middleware in three version-specific cases: since 4.13.0, middleware using the explicit default parameter pattern in /api/:tenant{[^/]+}/admin/ is not applied to a route written as /api/:tenant/admin/:id; since 4.1.4, middleware on /admin/ is not applied to a route registered as /admin for paths under /admin/; and since 4.4.0, a request path containing an encoded line terminator can reach the not-found handler without wildcard middleware. The default SmartRouter selects RegExpRouter for most applications, and the router's registration-time coverage calculation treated the first two matching pattern pairs as different while its compiled wildcard did not match line terminators in the third case. An unauthenticated client can reach a route handler or the not-found handler without authentication or authorization middleware registered on the wildcard path. TrieRouter, LinearRouter, and PatternRouter apply the middleware in the three described cases. 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
Configure Hono to use TrieRouter instead of the vulnerable RegExpRouter, for example: new Hono({ router: new TrieRouter() })
Hono SmartRouter router = new TrieRouter() - Operational
Regenerate PreparedRegExpRouter data after applying the fix
Event History
Frequently Asked Questions
Which Hono applications are most likely to be affected?
Applications using the default SmartRouter are most likely to be affected because it selects RegExpRouter for most applications. Applications explicitly using TrieRouter, LinearRouter, or PatternRouter apply the wildcard middleware in the described cases.
What must an attacker do to bypass middleware?
The attacker must request a route that falls into one of the route-pattern mismatches, or use a path containing an encoded line terminator such as %0A, %0D, %E2%80%A8, or %E2%80%A9. No privileges or user interaction are indicated by the supplied CVSS vector.
How can I determine whether my route configuration is exposed?
Review wildcard middleware and route registrations for explicit default parameter patterns such as /api/:tenant{[^/]+}/admin/* paired with routes such as /api/:tenant/admin/:id, and for /admin/* middleware paired with /admin* routes. Also test requests containing encoded line terminators, since wildcard middleware may not run for those paths.
What can be done if updating is not immediately possible?
Use TrieRouter, LinearRouter, or PatternRouter instead of RegExpRouter where feasible, as those routers apply wildcard middleware in all three described cases. Review any authorization or other security middleware registered through affected wildcard routes.