CVE-2026-47674

What it actually does

The ip-restriction middleware in Hono fails to properly canonicalize IPv6 addresses before comparing them against deny/allow lists. An attacker can use an alternative but equivalent representation of a blocked IP address (e.g., compressed IPv6, hex-notation IPv4-mapped) to bypass the IP-based access control mechanism, as the non-canonical string will not match the rule.

Why it matters to the business

Applications relying on Hono's IP restriction feature for security are exposed to authorization bypass. This could allow unauthorized actors from blocked IP addresses to access protected endpoints, administrative interfaces, or geographically restricted content. This circumvention of security controls can lead to unauthorized data access, modification, or exposure of internal services, potentially violating compliance policies.

How an attack unfolds

An attacker identifies a web application using a vulnerable version of Hono with IP-based access controls. The attacker, knowing or guessing that their IP address is on a deny list, crafts a request from that same IP. However, they manipulate the IP address representation to a non-canonical format, such as an IPv4-mapped address in hex notation (e.g., `::ffff:7f00:0001` instead of `127.0.0.1`). The vulnerable middleware performs a simple string comparison, fails to recognize the non-canonical form as matching the blocked IP, and incorrectly grants access to the protected resource.

How to fix it

The vulnerability is resolved in version 4.12.21 of the Hono framework. Upgrade the `hono` package in your application to version 4.12.21 or a later version. If an immediate upgrade is not possible, consider using a reverse proxy or Web Application Firewall (WAF) as a compensating control to enforce IP-based restrictions with robust address canonicalization before traffic reaches the application.

How to confirm the fix worked

To validate the fix, ensure your project's dependencies specify `hono` version 4.12.21 or newer. To test for the vulnerability, configure the `ip-restriction` middleware to deny a specific IP address. Attempt to access the protected resource from that IP using various non-canonical IPv6 representations (e.g., `::ffff:C0A8:0101` for `192.168.1.1`). A patched system will correctly block all requests from that IP, regardless of its string representation, while a vulnerable system will allow them.

Typical attack path

1. An attacker identifies a web application using the Hono framework and its `ip-restriction` middleware.
2. The attacker determines an IP address that is intended to be blocked by the application's rules.
3. The attacker crafts a request from the blocked IP address but represents it in a non-canonical IPv6 format.
4. The request is sent to a protected endpoint on the target application.
5. The vulnerable middleware fails to match the non-canonical IP against its blocklist, allowing the request and bypassing the access control.

How to detect it

Detection requires analyzing web server and application access logs. Look for successful requests (e.g., HTTP 200) to endpoints that should be protected by IP restrictions. The primary indicator is a request from a source IP address that, when fully normalized, matches an IP on the deny list, but is represented in logs in a non-canonical format (e.g., IPv4-mapped IPv6, compressed IPv6). Correlate access logs with the configured IP restriction rules to identify bypasses.

What your security team should do

• Prioritize upgrading all applications using the Hono framework to version 4.12.21 or newer.
• Audit applications to identify all instances where Hono's `ip-restriction` middleware is used as a security control.
• For critical applications where patching is delayed, implement a compensating control at the network edge, such as a WAF rule, to normalize and filter IP addresses.
• Review access logs for endpoints protected by this middleware, looking for successful requests from source IPs that should have been blocked.