CVE-2026-69198
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
6.9
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
CVE-2026-69198- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-20, CWE-918
- Updated
- 2026-11-02
EUVDEUVD-2026-52422
6.9
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
EUVD-2026-52422- CVSS 4.0
- 6.9 Medium
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 - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-4xrf-jv44-h6hh
6.9
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
Summary
Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target.
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) may therefore treat 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
isInSubnet in src/common.ts opens with a guard that compares the two prefix lengths:
export function isInSubnet(this, address) {
if (this.subnetMask < address.subnetMask) {
return false; // <-- reached before any bit comparison
}
if (this.mask(address.subnetMask) === address.mask()) {
return true;
}
return false;
}
That guard is correct for the question isInSubnet is named for — whether one network is contained in another, where a /0 network genuinely is not inside a /8. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. /0 is shorter than every reference prefix in the special-use tables (loopback /8, link-local /16, CGNAT /10, ULA /7, multicast /4), so for a classification call the bit comparison is never reached and the method returns false.
The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask — the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so correctForm() still yields the real target and the address remains fully usable for connecting.
/0 is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: 10.0.0.5/7 defeats isPrivate() for 10.0.0.0/8.
Affected versions
>= 10.1.1, <= 10.2.1. The is* classification API was introduced for Address4 in 10.1.1 and extended to Address6 in 10.2.0; releases before 10.1.1 do not expose it and are not affected through this vector. The containment guard itself is much older, but isInSubnet alone is a subnet-containment predicate whose behavior here is correct.
This also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through isInSubnet, so ::ffff:127.0.0.1/0 reverts to being reported as non-internal.
Impact
Every classifier is affected on both Address4 and Address6. The sole exception is Address6.isLinkLocal() for native fe80::/10 addresses, which compares raw bits directly; its IPv4-mapped path is still affected.
| Address | Reported as | Actually points at |
|---|---|---|
| 127.0.0.1/0 | not loopback | loopback (127.0.0.0/8) |
| 10.0.0.1/0, 10.0.0.5/7 | not private | RFC 1918 10/8 |
| 172.16.5.5/0 | not private | RFC 1918 172.16/12 |
| 192.168.1.1/0 | not private | RFC 1918 192.168/16 |
| 169.254.169.254/0 | not link-local | link-local / cloud metadata (IMDS) |
| 100.64.0.1/0 | not CGNAT | CGNAT 100.64/10 |
| 0.0.0.0/0, 255.255.255.255/0 | not unspecified / not broadcast | unspecified / broadcast |
| ::1/0…
- Record
GHSA-4xrf-jv44-h6hh- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-20, CWE-918
- Updated
- 2026-11-02
NVD
6.9
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
CVE-2026-69198- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-20, CWE-918
- Updated
- 2026-11-02
OSV
6.9
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
CVE-2026-69198- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-20, CWE-918
- Updated
- 2026-11-02
OSVDEBIAN-CVE-2026-69198
6.9
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
DEBIAN-CVE-2026-69198- CVSS 4.0
- 6.9 Medium
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 - Updated
- 2026-11-02
Show 8 moreShow less
OSVGHSA-4xrf-jv44-h6hh
6.9
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
Summary
Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target.
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) may therefore treat 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
isInSubnet in src/common.ts opens with a guard that compares the two prefix lengths:
export function isInSubnet(this, address) {
if (this.subnetMask < address.subnetMask) {
return false; // <-- reached before any bit comparison
}
if (this.mask(address.subnetMask) === address.mask()) {
return true;
}
return false;
}
That guard is correct for the question isInSubnet is named for — whether one network is contained in another, where a /0 network genuinely is not inside a /8. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. /0 is shorter than every reference prefix in the special-use tables (loopback /8, link-local /16, CGNAT /10, ULA /7, multicast /4), so for a classification call the bit comparison is never reached and the method returns false.
The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask — the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so correctForm() still yields the real target and the address remains fully usable for connecting.
/0 is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: 10.0.0.5/7 defeats isPrivate() for 10.0.0.0/8.
Affected versions
>= 10.1.1, <= 10.2.1. The is* classification API was introduced for Address4 in 10.1.1 and extended to Address6 in 10.2.0; releases before 10.1.1 do not expose it and are not affected through this vector. The containment guard itself is much older, but isInSubnet alone is a subnet-containment predicate whose behavior here is correct.
This also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through isInSubnet, so ::ffff:127.0.0.1/0 reverts to being reported as non-internal.
Impact
Every classifier is affected on both Address4 and Address6. The sole exception is Address6.isLinkLocal() for native fe80::/10 addresses, which compares raw bits directly; its IPv4-mapped path is still affected.
| Address | Reported as | Actually points at |
|---|---|---|
| 127.0.0.1/0 | not loopback | loopback (127.0.0.0/8) |
| 10.0.0.1/0, 10.0.0.5/7 | not private | RFC 1918 10/8 |
| 172.16.5.5/0 | not private | RFC 1918 172.16/12 |
| 192.168.1.1/0 | not private | RFC 1918 192.168/16 |
| 169.254.169.254/0 | not link-local | link-local / cloud metadata (IMDS) |
| 100.64.0.1/0 | not CGNAT | CGNAT 100.64/10 |
| 0.0.0.0/0, 255.255.255.255/0 | not unspecified / not broadcast | unspecified / broadcast |
| ::1/0…
- Record
GHSA-4xrf-jv44-h6hh- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-20, CWE-918
- Updated
- 2026-11-02
OSVRHSA-2026:49401
7.5
Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update
- Record
RHSA-2026:49401- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Updated
- 2026-11-02
OSVRHSA-2026:50826
8.6
Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update
- Record
RHSA-2026:50826- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-69198
6.9
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. 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, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
- Record
UBUNTU-CVE-2026-69198- CVSS 4.0
- 6.9 Medium
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 - Updated
- 2026-11-02
OSVCLSA-2026-1788790498 No score
TuxCare security update for ip-address (2 CVEs)
TuxCare rebuilt ip-address to address 2 CVEs. Fixed in 6.4.0-tuxcare.2.
- Record
CLSA-2026-1788790498- Updated
- 2026-11-02
OSVCLSA-2026-1790604982 No score
TuxCare security update for ip-address (2 CVEs)
TuxCare rebuilt ip-address to address 2 CVEs. Fixed in 7.1.0-tuxcare.1.
- Record
CLSA-2026-1790604982- Updated
- 2026-11-02
OSVCLSA-2026-1793097608 No score
TuxCare security update for ip-address (1 CVE)
TuxCare rebuilt ip-address to address 1 CVE. Fixed in 10.1.1-tuxcare.3.
- Record
CLSA-2026-1793097608- Updated
- 2026-11-02
OSVCLSA-2026-1793181094 No score
TuxCare security update for ip-address (1 CVE)
TuxCare rebuilt ip-address to address 1 CVE. Fixed in 10.1.0-tuxcare.4.
- Record
CLSA-2026-1793181094- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
ip-addressnpm |
10.1.1 to 10.2.1 | 10.2.2 |
ip-addressTuxCare:npm From an advisory covering 2 CVEs |
6.4.0-tuxcare.0 up to 6.4.0-tuxcare.2, plus listed versions 6.4.06.4.0-tuxcare.1 |
6.4.0-tuxcare.2 |
ip-addressTuxCare:npm From an advisory covering 2 CVEs |
7.1.0-tuxcare.0 up to 7.1.0-tuxcare.1, plus listed versions 7.1.0 |
7.1.0-tuxcare.1 |
ip-addressTuxCare:npm |
10.1.1-tuxcare.0 up to 10.1.1-tuxcare.3, plus listed versions 10.1.110.1.1-tuxcare.110.1.1-tuxcare.2 |
10.1.1-tuxcare.3 |
ip-addressTuxCare:npm |
10.1.0-tuxcare.0 up to 10.1.0-tuxcare.4, plus listed versions 10.1.010.1.0-tuxcare.110.1.0-tuxcare.210.1.0-tuxcare.3 |
10.1.0-tuxcare.4 |
node-ip-addressDebian:14 |
before 10.3.1-1, plus listed versions 10.2.0-110.2.0-28.1.0-28.1.0-3 |
10.3.1-1 |
ip-addressnpm |
10.1.1 up to 10.2.2 | 10.2.2 |
grafana12.4Red Hat:hummingbird:1 From an advisory covering 3 CVEs |
before 0:12.4.6-0.3.hum1 | 0:12.4.6-0.3.hum1 |
grafana13.1Red Hat:hummingbird:1 From an advisory covering 10 CVEs |
before 0:13.1.1-0.5.2.hum1 | 0:13.1.1-0.5.2.hum1 |
node-ip-addressUbuntu:20.04:LTS |
All versions, plus listed versions 6.3.0-1 |
None known |
Show 4 moreShow less
| Package | Affected | Fixed |
|---|---|---|
node-ip-addressUbuntu:22.04:LTS |
All versions, plus listed versions 6.4.0-18.1.0-2 |
None known |
node-ip-addressUbuntu:24.04:LTS |
All versions, plus listed versions 8.1.0-2 |
None known |
node-ip-addressUbuntu:26.10 |
All versions, plus listed versions 8.1.0-310.2.0-210.3.1-110.4.0-1 |
None known |
node-ip-addressUbuntu:26.04:LTS |
All versions, plus listed versions 8.1.0-28.1.0-3 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-69198 is a medium vulnerability (CVSS 6.9) in Beaugunderson Ip-address, published August 3, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.48%, the 41st percentile. Fixed in ip-address 10.2.2.
References
github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh
github.com/beaugunderson/ip-address/commit/488fe9bc7c35363b4b090494fc38c266d217740d
github.com/beaugunderson/ip-address/releases/tag/v10.2.2
github.com/advisories/GHSA-4xrf-jv44-h6hh
github.com/CVEProject/cvelistV5/tree/main/cves/2026/69xxx/CVE-2026-69198.json
nvd.nist.gov/vuln/detail/CVE-2026-69198
Show 79 moreShow less
security-tracker.debian.org/tracker/CVE-2026-69198
github.com/beaugunderson/ip-address
access.redhat.com/errata/RHSA-2026:49401
access.redhat.com/security/cve/CVE-2026-18446
access.redhat.com/security/updates/classification
images.redhat.com
access.redhat.com/security/cve/CVE-2026-67319
access.redhat.com/security/cve/CVE-2026-69198
security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_49401.json
bugzilla.redhat.com/show_bug.cgi?id=2509801
cve.org/CVERecord?id=CVE-2026-18446
nvd.nist.gov/vuln/detail/CVE-2026-18446
cna.openjsf.org/security-advisories.html
github.com/fastify/fast-uri/security/advisories/GHSA-7p8r-x3mc-p8w7
bugzilla.redhat.com/show_bug.cgi?id=2510023
cve.org/CVERecord?id=CVE-2026-67319
nvd.nist.gov/vuln/detail/CVE-2026-67319
github.com/axios/axios/security/advisories/GHSA-7q8q-rj6j-mhjq
vulncheck.com/advisories/axios-before-prototype-pollution-via-nested-option-objects
bugzilla.redhat.com/show_bug.cgi?id=2510803
cve.org/CVERecord?id=CVE-2026-69198
access.redhat.com/errata/RHSA-2026:50826
access.redhat.com/security/cve/CVE-2026-67313
access.redhat.com/security/cve/CVE-2026-67314
access.redhat.com/security/cve/CVE-2026-67315
access.redhat.com/security/cve/CVE-2026-67316
access.redhat.com/security/cve/CVE-2026-67317
access.redhat.com/security/cve/CVE-2026-67318
access.redhat.com/security/cve/CVE-2026-69152
access.redhat.com/security/cve/CVE-2026-69153
access.redhat.com/security/cve/CVE-2026-69192
security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_50826.json
cve.org/CVERecord?id=CVE-2026-67313
bugzilla.redhat.com/show_bug.cgi?id=2510030
cve.org/CVERecord?id=CVE-2026-67314
nvd.nist.gov/vuln/detail/CVE-2026-67314
github.com/axios/axios/security/advisories/GHSA-xj6q-8x83-jv6g
vulncheck.com/advisories/axios-before-prototype-pollution-via-auth-subfields
bugzilla.redhat.com/show_bug.cgi?id=2510019
cve.org/CVERecord?id=CVE-2026-67315
nvd.nist.gov/vuln/detail/CVE-2026-67315
github.com/axios/axios/security/advisories/GHSA-f4gw-2p7v-4548
vulncheck.com/advisories/axios-before-no-proxy-bypass-via
bugzilla.redhat.com/show_bug.cgi?id=2510009
cve.org/CVERecord?id=CVE-2026-67316
nvd.nist.gov/vuln/detail/CVE-2026-67316
github.com/axios/axios/security/advisories/GHSA-mmx7-hfxf-jppx
vulncheck.com/advisories/axios-before-prototype-pollution-via-bodyless-methods
bugzilla.redhat.com/show_bug.cgi?id=2510031
cve.org/CVERecord?id=CVE-2026-67317
nvd.nist.gov/vuln/detail/CVE-2026-67317
github.com/axios/axios/security/advisories/GHSA-jqh4-m9w3-8hp9
vulncheck.com/advisories/axios-before-maxbodylength-bypass-via-readablestream
bugzilla.redhat.com/show_bug.cgi?id=2509989
cve.org/CVERecord?id=CVE-2026-67318
nvd.nist.gov/vuln/detail/CVE-2026-67318
github.com/axios/axios/security/advisories/GHSA-mwf2-3pr3-8698
vulncheck.com/advisories/axios-before-maxbodylength-bypass-via-http-2
bugzilla.redhat.com/show_bug.cgi?id=2510722
cve.org/CVERecord?id=CVE-2026-69152
nvd.nist.gov/vuln/detail/CVE-2026-69152
github.com/juliangruber/brace-expansion/commit/139d015104e71433ad52a41d19467c48ecbb2c7d
github.com/juliangruber/brace-expansion/commit/1e30c930238d7162802d88a94189182def178dac
github.com/juliangruber/brace-expansion/commit/688a99eeaab02627c2b89ba8ba4821fecfa659cf
github.com/juliangruber/brace-expansion/commit/cb4b9e47cc2ec777c14b2b4492fb431a56f6a031
github.com/juliangruber/brace-expansion/security/advisories/GHSA-rgw5-rvv9-x895
bugzilla.redhat.com/show_bug.cgi?id=2510719
cve.org/CVERecord?id=CVE-2026-69153
nvd.nist.gov/vuln/detail/CVE-2026-69153
github.com/postcss/postcss/commit/7beca139e70f9075c6b19700fcb00dd8033e5da8
github.com/postcss/postcss/releases/tag/8.5.19
github.com/postcss/postcss/security/advisories/GHSA-fxqj-rqcc-2cmp
bugzilla.redhat.com/show_bug.cgi?id=2510801
cve.org/CVERecord?id=CVE-2026-69192
nvd.nist.gov/vuln/detail/CVE-2026-69192
github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e
github.com/beaugunderson/ip-address/releases/tag/v10.3.1
github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr
ubuntu.com/security/CVE-2026-69198
Left out here: the rest of 2 source descriptions. The JSON record has them.