Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.12, ipRestriction() does not…
GitHub_M·CWE-180·Published 2026-04-08
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.12, ipRestriction() does not canonicalize IPv4-mapped IPv6 client addresses (e.g. ::ffff:127.0.0.1) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior. This vulnerability is fixed in 4.12.12.
Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.12, ipRestriction() does not canonicalize IPv4-mapped IPv6 client addresses (e.g. ::ffff:127.0.0.1) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior. This vulnerability is fixed in 4.12.12.
## Summary `ipRestriction()` does not canonicalize IPv4-mapped IPv6 client addresses (e.g. `::ffff:127.0.0.1`) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior. ## Details The middleware classifies client addresses based on their textual form. Addresses containing "`:`" are treated as IPv6, including IPv4-mapped IPv6 addresses such as `::ffff:127.0.0.1`. These addresses are not normalized to IPv4 before matching. As a result: * IPv4 static rules (e.g. `127.0.0.1`) do not match because the raw string differs * IPv4 CIDR rules (e.g. `127.0.0.0/8`, `10.0.0.0/8`) are skipped because the address is treated as IPv6 For example, with: `denyList: ['127.0.0.1']` a request from `127.0.0.1` may be represented as `::ffff:127.0.0.1` and bypass the deny rule. This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses. ## Impact Applications that rely on IPv4-based `ipRestriction()` rules may incorrectly allow or deny requests. In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.
## Summary `ipRestriction()` does not canonicalize IPv4-mapped IPv6 client addresses (e.g. `::ffff:127.0.0.1`) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior. ## Details The middleware classifies client addresses based on their textual form. Addresses containing "`:`" are treated as IPv6, including IPv4-mapped IPv6 addresses such as `::ffff:127.0.0.1`. These addresses are not normalized to IPv4 before matching. As a result: * IPv4 static rules (e.g. `127.0.0.1`) do not match because the raw string differs * IPv4 CIDR rules (e.g. `127.0.0.0/8`, `10.0.0.0/8`) are skipped because the address is treated as IPv6 For example, with: `denyList: ['127.0.0.1']` a request from `127.0.0.1` may be represented as `::ffff:127.0.0.1` and bypass the deny rule. This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses. ## Impact Applications that rely on IPv4-based `ipRestriction()` rules may incorrectly allow or deny requests. In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.
Hono es un framework de aplicación web que proporciona soporte para cualquier entorno de ejecución de JavaScript. Antes de la versión 4.12.12, ipRestriction() no canoniza las direcciones de cliente IPv6 mapeadas a IPv4 (p. ej., ::ffff:127.0.0.1) antes de aplicar las reglas de permiso o denegación de IPv4. En entornos como Node.js de doble pila, esto puede hacer que las reglas IPv4 no coincidan, lo que lleva a un comportamiento de autorización no deseado. Esta vulnerabilidad se corrige en la versión 4.12.12.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | NVD | 5.3 | 3.9 | 1.4 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | Secondary | GHSA | 5.3 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 4.0 | Primary | cve.org | 6.3 | — | — | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
| 4.0 | Primary | cve.org | 6.3 | — | — | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
| 4.0 | Secondary | GHSA | 6.3 | — | — | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
| 4.0 | Secondary | NVD | 6.3 | — | — | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X |