CVE-2026-47674: Hono IP-Restriction Middleware IPv6 Bypass Vulnerability

Technical summary

The ip-restriction middleware in Hono performs string equality comparison on partially normalized IPv6 addresses. The vulnerability stems from incomplete normalization: while some normalization occurs, non-canonical IPv6 representations (e.g., compressed forms like '::1' vs. uncompressed '0000:0000:0000:0000:0000:0000:0000:0001', or IPv4-mapped addresses in hex notation like '::ffff:192.0.2.1' vs. dotted-decimal form) do not match the stored canonical rule entries. When a comparison fails due to representation mismatch, the rule is silently skipped rather than the request being rejected or accepted based on the closest matching rule. CWE-1289 (Improper Validation of Specified Type of Input for an API) and CWE-185 (Incorrect Regular Expression) indicate that the input validation and matching logic are insufficient. The fix in 4.12.21 presumably implements canonical normalization or a more robust IPv6 comparison mechanism.

Business impact

Organizations relying on Hono's IP-restriction middleware to enforce network access controls may inadvertently allow unauthorized IPs to reach their applications or block legitimate users. In scenarios where IP allowlisting is critical—such as restricting APIs to known partners, protecting admin interfaces, or maintaining geofencing policies—this bypass could expose sensitive functionality. The impact depends on rule configuration: deny-list bypasses pose the highest risk, as an attacker could access restricted services; allow-list misses affect availability but not confidentiality. For enterprises deploying Hono in high-trust network environments where IP restriction serves as a security boundary, this is a meaningful integrity and access-control issue.

Affected systems

Hono versions prior to 4.12.21 are affected. Any application using the hono/ip-restriction middleware with IPv6 allow or deny rules is susceptible to rule bypass via non-canonical IPv6 address representations. The vulnerability is not framework-version-specific across runtimes; it affects Hono deployments regardless of the underlying JavaScript runtime (Node.js, Deno, Bun, Cloudflare Workers, etc.), as the middleware logic is consistent across environments.

Exploitability

The vulnerability requires no authentication, special privileges, or user interaction. An attacker can trivially craft HTTP requests using alternative IPv6 notations to test or exploit misconfigured rules. For example, sending a request from an IPv6 address using a compressed representation when the deny rule lists only the uncompressed form will bypass the filter. Attack surface is broad: any publicly accessible Hono service using ip-restriction is a potential target. However, exploitability is gated by the attacker's ability to forge or control the source IP of requests (requires network position or misconfigured reverse proxy), which is a practical consideration in many environments.

Remediation

Update Hono to version 4.12.21 or later. Applications should verify that their dependency lockfiles or package manifests pin Hono to the patched version after upgrade. Review IP-restriction rule configurations post-update to ensure they remain fit-for-purpose; consider testing with both canonical and non-canonical IPv6 representations to confirm the fix works as expected. For organizations unable to upgrade immediately, implement defense-in-depth by validating IP restrictions at the reverse proxy or network edge (e.g., WAF, load balancer rules), though this increases operational overhead.

Patch guidance

Patch to Hono 4.12.21 or later. Verify the patched version is available in your package manager (npm, deno.land, or equivalent), and test in a staging environment before deploying to production. The fix should involve implementing full IPv6 canonicalization or a comparison method resilient to representation variations. Check the Hono release notes or security advisory for specific details on the normalization approach used in 4.12.21.

Detection guidance

Monitor Hono application logs for IP-restriction middleware behavior: look for unusual patterns of requests from IPv6 addresses that do not match typical client patterns, especially if they correlate with access attempts to sensitive endpoints. Implement synthetic testing using known IPv6 address representations (compressed, uncompressed, IPv4-mapped) against your allow/deny rules to verify correct behavior pre- and post-patch. Network traffic analysis can reveal requests from unexpected IPv6 notation variants. Inventory all Hono deployments and their current versions to identify instances running vulnerable builds.

Why prioritize this

This is a medium-severity access-control bypass with straightforward attack mechanics and broad applicability to any Hono application using IP restrictions. While the CVSS score of 5.3 reflects the lack of direct confidentiality impact and the requirement for network position/IP control, the integrity and availability implications are meaningful in security-sensitive deployments. Organizations heavily reliant on IP-based access control should prioritize patching; others may defer slightly while assessing their use of the middleware. The silent nature of the failure (rules are skipped without warning) makes this particularly dangerous because misconfiguration or bypass may go undetected.

Risk score, explained

CVSS 5.3 (MEDIUM) is assigned under CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. The Network attack vector and Low attack complexity reflect the ease of crafting requests with non-canonical IPv6 addresses. Integrity is impacted (I:L) because the middleware's ability to enforce intended access control is compromised, allowing unauthorized access or blocking legitimate traffic depending on configuration. Confidentiality and Availability are not directly impacted (C:N/A:N), as the flaw does not directly leak data or prevent legitimate service operation—it merely fails to enforce stated policy. The score is appropriate for a silent bypass of an access-control feature that assumes IP validation is working as designed.

Frequently asked questions