Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
isurlsafe can treat localhost as safe when DNS resolver 1.1.1.1 returns NXDOMAIN because dns.resolve4 yields no address and no dns.lookup fallback occurs, allowing server-side request forgery. POC Example to simulate 1.1.1.1 in version before 1.5.0 of dssrf:
Recommended action: Upgrade to 1.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
isurlsafe in v1.0.3 contains an SSRF bypass. removeatsymbolinstring is applied to the raw URL string before new URL() parses it. This strips the @ that separates userinfo from host, corrupting the hostname so internal IPs are never checked. Vulnerability In helpers.ts, isurlsafe does: What happens step by step Input: http://evil.com@127.0.0.1/ 1. removeatsymbolinstring → http://evil.com127.0.0.1/ 2. new URL(...) → hostname = "evil.com127.0.0.1" 3. Not a bare IP, not IPv6 → passes all IP checks 4. ishostnameresolvetointernalip("evil.com127.0.0.1") → NXDOMAIN → returns false 5. Result: true (safe) — but any HTTP client using the original URL connects to 127.0.0.1 Proof of Concept Root Cause @ in a URL separates userinfo (credentials) from host. Stripping it from the raw string before parsing destroys that boundary. The fix is to reject any URL that contains a userinfo component after parsing. Suggested Fix Remove the removeatsymbolinstring call from isurlsafe and add a userinfo…
Recommended action: Upgrade to 1.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability on dssrf allow, an attacker to use, one of them following 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 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
Recommended action: Upgrade to 1.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.