Security: SSRF bypass via userinfo stripping in is_url_safe (1.0.3)

[andrewmkhoury]

[REDACTED]

[HackingRepo]

please in another time create a security advisory not open issues on github

[HackingRepo]

@andrewmkhoury

[HackingRepo]

we not able to reproduce that @andrewmkhoury

relunsec@relunsec:~/software/dssrf$ cat index.js
const { is_url_safe } = require('dssrf');

(async () => {
  const cases = [
    'http://evil.com@127.0.0.1/',
    'http://evil.com@10.0.0.1/',
    'http://evil.com@192.168.1.1/',
    'http://evil.com@169.254.169.254/',   // AWS IMDS
    'http://evil.com@[::1]/',
  ];
  for (const url of cases) {
    const safe = await is_url_safe(url);
    console.log(`${safe ? 'BYPASSED ✗' : 'blocked  ✓'}  ${url}`);
  }
})();
relunsec@relunsec:~/software/dssrf$ node index.js 
blocked  ✓  http://evil.com@127.0.0.1/
blocked  ✓  http://evil.com@10.0.0.1/
blocked  ✓  http://evil.com@192.168.1.1/
blocked  ✓  http://evil.com@169.254.169.254/
blocked  ✓  http://evil.com@[::1]/
relunsec@relunsec:~/software/dssrf$ 

Everything blocked

[andrewmkhoury]

Thanks for checking — the cases you tested are actually accidentally blocked, which is why they look fine. The bypass requires a numeric userinfo prefix that concatenates with the host into a valid public IP after @ is stripped.

Here's the exact reproducer that confirms the issue on 1.0.3:

const { is_url_safe } = require('dssrf');

(async () => {
  const cases = [
    // ── These bypass (dssrf returns true, but HTTP client connects to private IP) ──
    'http://1@10.0.0.1/',   // strips @ → 110.0.0.1  (public IP) → passes check
    'http://2@10.0.0.1/',   // strips @ → 210.0.0.1  (public IP) → passes check

    // ── These are accidentally blocked (invalid hostname after stripping) ──
    'http://evil.com@127.0.0.1/',       // strips @ → evil.com127.0.0.1 → throws → false
    'http://evil.com@10.0.0.1/',        // same
    'http://evil.com@169.254.169.254/', // same
  ];
  for (const url of cases) {
    const safe = await is_url_safe(url);
    console.log(`${safe ? 'BYPASSED ✗' : 'blocked  ✓'}  ${url}`);
  }
})();

Output on 1.0.3:

BYPASSED ✗  http://1@10.0.0.1/
BYPASSED ✗  http://2@10.0.0.1/
blocked  ✓  http://evil.com@127.0.0.1/
blocked  ✓  http://evil.com@10.0.0.1/
blocked  ✓  http://evil.com@169.254.169.254/

Why evil.com@ vectors are blocked: remove_at_symbol_in_string turns http://evil.com@10.0.0.1/ into http://evil.com10.0.0.1/. That's an invalid hostname, so new URL() throws and the function returns false. Blocked by accident.

Why 1@ bypasses: http://1@10.0.0.1/ → strip @ → http://110.0.0.1/. 110.0.0.1 is a valid, public IPv4 address (passes all SSRF checks). But any HTTP client using the original URL (http://1@10.0.0.1/) ignores the userinfo 1 and connects to 10.0.0.1 — a private RFC1918 address.

The root cause is calling remove_at_symbol_in_string on the raw URL before parsing. Once you parse with new URL() first, you can check parsed.username !== "" directly and reject it without any string manipulation. That's what PR #98 does.

[HackingRepo]

Ok that needs to be fixed, in today, ok, in another time please do'nt post security issues here

[andrewmkhoury]

The claim that HTTP clients won't connect to 10.0.0.1 for http://2@10.0.0.1/ is incorrect. Every modern HTTP client (Node.js http, got, fetch, curl, Python requests) implements the WHATWG URL standard. Under that standard, the 2 is parsed as userinfo (credentials) — not part of the host. The host is unambiguously 10.0.0.1:

