CVE-2026-101910: CWE-918: Server-Side Request Forgery (SSRF) in beaugunderson ip-address
### Summary No classifier on `Address6` recognizes the NAT64 local-use range `64:ff9b:1::/48` (RFC 8215). `isPrivate()`, `isLoopback()`, `isLinkLocal()` and their siblings all return `false` for every address in it, so an internal IPv4 destination written through a local-use NAT64 prefix (`64:ff9b:1:7f00:0:100::` for `127.0.0.1`, `64:ff9b:1:a9fe:a9:fe00::` for `169.254.169.254`) reads as an ordinary global address. `getType()` names the range `'NAT64 (local-use)'`, so the library knows what the address is and classifies it as nothing. An application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) will classify an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint. ### Details The fix for GHSA-22jq-vg5j-6vgg (10.2.1) classifies IPv4-mapped (`::ffff:0:0/96`) and NAT64 well-known (`64:ff9b::/96`) addresses by their embedded IPv4 address: `embeddedIPv4()` in `src/ipv6.ts` decodes the trailing 32 bits and every special-use classifier delegates to the resulting `Address4`. Those are the only two ranges `embeddedIPv4()` handles. The local-use range differs in kind from the well-known prefix, which is why extending the decoder does not fix it. RFC 8215 reserves `64:ff9b:1::/48` so an operator can carve their own NAT64 prefix out of it, of any length RFC 6052 allows (`/48`, `/56`, `/64`, or `/96`). Where the IPv4 address sits depends on that choice: `127.0.0.1` is `64:ff9b:1:7f00:0:100::` under a `/48` prefix and `64:ff9b:1::7f00:1` under a `/96` prefix, and each of those decodes to a different address under the other prefix length. There is no single embedded IPv4 address for the library to classify by. What is well-defined is the range as a whole. The IANA IPv6 Special-Purpose Address Registry lists `64:ff9b:1::/48` as not globally reachable, and Python's `ipaddress` module reports `is_private` as `True` and `is_global` as `False` for every address in it. `isPrivate()` covered ULA (`fc00::/7`) plus the decoded mapped and well-known cases, and nothing in the local-use range. ### Affected versions `>= 10.2.0, <= 10.5.0`. The `is*` classification API was extended to `Address6` in 10.2.0; releases before it do not expose the method and are not affected through this vector. ### Impact Every address in `64:ff9b:1::/48` parses successfully, `isValid()` is `true`, and no classifier catches it. Which internal target is reached depends on the NAT64 prefix deployed on the server's network; the well-known prefix column is the patched control from GHSA-22jq-vg5j-6vgg. | Internal target | Well-known form | Classified | Local-use form (`/48` prefix) | Classified | |---|---|---|---|---| | `127.0.0.1` | `64:ff9b::7f00:1` | loopback | `64:ff9b:1:7f00:0:100::` | nothing | | `10.0.0.1` | `64:ff9b::a00:1` | private | `64:ff9b:1:a00:0:100::` | nothing | | `169.254.169.254` | `64:ff9b::a9fe:a9fe` | link-local | `64:ff9b:1:a9fe:a9:fe00::` | nothing | | `192.168.1.1` | `64:ff9b::c0a8:101` | private | `64:ff9b:1:c0a8:1:100::` | nothing | ### Reachability Reaching an internal host through one of these addresses requires that the server's network run a NAT64 translator on a prefix inside `64:ff9b:1::/48` and that the attacker guess or know the prefix length. That is the same precondition the well-known prefix carries (a translator on `64:ff9b::/96`), with the additional constraint that the prefix is operator-chosen rather than fixed. The severity reflects that precondition. ### Proof of concept `npm i [email protected]`, then: ```js const { Address6 } = require('ip-address'); // A guard of the shape the library documents. function isBlocked(host) { const a = new Address6(host); return a.isLoopback() || a.isLinkLocal() || a.isPrivate() || a.isMulticast() || a.isUnspecified(); } for (const h of ['64:ff9b::7f00:1', '64:ff9b:1:7f00:0:100::', '64:ff9b:1::7f00:1']) { console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-> getType()', new Address6(h).getType()); } ``` On affected versions: ``` BLOCK 64:ff9b::7f00:1 -> getType() NAT64 (well-known) ALLOW 64:ff9b:1:7f00:0:100:: -> getType() NAT64 (local-use) ALLOW 64:ff9b:1::7f00:1 -> getType() NAT64 (local-use) ``` ### Remediation Upgrade to the patched release. In the fix, `isPrivate()` returns `true` for every address in `64:ff9b:1::/48`, alongside ULA and the decoded mapped and well-known cases. The range is reported private as a whole rather than by a decoded IPv4 address, for the reason given above; `toAddress4Nat64(prefix)` remains the way to decode an address under a known deployment prefix. `isLoopback()` and `isLinkLocal()` are unchanged for this range, since without the prefix length the library cannot know which IPv4 address is embedded. If you cannot upgrade immediat
AI Analysis
Technical Summary
The ip-address library for IPv4 and IPv6 parsing in JavaScript versions >=10.2.0 and <10.5.1 contains a SSRF vulnerability due to the Address6 isPrivate classifier not recognizing the NAT64 local-use range 64:ff9b:1::/48. Applications that use combined checks of isPrivate, isLoopback, and isLinkLocal for trust boundary decisions may incorrectly classify internal IPv4 destinations encoded via this NAT64 range as external. Exploitation requires a server network using an operator-selected NAT64 prefix within this local-use range, enabling a potential bypass of intended network trust boundaries. This issue is resolved in version 10.5.1.
Potential Impact
This vulnerability can allow an attacker to bypass network trust boundaries by exploiting misclassification of internal IPv4 addresses encoded in the NAT64 local-use range as external. This could lead to unauthorized access or interaction with internal network resources that are otherwise protected by trust boundary checks. The impact is limited to environments using the affected ip-address library versions and operator-selected NAT64 prefixes within the specified range.
Mitigation Recommendations
Upgrade the ip-address library to version 10.5.1 or later, where the issue is fixed. No other mitigation is indicated by the vendor advisory. Patch status is confirmed fixed in 10.5.1.
CVE-2026-101910: CWE-918: Server-Side Request Forgery (SSRF) in beaugunderson ip-address
Description
### Summary No classifier on `Address6` recognizes the NAT64 local-use range `64:ff9b:1::/48` (RFC 8215). `isPrivate()`, `isLoopback()`, `isLinkLocal()` and their siblings all return `false` for every address in it, so an internal IPv4 destination written through a local-use NAT64 prefix (`64:ff9b:1:7f00:0:100::` for `127.0.0.1`, `64:ff9b:1:a9fe:a9:fe00::` for `169.254.169.254`) reads as an ordinary global address. `getType()` names the range `'NAT64 (local-use)'`, so the library knows what the address is and classifies it as nothing. An application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) will classify an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint. ### Details The fix for GHSA-22jq-vg5j-6vgg (10.2.1) classifies IPv4-mapped (`::ffff:0:0/96`) and NAT64 well-known (`64:ff9b::/96`) addresses by their embedded IPv4 address: `embeddedIPv4()` in `src/ipv6.ts` decodes the trailing 32 bits and every special-use classifier delegates to the resulting `Address4`. Those are the only two ranges `embeddedIPv4()` handles. The local-use range differs in kind from the well-known prefix, which is why extending the decoder does not fix it. RFC 8215 reserves `64:ff9b:1::/48` so an operator can carve their own NAT64 prefix out of it, of any length RFC 6052 allows (`/48`, `/56`, `/64`, or `/96`). Where the IPv4 address sits depends on that choice: `127.0.0.1` is `64:ff9b:1:7f00:0:100::` under a `/48` prefix and `64:ff9b:1::7f00:1` under a `/96` prefix, and each of those decodes to a different address under the other prefix length. There is no single embedded IPv4 address for the library to classify by. What is well-defined is the range as a whole. The IANA IPv6 Special-Purpose Address Registry lists `64:ff9b:1::/48` as not globally reachable, and Python's `ipaddress` module reports `is_private` as `True` and `is_global` as `False` for every address in it. `isPrivate()` covered ULA (`fc00::/7`) plus the decoded mapped and well-known cases, and nothing in the local-use range. ### Affected versions `>= 10.2.0, <= 10.5.0`. The `is*` classification API was extended to `Address6` in 10.2.0; releases before it do not expose the method and are not affected through this vector. ### Impact Every address in `64:ff9b:1::/48` parses successfully, `isValid()` is `true`, and no classifier catches it. Which internal target is reached depends on the NAT64 prefix deployed on the server's network; the well-known prefix column is the patched control from GHSA-22jq-vg5j-6vgg. | Internal target | Well-known form | Classified | Local-use form (`/48` prefix) | Classified | |---|---|---|---|---| | `127.0.0.1` | `64:ff9b::7f00:1` | loopback | `64:ff9b:1:7f00:0:100::` | nothing | | `10.0.0.1` | `64:ff9b::a00:1` | private | `64:ff9b:1:a00:0:100::` | nothing | | `169.254.169.254` | `64:ff9b::a9fe:a9fe` | link-local | `64:ff9b:1:a9fe:a9:fe00::` | nothing | | `192.168.1.1` | `64:ff9b::c0a8:101` | private | `64:ff9b:1:c0a8:1:100::` | nothing | ### Reachability Reaching an internal host through one of these addresses requires that the server's network run a NAT64 translator on a prefix inside `64:ff9b:1::/48` and that the attacker guess or know the prefix length. That is the same precondition the well-known prefix carries (a translator on `64:ff9b::/96`), with the additional constraint that the prefix is operator-chosen rather than fixed. The severity reflects that precondition. ### Proof of concept `npm i [email protected]`, then: ```js const { Address6 } = require('ip-address'); // A guard of the shape the library documents. function isBlocked(host) { const a = new Address6(host); return a.isLoopback() || a.isLinkLocal() || a.isPrivate() || a.isMulticast() || a.isUnspecified(); } for (const h of ['64:ff9b::7f00:1', '64:ff9b:1:7f00:0:100::', '64:ff9b:1::7f00:1']) { console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-> getType()', new Address6(h).getType()); } ``` On affected versions: ``` BLOCK 64:ff9b::7f00:1 -> getType() NAT64 (well-known) ALLOW 64:ff9b:1:7f00:0:100:: -> getType() NAT64 (local-use) ALLOW 64:ff9b:1::7f00:1 -> getType() NAT64 (local-use) ``` ### Remediation Upgrade to the patched release. In the fix, `isPrivate()` returns `true` for every address in `64:ff9b:1::/48`, alongside ULA and the decoded mapped and well-known cases. The range is reported private as a whole rather than by a decoded IPv4 address, for the reason given above; `toAddress4Nat64(prefix)` remains the way to decode an address under a known deployment prefix. `isLoopback()` and `isLinkLocal()` are unchanged for this range, since without the prefix length the library cannot know which IPv4 address is embedded. If you cannot upgrade immediat
CVSS v4.0
Score 6.9medium
Affected software
beaugunderson
ip-address
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The ip-address library for IPv4 and IPv6 parsing in JavaScript versions >=10.2.0 and <10.5.1 contains a SSRF vulnerability due to the Address6 isPrivate classifier not recognizing the NAT64 local-use range 64:ff9b:1::/48. Applications that use combined checks of isPrivate, isLoopback, and isLinkLocal for trust boundary decisions may incorrectly classify internal IPv4 destinations encoded via this NAT64 range as external. Exploitation requires a server network using an operator-selected NAT64 prefix within this local-use range, enabling a potential bypass of intended network trust boundaries. This issue is resolved in version 10.5.1.
Potential Impact
This vulnerability can allow an attacker to bypass network trust boundaries by exploiting misclassification of internal IPv4 addresses encoded in the NAT64 local-use range as external. This could lead to unauthorized access or interaction with internal network resources that are otherwise protected by trust boundary checks. The impact is limited to environments using the affected ip-address library versions and operator-selected NAT64 prefixes within the specified range.
Mitigation Recommendations
Upgrade the ip-address library to version 10.5.1 or later, where the issue is fixed. No other mitigation is indicated by the vendor advisory. Patch status is confirmed fixed in 10.5.1.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-09-28T15:55:37.907Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6abaabe3f7a7c54106053eb9
Added to database: 09/28/2026, 18:03:15 UTC
Last enriched: 09/28/2026, 18:18:03 UTC
Last updated: 09/29/2026, 04:46:15 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.