{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-101910", "tracking": { "current_release_date": "2026-09-30T01:20:01.668875Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-101910", "initial_release_date": "2026-09-28T18:26:53.362601Z", "revision_history": [ { "date": "2026-09-28T18:26:53.362601Z", "number": "1", "summary": "NCSC Score created." }, { "date": "2026-09-28T18:29:04.329461Z", "number": "2", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)." }, { "date": "2026-09-28T18:29:06.286177Z", "number": "3", "summary": "NCSC Score updated." }, { "date": "2026-09-28T18:38:27.502936Z", "number": "4", "summary": "CVSS created.| CWES created (1).| Unknown change.| Products created (1).| References created (3).| Description created for source.| Unknown change." }, { "date": "2026-09-28T18:38:35.227466Z", "number": "5", "summary": "NCSC Score updated." }, { "date": "2026-09-28T21:40:05.305541Z", "number": "6", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (5).| CWES updated (1)." }, { "date": "2026-09-28T21:40:08.462576Z", "number": "7", "summary": "NCSC Score updated." }, { "date": "2026-09-29T00:21:08.867947Z", "number": "8", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (1).| References created (4).| CWES updated (1)." }, { "date": "2026-09-29T00:45:03.516980Z", "number": "9", "summary": "Source created.| CVE status created. (valid)| Products connected (1)." }, { "date": "2026-09-29T00:45:13.721389Z", "number": "10", "summary": "NCSC Score updated." }, { "date": "2026-09-29T06:12:31.088170Z", "number": "11", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (3).| Products connected (4).| References created (5).| CWES updated (1)." }, { "date": "2026-09-29T06:43:53.661467Z", "number": "12", "summary": "Description created for source." }, { "date": "2026-09-29T12:29:27.378952Z", "number": "13", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (4).| Product Identifiers created (1).| References created (5).| CWES updated (1).| Vendor_assessment created." }, { "date": "2026-09-29T12:29:31.517376Z", "number": "14", "summary": "NCSC Score updated." }, { "date": "2026-09-29T16:12:56.221559Z", "number": "15", "summary": "EPSS created.| Unknown change." }, { "date": "2026-09-29T18:31:45.833783Z", "number": "16", "summary": "NCSC Score updated." } ], "status": "interim", "version": "16" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:rpm/1", "product": { "name": "vers:rpm/1", "product_id": "CSAFPID-6014972", "product_identification_helper": { "cpe": "cpe:/a:redhat:hummingbird:1" } } } ], "category": "product_name", "name": "Red Hat Hardened Images" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-8902830" } } ], "category": "product_name", "name": "grafana12.4" }, { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-8902831" } } ], "category": "product_name", "name": "grafana13.1" }, { "branches": [ { "category": "product_version_range", "name": "vers:rpm/unknown", "product": { "name": "vers:rpm/unknown", "product_id": "CSAFPID-9053231" } } ], "category": "product_name", "name": "grafana13.2" } ], "category": "product_family", "name": "Red Hat Hardened Images" } ], "category": "vendor", "name": "Red Hat" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/>=10.2.0|<10.5.1", "product": { "name": "vers:unknown/>=10.2.0|<10.5.1", "product_id": "CSAFPID-9482857" } }, { "category": "product_version_range", "name": "vers:unknown/v10.2.0", "product": { "name": "vers:unknown/v10.2.0", "product_id": "CSAFPID-8923137" } }, { "category": "product_version_range", "name": "vers:unknown/v10.2.1", "product": { "name": "vers:unknown/v10.2.1", "product_id": "CSAFPID-8932681" } }, { "category": "product_version_range", "name": "vers:unknown/v10.2.2", "product": { "name": "vers:unknown/v10.2.2", "product_id": "CSAFPID-8932680" } }, { "category": "product_version_range", "name": "vers:unknown/v10.3.0", "product": { "name": "vers:unknown/v10.3.0", "product_id": "CSAFPID-8932679" } }, { "category": "product_version_range", "name": "vers:unknown/v10.3.1", "product": { "name": "vers:unknown/v10.3.1", "product_id": "CSAFPID-9485009" } }, { "category": "product_version_range", "name": "vers:unknown/v10.4.0", "product": { "name": "vers:unknown/v10.4.0", "product_id": "CSAFPID-9485008" } }, { "category": "product_version_range", "name": "vers:unknown/v10.5.0", "product": { "name": "vers:unknown/v10.5.0", "product_id": "CSAFPID-9485007" } } ], "category": "product_name", "name": "ip-address" } ], "category": "vendor", "name": "beaugunderson" }, { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:deb/unknown", "product": { "name": "vers:deb/unknown", "product_id": "CSAFPID-7088727" } } ], "category": "product_name", "name": "node-ip-address" } ], "category": "product_family", "name": "bookworm" } ], "category": "vendor", "name": "debian" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-101910", "cwe": { "id": "CWE-918", "name": "Server-Side Request Forgery (SSRF)" }, "notes": [ { "category": "description", "text": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.", "title": "nvd - https://nvd.nist.gov/vuln/detail/CVE-2026-101910" }, { "category": "description", "text": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.", "title": "cveprojectv5 - https://www.cve.org/CVERecord?id=CVE-2026-101910" }, { "category": "description", "text": "### Summary\n\nNo 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.\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 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.\n\n### Details\n\nThe 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.\n\nThe 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.\n\nWhat 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.\n\n### Affected versions\n\n`>= 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.\n\n### Impact\n\nEvery 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.\n\n| Internal target | Well-known form | Classified | Local-use form (`/48` prefix) | Classified |\n|---|---|---|---|---|\n| `127.0.0.1` | `64:ff9b::7f00:1` | loopback | `64:ff9b:1:7f00:0:100::` | nothing |\n| `10.0.0.1` | `64:ff9b::a00:1` | private | `64:ff9b:1:a00:0:100::` | nothing |\n| `169.254.169.254` | `64:ff9b::a9fe:a9fe` | link-local | `64:ff9b:1:a9fe:a9:fe00::` | nothing |\n| `192.168.1.1` | `64:ff9b::c0a8:101` | private | `64:ff9b:1:c0a8:1:100::` | nothing |\n\n### Reachability\n\nReaching 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.\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 ['64:ff9b::7f00:1', '64:ff9b:1:7f00:0:100::', '64:ff9b:1::7f00:1']) {\n console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-> getType()', new Address6(h).getType());\n}\n```\n\nOn affected versions:\n\n```\nBLOCK 64:ff9b::7f00:1 -> getType() NAT64 (well-known)\nALLOW 64:ff9b:1:7f00:0:100:: -> getType() NAT64 (local-use)\nALLOW 64:ff9b:1::7f00:1 -> getType() NAT64 (local-use)\n```\n\n### Remediation\n\nUpgrade 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.\n\nIf you cannot upgrade immediately, test the range directly:\n\n```js\nconst NAT64_LOCAL_USE = new Address6('64:ff9b:1::/48');\nconst localUse = new Address6(host).isHostInSubnet(NAT64_LOCAL_USE);\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.", "title": "github - https://github.com/advisories/GHSA-2vr4-cq9g-pvrc" }, { "category": "description", "text": "### Summary\n\nNo 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.\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 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.\n\n### Details\n\nThe 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.\n\nThe 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.\n\nWhat 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.\n\n### Affected versions\n\n`>= 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.\n\n### Impact\n\nEvery 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.\n\n| Internal target | Well-known form | Classified | Local-use form (`/48` prefix) | Classified |\n|---|---|---|---|---|\n| `127.0.0.1` | `64:ff9b::7f00:1` | loopback | `64:ff9b:1:7f00:0:100::` | nothing |\n| `10.0.0.1` | `64:ff9b::a00:1` | private | `64:ff9b:1:a00:0:100::` | nothing |\n| `169.254.169.254` | `64:ff9b::a9fe:a9fe` | link-local | `64:ff9b:1:a9fe:a9:fe00::` | nothing |\n| `192.168.1.1` | `64:ff9b::c0a8:101` | private | `64:ff9b:1:c0a8:1:100::` | nothing |\n\n### Reachability\n\nReaching 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.\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 ['64:ff9b::7f00:1', '64:ff9b:1:7f00:0:100::', '64:ff9b:1::7f00:1']) {\n console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-> getType()', new Address6(h).getType());\n}\n```\n\nOn affected versions:\n\n```\nBLOCK 64:ff9b::7f00:1 -> getType() NAT64 (well-known)\nALLOW 64:ff9b:1:7f00:0:100:: -> getType() NAT64 (local-use)\nALLOW 64:ff9b:1::7f00:1 -> getType() NAT64 (local-use)\n```\n\n### Remediation\n\nUpgrade 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.\n\nIf you cannot upgrade immediately, test the range directly:\n\n```js\nconst NAT64_LOCAL_USE = new Address6('64:ff9b:1::/48');\nconst localUse = new Address6(host).isHostInSubnet(NAT64_LOCAL_USE);\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.", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-2vr4-cq9g-pvrc.json?alt=media" }, { "category": "description", "text": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-101910.json?alt=media" }, { "category": "description", "text": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.2.0 until 10.5.1, the Address6 isPrivate classifier in src/ipv6.ts does not recognize the NAT64 local-use range 64:ff9b:1::/48. Applications that combine isPrivate, isLoopback, and isLinkLocal for a trust-boundary decision can treat an internal IPv4 destination encoded through that range as external. Exploitation depends on a server network using an operator-selected NAT64 prefix within the local-use range. A successful bypass can cross the intended network trust boundary. This issue is fixed in version 10.5.1.", "title": "debian - https://security-tracker.debian.org/tracker/CVE-2026-101910" }, { "category": "description", "text": "A flaw was found in ip-address. The address classification mechanism fails to identify the local-use Network Address Translation (NAT64) range as private. A remote attacker can exploit this by submitting an internal address formatted within this IPv6 prefix to an application that relies on the library to enforce network boundaries. Successful exploitation allows an attacker to bypass network access controls, potentially resulting in Server-Side Request Forgery (SSRF) and unauthorized access to restricted internal services.", "title": "redhat - https://access.redhat.com/security/cve/CVE-2026-101910" }, { "category": "other", "text": "0.00386", "title": "EPSS" }, { "category": "other", "text": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/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", "title": "CVSSV4" }, { "category": "other", "text": "6.9", "title": "CVSSV4 base score" }, { "category": "other", "text": "4.3", "title": "NCSC Score" }, { "category": "other", "text": "There is cwe data available from source Nvd, Is related to (a version of) an uncommon product", "title": "NCSC Score top decreasing factors" }, { "category": "details", "text": "Severity: 2\n", "title": "Vendor assessment" } ], "product_status": { "known_affected": [ "CSAFPID-9482857", "CSAFPID-7088727", "CSAFPID-8923137", "CSAFPID-8932679", "CSAFPID-8932680", "CSAFPID-8932681", "CSAFPID-9485007", "CSAFPID-9485008", "CSAFPID-9485009", "CSAFPID-6014972", "CSAFPID-8902830", "CSAFPID-8902831", "CSAFPID-9053231" ] }, "references": [ { "category": "external", "summary": "Source - nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101910" }, { "category": "external", "summary": "Source - ncscclear", "url": "https://vulnerabilities.ncsc.nl/manual/CVE-2026-101910" }, { "category": "external", "summary": "Source - cveprojectv5", "url": "https://www.cve.org/CVERecord?id=CVE-2026-101910" }, { "category": "external", "summary": "Source - github", "url": "https://github.com/advisories/GHSA-2vr4-cq9g-pvrc" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-2vr4-cq9g-pvrc.json?alt=media" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-101910.json?alt=media" }, { "category": "external", "summary": "Source - debian", "url": "https://security-tracker.debian.org/tracker/CVE-2026-101910" }, { "category": "external", "summary": "Source - redhat", "url": "https://access.redhat.com/security/cve/CVE-2026-101910" }, { "category": "external", "summary": "Source - first", "url": "https://api.first.org/data/v1/epss" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/beaugunderson/ip-address/commit/ab3dc88bcf5374344168a2ba075ca7ac4ff257f8" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.5.1" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv; redhat", "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-2vr4-cq9g-pvrc" }, { "category": "external", "summary": "Reference - github", "url": "https://github.com/advisories/GHSA-2vr4-cq9g-pvrc" }, { "category": "external", "summary": "Reference - github; osv; redhat", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101910" }, { "category": "external", "summary": "Reference - osv", "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/101xxx/CVE-2026-101910.json" }, { "category": "external", "summary": "Reference - redhat", "url": "https://www.cve.org/CVERecord?id=CVE-2026-101910" } ], "scores": [ { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "baseScore": 5.3, "baseSeverity": "MEDIUM" }, "products": [ "CSAFPID-6014972", "CSAFPID-7088727", "CSAFPID-8902830", "CSAFPID-8902831", "CSAFPID-8923137", "CSAFPID-8932679", "CSAFPID-8932680", "CSAFPID-8932681", "CSAFPID-9053231", "CSAFPID-9482857", "CSAFPID-9485007", "CSAFPID-9485008", "CSAFPID-9485009" ] } ], "title": "CVE-2026-101910" } ] }