new URL('http://2@10.0.0.1/').hostname  // → "10.0.0.1"
new URL('http://2@10.0.0.1/').username  // → "2"

The exploit is precisely the split between what dssrf checks vs. what the HTTP client connects to:

	URL checked	Hostname seen
dssrf	http://210.0.0.1/ (after stripping @)	210.0.0.1 ← public, passes
got / fetch / curl	http://2@10.0.0.1/ (original)	10.0.0.1 ← private RFC1918

You can verify this yourself — the 0@10.0.0.0 case you found actually demonstrates the same split perfectly. Your PoC showed remove_at_symbol_in_string('http://0@10.0.0.0/') → http://010.0.0.0/ → WHATWG parses 010 as octal → hostname 8.0.0.0 (public, passes check). But:

new URL('http://0@10.0.0.0/').hostname  // → "10.0.0.0"  ← that's where the client connects

Confirmed working bypass vectors on 1.0.3:

new URL('http://1@10.0.0.1/').hostname  // → "10.0.0.1"  (dssrf sees 110.0.0.1 — public)
new URL('http://2@10.0.0.1/').hostname  // → "10.0.0.1"  (dssrf sees 210.0.0.1 — public)
new URL('http://0@10.0.0.0/').hostname  // → "10.0.0.0"  (dssrf sees 8.0.0.0   — public)

All three are real RFC1918 addresses. got (which dssrf uses internally for redirect following) will connect to them. Any caller using the original URL string with their own HTTP client will also connect to them — that's the entire SSRF threat model.

The fix in PR #98 avoids all of this by never manipulating the URL string — just parse once with new URL(), then reject if parsed.username !== "".

[HackingRepo]

no nooooooooooooooooo million of times, not a vuln you should first is_url_safe function returned false, then you will return SSRF detected not new URL, the library works correctly, you just hallucinated, garbage, i see never works

I disagree please submit valid vulns, example like GHSA-8p33-q827-ghj5 the another researcher published valid, that is AI Slop, it does not work at all

import { is_url_safe } from 'dssrf'; // 1.0.3

let b = await is_url_safe('http://2@127.0.0.1:7001/');
if (!b) { console.log("SSRF DETECTED") }
else { fetch(b) } // Never fetched

// So that will just display just SSRF DETECTED and everything safe

[andrewmkhoury]

Here is a self-contained PoC in the same format as GHSA-8p33-q827-ghj5. Copy-paste and run — no other setup needed.

mkdir dssrf-userinfo-poc && cd dssrf-userinfo-poc
npm init -y >/dev/null
npm install dssrf@1.0.3
cat > audit.js <<'EOF'
const dssrf = require('dssrf');

const cases = [
  // Controls — must remain blocked
  ['http://10.0.0.1/',   false, 'RFC1918 bare (control)'],
  ['http://127.0.0.1/',  false, 'loopback bare (control)'],
  ['https://8.8.8.8/',   true,  'public IPv4 (control)'],

  // Bypasses — dssrf returns true but HTTP client connects to private IP
  ['http://2@10.0.0.1/', false, 'strips @ → 210.0.0.1 (public) — client hits 10.0.0.1'],
  ['http://1@10.0.0.1/', false, 'strips @ → 110.0.0.1 (public) — client hits 10.0.0.1'],
  ['http://0@10.0.0.0/', false, 'strips @ → 010.0.0.0 → octal 8.0.0.0 — client hits 10.0.0.0'],
];

(async () => {
  let bypasses = 0;
  for (const [url, expected, label] of cases) {
    const safe = await dssrf.is_url_safe(url);
    const bypassed = safe === true && expected === false;
    if (bypassed) bypasses++;
    const status = bypassed         ? '✗ BYPASS' :
                   safe === expected ? '✓ ok    ' : '? wrong ';
    console.log(`${status}  ${url.padEnd(28)}  ${label}`);
  }
  console.log('');
  console.log(bypasses > 0
    ? `VULNERABLE: ${bypasses} bypass(es) confirmed on dssrf@1.0.3`
    : 'No bypasses found.');
  process.exit(bypasses > 0 ? 1 : 0);
})();
EOF
node audit.js

