Security fixes
This release includes fixes for the following security issues:
Backslash in the request path is parsed as a path separator, bypassing path-based access control at a reverse proxy
Affects: all requests. The raw request-target was passed to the WHATWG URL parser, which treats a backslash in the path as / and resolves .. segments, so /admin\secret reached the application as /admin/secret. A reverse proxy that forwards the backslash unchanged applied its path-based rules to the original path. GHSA-jpvv-r467-5p4w
A request whose path contains a raw backslash is now rejected with 400 Bad Request, for HTTP/1.1, HTTP/2 and WebSocket upgrades. A percent-encoded backslash (%5C) and a backslash in the query string are still accepted.
WebSocket upgrade request-target starting with // replaces the host in c.req.url, bypassing Origin checks
Affects: upgradeWebSocket. The URL of an upgrade request was built by resolving the request-target against the Host header, so a request-target such as //attacker.example/ws set the host of c.req.url to a client-chosen value while routing still saw /ws. An application that compared Origin with the origin of c.req.url could be bypassed by a page on another site. GHSA-7v5p-43qr-wch5
The host of upgrade requests now comes from the Host header, as for ordinary requests.
Unhandled ECONNRESET on the socket during an asynchronous WebSocket upgrade crashes the process
Affects: upgradeWebSocket. While the application handled an upgrade request, the socket had no error listener. A client that reset the connection during asynchronous middleware caused an unhandled 'error' event and terminated the process. GHSA-qv5m-9pm6-hqp3
Error and close events on the socket are now handled while the application runs, and a pending upgrade is released when the socket closes.
The backslash fix also ships in @hono/node-server v1.19.18. Users of upgradeWebSocket are encouraged to upgrade to this version.