{"id":"CVE-2026-101913","aliases":["CLSA-2026-1790676837","CLSA-2026-1790677530","CLSA-2026-1792233491","CLSA-2026-1792369098","CLSA-2026-1792451467","CLSA-2026-1792476227","DEBIAN-CVE-2026-101913","EUVD-2026-88399","GHSA-22jq-vg5j-6vgg","GHSA-mwp4-54f8-5fhr","GHSA-rpw4-54j3-4h4q","UBUNTU-CVE-2026-101913"],"status":"published","title":"ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","severity":{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00386,"percentile":0.32998,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-697","CWE-918"],"published":"2026-09-28T17:49:02Z","modified":"2026-10-28T02:30:45Z","fixes":[{"ecosystem":"npm","package":"ip-address","fixed_in":["10.5.1"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"ip-address","fixed_in":["6.4.0-tuxcare.4","7.1.0-tuxcare.2"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"node-ip-address","fixed_in":["10.7.2-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"10.5.0"},{"fixed":"10.5.1"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.4.0-tuxcare.0"},{"fixed":"6.4.0-tuxcare.4"}]}],"versions":["6.4.0","6.4.0-tuxcare.1","6.4.0-tuxcare.2","6.4.0-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"7.1.0-tuxcare.0"},{"fixed":"7.1.0-tuxcare.2"}]}],"versions":["7.1.0","7.1.0-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"9.0.5-tuxcare.0"},{"fixed":"9.0.5-tuxcare.3"}]}],"versions":["9.0.5","9.0.5-tuxcare.1","9.0.5-tuxcare.2"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"10.5.0-tuxcare.0"},{"fixed":"10.5.0-tuxcare.1"}]}],"versions":["10.5.0"],"bundled":4},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"10.1.1-tuxcare.0"},{"fixed":"10.1.1-tuxcare.1"}]}],"versions":["10.1.1"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:npm","package":"ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"10.1.0-tuxcare.0"},{"fixed":"10.1.0-tuxcare.1"}]}],"versions":["10.1.0"],"bundled":5},{"source":"osv","ecosystem":"Debian:12","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10.2.0-1","10.2.0-2","10.3.1-1","10.4.0-1","10.7.2-1","8.1.0-2","8.1.0-3"]},{"source":"osv","ecosystem":"Debian:13","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10.2.0-1","10.2.0-2","10.3.1-1","10.4.0-1","10.7.2-1","8.1.0-2","8.1.0-3"]},{"source":"osv","ecosystem":"Debian:14","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.7.2-1"}]}],"versions":["10.2.0-1","10.2.0-2","10.3.1-1","10.4.0-1","8.1.0-2","8.1.0-3"]},{"source":"osv","ecosystem":"npm","package":"ip-address","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"10.5.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.3.0-1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.4.0-1","8.1.0-2"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["8.1.0-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["8.1.0-3","10.2.0-2","10.3.1-1","10.4.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"node-ip-address","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["8.1.0-2","8.1.0-3"]}],"products":[{"vendor":"beaugunderson","product":"ip-address"}],"references":[{"url":"https://github.com/beaugunderson/ip-address/security/advisories/GHSA-rpw4-54j3-4h4q","tags":["x_refsource_CONFIRM","exploit","advisory","web","report"]},{"url":"https://github.com/beaugunderson/ip-address/commit/d03e960c7cc3179ef25c8a44b4f94dd499625546","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/beaugunderson/ip-address/releases/tag/v10.5.1","tags":["x_refsource_MISC","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-101913","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-rpw4-54j3-4h4q"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/101xxx/CVE-2026-101913.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-101913","tags":["advisory"]},{"url":"https://github.com/beaugunderson/ip-address","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-101913","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-101913","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-101913","title":"ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T17:49:02.657Z","modified":"2026-09-28T18:38:42.684Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-697","CWE-918"],"updated_at":"2026-11-02T14:20:09.808851Z"}],"euvd":[{"id":"EUVD-2026-88399","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T17:49:02Z","modified":"2026-09-28T18:38:42Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T17:27:52.759804Z"}],"ghsa":[{"id":"GHSA-rpw4-54j3-4h4q","title":"ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts","description":"### Summary\n\n`Address6.isLinkLocal()` recognizes `fe80::/64` rather than `fe80::/10`. Link-local unicast is the whole `/10` under RFC 4291 §2.4 and the IANA IPv6 Special-Purpose Address Registry, so the method returns `false` for every link-local address outside the one `/64` that stateless address autoconfiguration happens to use. `new Address6('fe81::1').isLinkLocal()` is `false`.\n\nThe library contradicts itself on the same object: for `fe81::1`, `getType()` returns `'Link-local unicast'`, `getScope()` returns `'Link local'`, and `isHostInSubnet(new Address6('fe80::/10'))` returns `true`, while `isLinkLocal()` returns `false`.\n\nAn 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 a link-local target as unremarkable 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.\n\n### Details\n\n`isLinkLocal()` in `src/ipv6.ts` compares the first 64 bits of the address against a literal string:\n\n```ts\n// Zeroes are required, i.e. we can't check isHostInSubnet with 'fe80::/10'\nif (\n  this.getBitsBase2(0, 64) ===\n  '1111111010000000000000000000000000000000000000000000000000000000'\n) {\n  return true;\n}\n```\n\nThe comparison requires the first 64 bits to be exactly `fe80:0000:0000:0000`, so it accepts 2⁶⁴ of the 2¹¹⁸ addresses in `fe80::/10`. The comment states a premise the library disproves: `getType()` classifies the same range with `isHostInSubnet` against the `'fe80::/10': 'Link-local unicast'` entry in `src/v6/constants.ts`, and `Address4.isLinkLocal()` is a plain `isHostInSubnet` test against `169.254.0.0/16`. RFC 4291 §2.5.6 constrains the format of an autoconfigured link-local address; it does not define the range, and reading it as the definition is the likeliest origin of the `/64` comparison.\n\nThe IPv4-mapped and NAT64 well-known paths of `isLinkLocal()` are unaffected: `::ffff:169.254.169.254` and `64:ff9b::a9fe:a9fe` are classified by their embedded IPv4 address and report `true`.\n\n### Affected versions\n\n`\u003c= 10.5.0`. The comparison has had this shape since `Address6.isLinkLocal()` was introduced, so every release exposing the method is affected.\n\n### Impact\n\nEvery well-formed address in `fe80::/10` outside `fe80::/64` is parsed successfully, `isValid()` is `true`, and the classifier reports something untrue about it. No other classifier catches these addresses: `isPrivate()` covers ULA (`fc00::/7`), not link-local.\n\n| Address | `isLinkLocal()` | `getType()` | `getScope()` |\n|---|---|---|---|\n| `fe80::1` | `true` | Link-local unicast | Link local |\n| `fe81::1` | `false` | Link-local unicast | Link local |\n| `fe8f::1` | `false` | Link-local unicast | Link local |\n| `febf::1` | `false` | Link-local unicast | Link local |\n| `fe80:0:0:1::1` | `false` | Link-local unicast | Link local |\n| `fe80::1:0:0:0:1` | `false` | Link-local unicast | Link local |\n\nPython's `ipaddress` module, the `IN6_IS_ADDR_LINKLOCAL` macro in `netinet6/in6.h`, and Linux's `ipv6_addr_type()` all apply a ten-bit prefix test and classify every row above as link-local.\n\nA request admitted through a guard built on `isLinkLocal()` reaches a link-local host on the server's own segment: a neighboring machine or the on-link router. An IPv6 link-local destination generally needs a zone index and a neighbor on the same link, so the reach is the server's own segment rather than the internet or a universal metadata endpoint, and the severity reflects that.\n\n### Proof of concept\n\n`npm i ip-address@10.5.0`, then:\n\n```js\nconst { Address6 } = require('ip-address');\n\n// A guard of the shape the library documents.\nfunction isBlocked(host) {\n  const a = new Address6(host);\n  return a.isLoopback() || a.isLinkLocal() || a.isPrivate() || a.isMulticast() || a.isUnspecified();\n}\n\nfor (const h of ['fe80::1', 'fe81::1', 'febf::1', 'fe80:0:0:1::1']) {\n  const a = new Address6(h);\n  console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-\u003e getType()', a.getType());\n}\n```\n\nOn affected versions:\n\n```\nBLOCK fe80::1 -\u003e getType() Link-local unicast\nALLOW fe81::1 -\u003e getType() Link-local unicast\nALLOW febf::1 -\u003e getType() Link-local unicast\nALLOW fe80:0:0:1::1 -\u003e getType() Link-local unicast\n```\n\n### Remediation\n\nUpgrade to the patched release. In the fix, `isLinkLocal()` tests the address against `fe80::/10` with the same `isHostInSubnet` predicate `getType()` and `Address4.isLinkLocal()` use. The same release adds `2001::/32` to the type table so `getType()` reports `'Teredo'` for the addresses `isTeredo()` returns `true` for; that is a consistency correction with no security effect.\n\nIf you cannot upgrade immediately, test the range directly:\n\n```js\nconst LINK_LOCAL = new Address6('fe80::/10');\nconst linkLocal = new Address6(host).isHostInSubnet(LINK_LOCAL);\n```\n\n### A note on SSRF defense\n\nThese methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the *resolved* IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.","status":"published","published":"2026-09-28T20:43:55Z","modified":"2026-09-28T20:43:57Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium"}],"cwes":["CWE-697","CWE-918"],"updated_at":"2026-11-02T14:41:22.654187Z"}],"nvd":[{"id":"CVE-2026-101913","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T18:17:21.237Z","modified":"2026-09-30T19:57:08.043Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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","level":"medium","assessor":"secondary"}],"cwes":["CWE-697","CWE-918"],"updated_at":"2026-11-02T14:12:52.081323Z"}],"osv":[{"id":"CVE-2026-101913","title":"ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T17:49:02.657Z","modified":"2026-10-28T02:30:45.610733632Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium"}],"cwes":["CWE-697","CWE-918"],"updated_at":"2026-11-02T15:44:53.83521Z"},{"id":"DEBIAN-CVE-2026-101913","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T18:17:21.237Z","modified":"2026-10-01T08:47:28.827303304Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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","level":"medium"}],"updated_at":"2026-11-02T15:45:48.440897Z"},{"id":"GHSA-rpw4-54j3-4h4q","title":"ip-address: Address6.isLinkLocal() recognizes fe80::/64 rather than fe80::/10, allowing SSRF and trust-boundary bypass to on-link hosts","description":"### Summary\n\n`Address6.isLinkLocal()` recognizes `fe80::/64` rather than `fe80::/10`. Link-local unicast is the whole `/10` under RFC 4291 §2.4 and the IANA IPv6 Special-Purpose Address Registry, so the method returns `false` for every link-local address outside the one `/64` that stateless address autoconfiguration happens to use. `new Address6('fe81::1').isLinkLocal()` is `false`.\n\nThe library contradicts itself on the same object: for `fe81::1`, `getType()` returns `'Link-local unicast'`, `getScope()` returns `'Link local'`, and `isHostInSubnet(new Address6('fe80::/10'))` returns `true`, while `isLinkLocal()` returns `false`.\n\nAn 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 a link-local target as unremarkable 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.\n\n### Details\n\n`isLinkLocal()` in `src/ipv6.ts` compares the first 64 bits of the address against a literal string:\n\n```ts\n// Zeroes are required, i.e. we can't check isHostInSubnet with 'fe80::/10'\nif (\n  this.getBitsBase2(0, 64) ===\n  '1111111010000000000000000000000000000000000000000000000000000000'\n) {\n  return true;\n}\n```\n\nThe comparison requires the first 64 bits to be exactly `fe80:0000:0000:0000`, so it accepts 2⁶⁴ of the 2¹¹⁸ addresses in `fe80::/10`. The comment states a premise the library disproves: `getType()` classifies the same range with `isHostInSubnet` against the `'fe80::/10': 'Link-local unicast'` entry in `src/v6/constants.ts`, and `Address4.isLinkLocal()` is a plain `isHostInSubnet` test against `169.254.0.0/16`. RFC 4291 §2.5.6 constrains the format of an autoconfigured link-local address; it does not define the range, and reading it as the definition is the likeliest origin of the `/64` comparison.\n\nThe IPv4-mapped and NAT64 well-known paths of `isLinkLocal()` are unaffected: `::ffff:169.254.169.254` and `64:ff9b::a9fe:a9fe` are classified by their embedded IPv4 address and report `true`.\n\n### Affected versions\n\n`\u003c= 10.5.0`. The comparison has had this shape since `Address6.isLinkLocal()` was introduced, so every release exposing the method is affected.\n\n### Impact\n\nEvery well-formed address in `fe80::/10` outside `fe80::/64` is parsed successfully, `isValid()` is `true`, and the classifier reports something untrue about it. No other classifier catches these addresses: `isPrivate()` covers ULA (`fc00::/7`), not link-local.\n\n| Address | `isLinkLocal()` | `getType()` | `getScope()` |\n|---|---|---|---|\n| `fe80::1` | `true` | Link-local unicast | Link local |\n| `fe81::1` | `false` | Link-local unicast | Link local |\n| `fe8f::1` | `false` | Link-local unicast | Link local |\n| `febf::1` | `false` | Link-local unicast | Link local |\n| `fe80:0:0:1::1` | `false` | Link-local unicast | Link local |\n| `fe80::1:0:0:0:1` | `false` | Link-local unicast | Link local |\n\nPython's `ipaddress` module, the `IN6_IS_ADDR_LINKLOCAL` macro in `netinet6/in6.h`, and Linux's `ipv6_addr_type()` all apply a ten-bit prefix test and classify every row above as link-local.\n\nA request admitted through a guard built on `isLinkLocal()` reaches a link-local host on the server's own segment: a neighboring machine or the on-link router. An IPv6 link-local destination generally needs a zone index and a neighbor on the same link, so the reach is the server's own segment rather than the internet or a universal metadata endpoint, and the severity reflects that.\n\n### Proof of concept\n\n`npm i ip-address@10.5.0`, then:\n\n```js\nconst { Address6 } = require('ip-address');\n\n// A guard of the shape the library documents.\nfunction isBlocked(host) {\n  const a = new Address6(host);\n  return a.isLoopback() || a.isLinkLocal() || a.isPrivate() || a.isMulticast() || a.isUnspecified();\n}\n\nfor (const h of ['fe80::1', 'fe81::1', 'febf::1', 'fe80:0:0:1::1']) {\n  const a = new Address6(h);\n  console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-\u003e getType()', a.getType());\n}\n```\n\nOn affected versions:\n\n```\nBLOCK fe80::1 -\u003e getType() Link-local unicast\nALLOW fe81::1 -\u003e getType() Link-local unicast\nALLOW febf::1 -\u003e getType() Link-local unicast\nALLOW fe80:0:0:1::1 -\u003e getType() Link-local unicast\n```\n\n### Remediation\n\nUpgrade to the patched release. In the fix, `isLinkLocal()` tests the address against `fe80::/10` with the same `isHostInSubnet` predicate `getType()` and `Address4.isLinkLocal()` use. The same release adds `2001::/32` to the type table so `getType()` reports `'Teredo'` for the addresses `isTeredo()` returns `true` for; that is a consistency correction with no security effect.\n\nIf you cannot upgrade immediately, test the range directly:\n\n```js\nconst LINK_LOCAL = new Address6('fe80::/10');\nconst linkLocal = new Address6(host).isHostInSubnet(LINK_LOCAL);\n```\n\n### A note on SSRF defense\n\nThese methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the *resolved* IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.","status":"published","published":"2026-09-28T20:43:55Z","modified":"2026-09-28T21:00:05.359993143Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium"}],"cwes":["CWE-697","CWE-918"],"updated_at":"2026-11-02T15:46:56.281047Z"},{"id":"UBUNTU-CVE-2026-101913","description":"ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.5.1, the Address6 isLinkLocal method in src/ipv6.ts recognizes only fe80::/64 instead of the complete fe80::/10 IPv6 link-local range. An attacker-controlled address elsewhere in fe80::/10 can therefore pass a trust-boundary check that relies on isLinkLocal. The same address is identified as link-local by getType and getScope, exposing the inconsistent classification. A successful bypass can reach an on-link host outside the intended trust boundary. This issue is fixed in version 10.5.1.","status":"published","published":"2026-09-28T18:17:00Z","modified":"2026-10-17T12:57:55.357352202Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:55:58.519486Z"},{"id":"CLSA-2026-1790676837","title":"TuxCare security update for ip-address (1 CVE)","description":"TuxCare rebuilt ip-address to address 1 CVE. Fixed in 6.4.0-tuxcare.4.","status":"published","published":"2026-09-29T10:13:57Z","modified":"2026-10-15T09:47:38.431892328Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1790677530","title":"TuxCare security update for ip-address (1 CVE)","description":"TuxCare rebuilt ip-address to address 1 CVE. Fixed in 7.1.0-tuxcare.2.","status":"published","published":"2026-09-29T10:25:30Z","modified":"2026-10-15T09:47:47.963549863Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1792233491","title":"TuxCare security update for ip-address (3 CVEs)","description":"TuxCare rebuilt ip-address to address 3 CVEs. Fixed in 9.0.5-tuxcare.3.","status":"published","published":"2026-10-17T10:38:11Z","modified":"2026-10-17T13:09:29.518107714Z","updated_at":"2026-11-02T15:43:52.011757Z"},{"id":"CLSA-2026-1792369098","title":"TuxCare security update for ip-address (4 CVEs)","description":"TuxCare rebuilt ip-address to address 4 CVEs. Fixed in 10.5.0-tuxcare.1.","status":"published","published":"2026-10-19T00:18:18Z","modified":"2026-10-19T07:46:22.332492587Z","updated_at":"2026-11-02T15:43:53.353888Z"},{"id":"CLSA-2026-1792451467","title":"TuxCare security update for ip-address (6 CVEs)","description":"TuxCare rebuilt ip-address to address 6 CVEs. Fixed in 10.1.1-tuxcare.1.","status":"published","published":"2026-10-19T23:11:07Z","modified":"2026-10-20T01:45:10.154846379Z","updated_at":"2026-11-02T15:43:54.378946Z"},{"id":"CLSA-2026-1792476227","title":"TuxCare security update for ip-address (7 CVEs)","description":"TuxCare rebuilt ip-address to address 7 CVEs. Fixed in 10.1.0-tuxcare.1.","status":"published","published":"2026-10-20T06:03:47Z","modified":"2026-10-20T07:15:15.381040519Z","updated_at":"2026-11-02T15:43:54.378946Z"}]}}