Expected output on 1.0.3:

✓ ok      http://10.0.0.1/              RFC1918 bare (control)
✓ ok      http://127.0.0.1/             loopback bare (control)
✓ ok      https://8.8.8.8/              public IPv4 (control)
✗ BYPASS  http://2@10.0.0.1/            strips @ → 210.0.0.1 (public) — client hits 10.0.0.1
✗ BYPASS  http://1@10.0.0.1/            strips @ → 110.0.0.1 (public) — client hits 10.0.0.1
✗ BYPASS  http://0@10.0.0.0/            strips @ → 010.0.0.0 → octal 8.0.0.0 — client hits 10.0.0.0

VULNERABLE: 3 bypass(es) confirmed on dssrf@1.0.3

Why your earlier test missed it: you tested http://2@127.0.0.1/ — loopback. Stripping @ gives 2127.0.0.1 which is an invalid hostname, so new URL() throws and is_url_safe returns false. Blocked by accident, not by design. The bypass only works against 10.x.x.x where the stripped form (210.x.x.x) happens to be a valid public IP.

[HackingRepo]

Not a vulnerability at all, but do'nt worry will be a hardening fix, in thw next version, but i will merge your pr now

[andrewmkhoury]

Please dig further I am pretty sure it isn't hallucination. I am using AI to speed up my work here but I am testing and I see it is indeed vulnerable with certain IPs. Your test was for 127.0.0.1 but that isn't vulnerable, the 10.0.0.* IPs are vulnerable. See below, it gets past it because 210.0.0.1 is seen as a valid IP. The example you gave won't work because ***@***.*** => 2127.0.0.1 is not a valid IP. import { is_url_safe } from 'dssrf'; // 1.0.3 let b = await ***@***.***:7001/'); if (!b) { console.log("SSRF DETECTED") } if (b) { console.log("VULNERABLE - SSRF NOT DETECTED") } *The reason why the issue is only with IPs with first block as two digits is because the @ gets stripped:*helpers.js:318-319 — the function itself: function remove_at_symbol_in_string(s) { return s.replace(/@/g, ""); } helpers.js:407 — called inside is_url_safe before new URL(): u = replace_two_slashes_url_to_normal_url(u); u = remove_at_symbol_in_string(u); // ← strips @ here const parsed = new URL(u); // ← parses the already-corrupted string So by the time new URL() is called, the @ is already gone and the hostname has been silently mangled. The fix in PR #98 removes line 407 entirely and instead checks parsed.username !== "" after parsing the original URL.

…

On Mon, Jun 1, 2026 at 11:18 PM RelunSec ***@***.***> wrote: *HackingRepo* left a comment (HackingRepo/dssrf-js#97) <#97 (comment)> no nooooooooooooooooo, not a vuln you should first is_url_safe function returned false, then you will return SSRF detected not new URL, the library works correctly, you just hallucinated, garbage, i see never works I disagree please submit valid vulns, example like GHSA-8p33-q827-ghj5 <https://github.com/HackingRepo/dssrf-js/security/advisories/GHSA-8p33-q827-ghj5> the another researcher published valid, that is AI Slop, it does not work at all import { is_url_safe } from 'dssrf'; // 1.0.3 let b = await ***@***.***:7001/');if (!b) { console.log("SSRF DETECTED") }// So that will just display SSRF DETECTED — Reply to this email directly, view it on GitHub <#97?email_source=notifications&email_token=AASDLARMIPPLXUAB53CUBOL45ZWURA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZHEZDONRYGYZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4599276862>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASDLAUQB5GJQJAU2NNZ32345ZWURAVCNFSM6AAAAACZS3CZV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKOJZGI3TMOBWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>