EUVD-2026-51574
GHSA-5846-7qm3-r52j
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
AC:H because exploitation requires external DNS (e.g., 1.1.1.1) configured in Node.js; S:C and C:H because internal service access crosses trust boundary.
Primary rating from Vendor (https://github.com/HackingRepo/dssrf-js).
CVSS VectorVendor: https://github.com/HackingRepo/dssrf-js
Lifecycle Timeline
3DescriptionCVE.org
Summary
is_url_safe 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:
import { is_url_safe } from '../dist/helpers.js';
import dns from 'dns';
dns.setServers(['1.1.1.1']);
const TARGET = 'http://localhost/admin';
console.log(`Testing: ${TARGET}`);
console.log(`Current DNS Servers: ${dns.getServers()}`);
const result = await is_url_safe(TARGET);
if (result === true) {
console.log('dssrf treated localhost as SAFE because 1.1.1.1 returned NXDOMAIN.');
} else {
console.log('dssrf blocked localhost.');
}AnalysisAI
Server-side request forgery bypass in the dssrf npm SSRF-protection library (versions <= 1.0.4) allows internal resource access when Node.js is configured with an external DNS resolver such as 1.1.1.1. The is_url_safe() function relies solely on dns.resolve4 and dns.resolve6 to check whether a hostname resolves to an internal IP; when an external resolver returns NXDOMAIN for 'localhost' (which it cannot authoritatively answer), no addresses are returned and no fallback to dns.lookup occurs, causing the library to incorrectly classify localhost as safe. publicly available exploit code exists, demonstrated via a published proof-of-concept in the GitHub advisory GHSA-5846-7qm3-r52j.
Technical ContextAI
dssrf (pkg:npm/dssrf) is a Node.js library explicitly designed to prevent SSRF by validating URLs before an application makes outbound HTTP requests. Its is_url_safe() helper calls dns.resolve4() and dns.resolve6() to resolve hostnames and then checks resulting IPs against an internal-address blocklist (via is_ip_internal). The flaw is in the DNS resolution path: when Node.js is configured to use an external recursive resolver such as Cloudflare's 1.1.1.1 (via dns.setServers()), that resolver returns NXDOMAIN for 'localhost' because it has no authoritative record for it. The library interprets the empty result as 'no internal address found' and marks the URL as safe, completely bypassing the SSRF guard. The missing control is a fallback to dns.lookup(), which consults the OS-level resolver and /etc/hosts, where 'localhost' always resolves to 127.0.0.1. CWE-918 (Server-Side Request Forgery) precisely describes this root cause: a security control that is supposed to validate server-initiated HTTP requests fails to do so due to an incomplete hostname-resolution mechanism. The patch (commit 668c21792cd1252baf779a176aa652e2b4c0067d, PR #102) adds a dns.lookup({ all: true }) fallback invoked only when both dns.resolve4 and dns.resolve6 return empty arrays, closing the gap.
RemediationAI
Upgrade dssrf to version 1.0.5 or later, which introduces a dns.lookup() fallback for hostnames that return no records from dns.resolve4 and dns.resolve6; this ensures OS-level resolution (including /etc/hosts entries for 'localhost') is always consulted. The fix is available via PR #102 (https://github.com/HackingRepo/dssrf-js/pull/102) and commit 668c21792cd1252baf779a176aa652e2b4c0067d. If an immediate upgrade is not feasible, a targeted compensating control is to avoid configuring Node.js with external-only DNS resolvers (i.e., do not call dns.setServers() with only public resolvers like 1.1.1.1 or 8.8.8.8); ensuring the OS default resolver or a resolver that handles 'localhost' is always available will prevent the NXDOMAIN bypass. An additional defense-in-depth measure is to implement network-layer egress filtering that blocks outbound HTTP connections to loopback (127.0.0.0/8), link-local (169.254.0.0/16), and RFC-1918 ranges at the firewall or container network policy level, independent of application-layer checks. This compensating control has the trade-off of requiring infrastructure changes and may break legitimate internal service communication if not scoped carefully.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today