Search
Search Results (9 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-126343 | 1 Hono | 1 Node-server | 2026-11-13 | 5.3 Medium |
| @hono/node-server allows running the Hono application on Node.js. From 2.0.0 until 2.1.6, the WebSocket upgrade handler waits for the Hono application to finish asynchronous middleware or handler work without first attaching an error listener to the socket. If an unauthenticated client resets the TCP connection during that window, the socket emits an unhandled ECONNRESET error and terminates the Node.js process. If a global uncaughtException handler suppresses termination, the pending upgrade waiter is not released and repeated requests can grow the heap. This affects applications that enable WebSocket support and perform asynchronous work on the upgrade path. This issue is fixed in version 2.1.6. | ||||
| CVE-2026-126344 | 1 Hono | 1 Node-server | 2026-11-13 | 5.4 Medium |
| @hono/node-server allows running the Hono application on Node.js. From 2.0.0 until 2.1.6, the WebSocket upgrade path resolves a raw request-target beginning with // against a base URL built from the Host header, causing the WHATWG URL parser to treat the request-target as a network-path reference and replace the host in c.req.url. Routing still uses the local WebSocket path, so an application that compares the Origin header with the origin of c.req.url, including checks implemented with csrf(), compares an attacker's origin with itself and accepts the connection. A page on another site can consequently open a WebSocket with the victim's cookies and read and send messages when the application uses upgradeWebSocket and trusts the host in c.req.url. Ordinary HTTP requests are not affected. This issue is fixed in version 2.1.6. | ||||
| CVE-2026-126210 | 1 Hono | 1 Node-server | 2026-11-13 | 5.3 Medium |
| @hono/node-server allows running the Hono application on Node.js. Prior to 1.19.18 and from 2.0.0 until 2.1.6, the server passes a raw request-target containing a backslash in its path to the WHATWG URL parser, which treats the backslash as a path separator and resolves dot segments. A reverse proxy, load balancer, or web application firewall that preserves the backslash and applies path-based rules to the original request can therefore permit a request that the application normalizes to a blocked route. This lets an unauthenticated client reach route content that the upstream component was intended to deny, while Hono application access controls are unaffected because they operate on the normalized path. This issue is fixed in versions 1.19.18 and 2.1.6. | ||||
| CVE-2026-118663 | 1 Hono | 1 Node-server | 2026-10-29 | 5.3 Medium |
| @hono/node-server allows running the Hono application on Node.js. From 1.19.10 until 2.1.3, serveStatic decodes a request path a second time after Hono has already decoded it for routing, so a malformed percent-encoded sequence can make route middleware evaluate an encoded path while static file resolution uses a different directory. An unauthenticated attacker can bypass middleware mounted on a protected static prefix and read a file inside the configured static root, although the flaw does not permit traversal outside that root. This issue is fixed in version 2.1.3. | ||||
| CVE-2026-73565 | 1 Hono | 1 Node-server | 2026-10-24 | 5.3 Medium |
| @hono/node-server allows running the Hono application on Node.js. From 2.0.0 until 2.0.10, a WebSocket upgrade request to an upgradeWebSocket route with a missing or malformed Sec-WebSocket-Key header causes src/websocket.ts to retain the request's IncomingMessage in waiterMap and leave waitForWebSocket pending because ws.handleUpgrade emits no connection event. The aborted handshake therefore has no cleanup path, allowing an unauthenticated attacker to flood a public route, cause unbounded memory growth, and eventually make the service unavailable. This issue is fixed in version 2.0.10. | ||||
| CVE-2026-39406 | 1 Hono | 1 Node-server | 2026-04-21 | 5.3 Medium |
| @hono/node-server allows running the Hono application on Node.js. Prior to 1.19.13, a path handling inconsistency in serveStatic allows protected static files to be accessed by using repeated slashes (//) in the request path. When route-based middleware (e.g., /admin/*) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass. This vulnerability is fixed in 1.19.13. | ||||
| CVE-2026-29087 | 1 Hono | 1 Node-server | 2026-04-16 | 7.5 High |
| @hono/node-server allows running the Hono application on Node.js. Prior to version 1.19.10, when using @hono/node-server's static file serving together with route-based middleware protections (e.g. protecting /admin/*), inconsistent URL decoding can allow protected static resources to be accessed without authorization. In particular, paths containing encoded slashes (%2F) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served. This issue has been patched in version 1.19.10. | ||||
| CVE-2024-32652 | 1 Hono | 1 Node-server | 2025-09-17 | 7.5 High |
| The adapter @hono/node-server allows you to run your Hono application on Node.js. Prior to 1.10.1, the application hangs when receiving a Host header with a value that `@hono/node-server` can't handle well. Invalid values are those that cannot be parsed by the `URL` as a hostname such as an empty string, slashes `/`, and other strings. The version 1.10.1 includes the fix for this issue. | ||||
| CVE-2024-23340 | 1 Hono | 1 Node-server | 2025-05-30 | 5.3 Medium |
| @hono/node-server is an adapter that allows users to run Hono applications on Node.js. Since v1.3.0, @hono/node-server has used its own Request object with `url` behavior that is unexpected. In the standard API, if the URL contains `..`, here called "double dots", the URL string returned by Request will be in the resolved path. However, the `url` in @hono/node-server's Request as does not resolve double dots, so `http://localhost/static/.. /foo.txt` is returned. This causes vulnerabilities when using `serveStatic`. Modern web browsers and a latest `curl` command resolve double dots on the client side, so this issue doesn't affect those using either of those tools. However, problems may occur if accessed by a client that does not resolve them. Version 1.4.1 includes the change to fix this issue. As a workaround, don't use `serveStatic`. | ||||
Page 1 of 1.