GHSA-XPCF-PG52-R92G

Vulnerability from github – Published: 2026-04-08 00:17 – Updated: 2026-04-24 21:06
VLAI
Summary
Hono has incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses
Details

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.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.12.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39409"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:17:14Z",
    "nvd_published_at": "2026-04-08T15:16:14Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`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.\n\n## Details\n\nThe 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.\n\nAs a result:\n\n* IPv4 static rules (e.g. `127.0.0.1`) do not match because the raw string differs\n* IPv4 CIDR rules (e.g. `127.0.0.0/8`, `10.0.0.0/8`) are skipped because the address is treated as IPv6\n\nFor example, with:\n\n`denyList: [\u0027127.0.0.1\u0027]`\n\na request from `127.0.0.1` may be represented as `::ffff:127.0.0.1` and bypass the deny rule.\n\nThis behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses.\n\n## Impact\n\nApplications that rely on IPv4-based `ipRestriction()` rules may incorrectly allow or deny requests.\n\nIn affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.",
  "id": "GHSA-xpcf-pg52-r92g",
  "modified": "2026-04-24T21:06:13Z",
  "published": "2026-04-08T00:17:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-xpcf-pg52-r92g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39409"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/commit/48fa2233bc092f650119f42df043050737cabf39"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/honojs/hono"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/releases/tag/v4.12.12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hono has incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.