CVE-2026-39409

What it actually does

The `ipRestriction()` middleware in the Hono framework fails to canonicalize IPv4-mapped IPv6 addresses (e.g., `::ffff:127.0.0.1`) before processing access control rules. In dual-stack environments like Node.js, this causes IPv4-based allow/deny rules to be ignored for clients connecting with such addresses, leading to a bypass of the intended IP-based access controls.

Why it matters to the business

Applications relying on Hono's IP restriction feature to protect sensitive endpoints or data are vulnerable to unauthorized access. This can lead to data breaches, unauthorized system modifications, or circumvention of security controls if an attacker connects from an IP that should be blocked but uses a specific IPv6 format to bypass the check.

How an attack unfolds

An attacker identifies a web application using a vulnerable version of Hono with IP-based access restrictions in a dual-stack environment. The attacker, knowing their IP address is on a deny list, initiates a connection to a protected endpoint. By ensuring their client presents their source IP as an IPv4-mapped IPv6 address (e.g., `::ffff:ATTACKER_IP`), they exploit the vulnerability. The Hono middleware fails to normalize this address to its IPv4 equivalent, does not match it against the deny rule, and incorrectly grants the attacker access to the restricted resource.

How to fix it

Upgrade the Hono framework to version 4.12.12 or later. This version correctly canonicalizes IPv4-mapped IPv6 addresses before applying restriction rules. To do this, update your project's `package.json` file and run your package manager's install command (e.g., `npm install` or `yarn install`). If an immediate upgrade is not possible, consider implementing a mitigation at a higher level, such as using a reverse proxy or load balancer to normalize all incoming client IP addresses to a consistent format before they reach the Hono application.

How to confirm the fix worked

To confirm the vulnerability is remediated, check your project's dependency lock file (e.g., `package-lock.json`, `yarn.lock`) to ensure that the resolved version of the `hono` package is 4.12.12 or greater. To test for exposure, create a test endpoint with an IP restriction rule that denies a specific IPv4 address (e.g., `127.0.0.1`). Attempt to access this endpoint from a client that presents its IP as the IPv4-mapped IPv6 equivalent (`::ffff:127.0.0.1`). If the request is correctly denied, the patch is effective. If the request is allowed, the application remains vulnerable.

Typical attack path

1. Identify a target application using a vulnerable version of the Hono framework and its `ipRestriction()` middleware.
2. Discover that the application is hosted in a dual-stack environment where IPv4 addresses can be represented as IPv4-mapped IPv6 addresses.
3. Craft a request to a protected endpoint from an IP address that is expected to be blocked by an IPv4 rule.
4. Ensure the connection uses the IPv4-mapped IPv6 format for the source address (e.g., `::ffff:x.x.x.x`).
5. The middleware fails to apply the IPv4 rule, and the attacker successfully bypasses the access control.

How to detect it

Review web server and application logs for successful requests (e.g., HTTP 200-299 status codes) to endpoints that are supposed to be protected by IPv4-based IP restrictions. A strong indicator of exploitation is a successful request where the source IP address is in the IPv4-mapped IPv6 format (i.e., starts with `::ffff:`) and its corresponding IPv4 address is on a deny list.

• Successful log entries with source IP matching regex `::ffff:\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}` to an endpoint protected by an IPv4 deny list.

What your security team should do

• Immediately upgrade all applications using the Hono framework to version 4.12.12 or newer to patch the vulnerability.
• Use dependency scanning tools to identify all projects and systems that utilize vulnerable versions of Hono.
• For systems that cannot be immediately upgraded, review the business impact of the endpoints protected by `ipRestriction()` and consider applying network-level mitigations, such as IP address normalization in a reverse proxy.