Vulnerability GHSA-h7mg-cq63-vhpq

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() }).