GHSA-8P33-Q827-GHJ5
Vulnerability from github – Published: 2026-05-06 18:13 – Updated: 2026-06-18 22:54
VLAI
Summary
dssrf: every IPv6 category bypasses is_url_safe
Details
A vulnerability on dssrf allow, an attacker to use, one of them following ipv6
Input Category
http://[::1]/ IPv6 loopback
http://[fc00::1]/ IPv6 ULA
http://[fe80::1]/ IPv6 link-local
http://[::ffff:127.0.0.1]/ IPv4-mapped loopback
http://[::ffff:169.254.169.254]/ IPv4-mapped IMDS
http://[::ffff:100.64.0.1]/ IPv4-mapped CGNAT
http://[64:ff9b::7f00:1]/ NAT64 well-known prefix
http://[64:ff9b:1::1]/ NAT64 local-use (RFC 8215)
http://[5f00::1]/ SRv6 SID (RFC 9602)
http://[3fff::1]/ IPv6 documentation (RFC 9637)
http://[fec0::1]/ IPv6 site-local (deprecated, RFC 3879)
http://[::127.0.0.1]/ IPv4-compatible IPv6
one of those to bypass dssrf and the attacker get SSRF, we claim that ipv6 disabled entirely that is wrong on our documentation
POC
mkdir dssrf-poc && cd dssrf-poc
npm init -y >/dev/null
npm install dssrf@^1.0.2
cat > audit.js <<'EOF'
const dssrf = require('dssrf');
const cases = [
['http://[::1]/', 'IPv6 loopback'],
['http://[fc00::1]/', 'IPv6 ULA'],
['http://[fe80::1]/', 'IPv6 link-local'],
['http://[::ffff:127.0.0.1]/', 'IPv4-mapped loopback'],
['http://[::ffff:169.254.169.254]/', 'IPv4-mapped IMDS'],
['http://[64:ff9b::7f00:1]/', 'NAT64 well-known + 127.0.0.1'],
['http://[64:ff9b:1::1]/', 'NAT64 local-use (RFC 8215)'],
['http://[5f00::1]/', 'SRv6 SID (RFC 9602)'],
['http://[fec0::1]/', 'IPv6 site-local deprecated'],
['http://127.0.0.1/', 'IPv4 loopback (control)'],
['http://10.0.0.1/', 'IPv4 RFC1918 (control)'],
['http://8.8.8.8/', 'PUBLIC IPv4 (control)'],
];
(async () => {
for (const [url, label] of cases) {
const safe = await dssrf.is_url_safe(url);
console.log(`${safe ? '✓ALLOW' : '·block'} ${url.padEnd(40)} ${label}`);
}
})();
EOF
node audit.js
Credit
Million Thank's to brmenna@gmail.com for reporting that responsibly.
Update
Users need to update from now to dssrf 1.0.3
Lessons Learned
AS we see in the past and today, a lot of advisories or cves bypasses uses IPv6, and IPv6 is the weakest link to be configured correctly and rarely properly tested, Since we blocked ipv4, our ipv6 blocking logic completly broken and never works
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "dssrf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44232"
],
"database_specific": {
"cwe_ids": [
"CWE-791"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T18:13:32Z",
"nvd_published_at": "2026-05-12T21:16:16Z",
"severity": "HIGH"
},
"details": "A vulnerability on dssrf allow, an attacker to use, one of them following ipv6\n\n```rust\nInput\tCategory\nhttp://[::1]/\tIPv6 loopback\nhttp://[fc00::1]/\tIPv6 ULA\nhttp://[fe80::1]/\tIPv6 link-local\nhttp://[::ffff:127.0.0.1]/\tIPv4-mapped loopback\nhttp://[::ffff:169.254.169.254]/\tIPv4-mapped IMDS\nhttp://[::ffff:100.64.0.1]/\tIPv4-mapped CGNAT\nhttp://[64:ff9b::7f00:1]/\tNAT64 well-known prefix\nhttp://[64:ff9b:1::1]/\tNAT64 local-use (RFC 8215)\nhttp://[5f00::1]/\tSRv6 SID (RFC 9602)\nhttp://[3fff::1]/\tIPv6 documentation (RFC 9637)\nhttp://[fec0::1]/\tIPv6 site-local (deprecated, RFC 3879)\nhttp://[::127.0.0.1]/\tIPv4-compatible IPv6\n```\n\none of those to bypass dssrf and the attacker get **SSRF**, we claim that ipv6 disabled entirely that is wrong on our documentation\n\n### POC\n\n```bash\nmkdir dssrf-poc \u0026\u0026 cd dssrf-poc\nnpm init -y \u003e/dev/null\nnpm install dssrf@^1.0.2\ncat \u003e audit.js \u003c\u003c\u0027EOF\u0027\nconst dssrf = require(\u0027dssrf\u0027);\nconst cases = [\n [\u0027http://[::1]/\u0027, \u0027IPv6 loopback\u0027],\n [\u0027http://[fc00::1]/\u0027, \u0027IPv6 ULA\u0027],\n [\u0027http://[fe80::1]/\u0027, \u0027IPv6 link-local\u0027],\n [\u0027http://[::ffff:127.0.0.1]/\u0027, \u0027IPv4-mapped loopback\u0027],\n [\u0027http://[::ffff:169.254.169.254]/\u0027, \u0027IPv4-mapped IMDS\u0027],\n [\u0027http://[64:ff9b::7f00:1]/\u0027, \u0027NAT64 well-known + 127.0.0.1\u0027],\n [\u0027http://[64:ff9b:1::1]/\u0027, \u0027NAT64 local-use (RFC 8215)\u0027],\n [\u0027http://[5f00::1]/\u0027, \u0027SRv6 SID (RFC 9602)\u0027],\n [\u0027http://[fec0::1]/\u0027, \u0027IPv6 site-local deprecated\u0027],\n [\u0027http://127.0.0.1/\u0027, \u0027IPv4 loopback (control)\u0027],\n [\u0027http://10.0.0.1/\u0027, \u0027IPv4 RFC1918 (control)\u0027],\n [\u0027http://8.8.8.8/\u0027, \u0027PUBLIC IPv4 (control)\u0027],\n];\n(async () =\u003e {\n for (const [url, label] of cases) {\n const safe = await dssrf.is_url_safe(url);\n console.log(`${safe ? \u0027\u2713ALLOW\u0027 : \u0027\u00b7block\u0027} ${url.padEnd(40)} ${label}`);\n }\n})();\nEOF\nnode audit.js\n```\n\n### Credit\nMillion Thank\u0027s to \u003cbrmenna@gmail.com\u003e for reporting that responsibly.\n\n### Update\nUsers need to update from now to dssrf 1.0.3\n\n### Lessons Learned\nAS we see in the past and today, a lot of advisories or cves bypasses uses IPv6, and IPv6 is the weakest link to be configured correctly and rarely properly tested, Since we blocked ipv4, our ipv6 blocking logic completly broken and never works",
"id": "GHSA-8p33-q827-ghj5",
"modified": "2026-06-18T22:54:14Z",
"published": "2026-05-06T18:13:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/HackingRepo/dssrf-js/security/advisories/GHSA-8p33-q827-ghj5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44232"
},
{
"type": "PACKAGE",
"url": "https://github.com/HackingRepo/dssrf-js"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "dssrf: every IPv6 category bypasses is_url_safe"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…