CVE-2026-54729: 
JavaScript vulnerability analysis and mitigation

CVE-2026-54729 is a Server-Side Request Forgery (SSRF) vulnerability in the dssrf Node.js library (npm package), which is designed to provide SSRF defense utilities. The flaw exists in the is_url_safe function, which can incorrectly treat localhost as a safe destination when the DNS resolver 1.1.1.1 (Cloudflare) returns NXDOMAIN — because dns.resolve4 yields no address and no dns.lookup fallback is triggered. All versions up to and including 1.0.4 are affected; the issue was fixed in version 1.0.5. It was originally discovered and disclosed on June 9, 2026, and published to the GitHub Advisory Database on July 31, 2026, with a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Feedly).

The root cause is classified as CWE-918 (Server-Side Request Forgery). The resolve_all_records() function in src/helpers.ts relied solely on dns.resolve4 and dns.resolve6 to resolve hostnames; when the configured DNS resolver (e.g., 1.1.1.1) returns NXDOMAIN for localhost, both calls return empty arrays and no dns.lookup fallback is invoked. As a result, is_hostname_resolve_to_internal_ip() finds no internal addresses and is_url_safe() incorrectly returns true, allowing requests to localhost or other restricted internal addresses to proceed unchecked. The fix (PR #102, commit 668c217) refactors resolve_all_records() to run dns.resolve4, dns.resolve6, and dns.resolveCname in parallel via Promise.all, and adds a dns.lookup({ all: true }) fallback when both A and AAAA results are empty (Github Advisory, PR #102, Commit 668c217).

Successful exploitation allows an unauthenticated remote attacker to bypass the SSRF protection provided by dssrf and force the vulnerable application to send HTTP requests to localhost or other internal/restricted addresses. This can expose internal administrative interfaces, metadata services, or other backend services not intended to be publicly accessible, potentially leading to unauthorized data access, internal service enumeration, or further lateral movement within the hosting environment. The integrity impact is rated High under CVSS v4.0, as the attacker can manipulate the application's outbound request behavior in ways the application owner did not intend (Github Advisory, Feedly).

1. Identify vulnerable applications: Locate Node.js applications that use the dssrf npm package at version 1.0.4 or earlier and rely on is_url_safe() for SSRF protection, particularly those configured to use 1.1.1.1 as their DNS resolver.
2. Confirm DNS resolver configuration: Verify that the target application's Node.js process uses 1.1.1.1 (or another resolver that returns NXDOMAIN for localhost), which can sometimes be inferred from server environment configurations or cloud provider defaults.
3. Craft a malicious URL: Prepare a request targeting an internal resource, such as http://localhost/admin, http://127.0.0.1:8080/api, or http://169.254.169.254/latest/meta-data/ (cloud metadata endpoint).
4. Submit the URL to the application: Send the crafted URL to any application endpoint that accepts user-supplied URLs and passes them through is_url_safe() for validation (e.g., a webhook registration, URL preview, or proxy feature).
5. Bypass SSRF check: Because 1.1.1.1 returns NXDOMAIN for localhost, dns.resolve4 returns an empty array, no dns.lookup fallback occurs, and is_url_safe() returns true, allowing the request to proceed.
6. Access internal resources: The application server makes an HTTP request to the internal address on behalf of the attacker, and the response may be returned to the attacker or used to exfiltrate data or interact with internal services (Github Advisory, PR #102).

• Network: Outbound HTTP requests from the application server to 127.0.0.1, ::1, localhost, or cloud metadata IP 169.254.169.254 that are not expected in normal operation; unusual internal service access patterns originating from the Node.js application process.
• Logs: Application logs showing is_url_safe() returning true for URLs containing localhost, 127.0.0.1, or other RFC-1918/loopback addresses; DNS query logs showing NXDOMAIN responses for localhost from 1.1.1.1.
• Process: Node.js process initiating HTTP connections to loopback or link-local addresses; unexpected responses from internal admin panels or metadata services appearing in application output or error logs.

Upgrade the dssrf npm package to version 1.0.5 or later, which introduces a dns.lookup({ all: true }) fallback in resolve_all_records() to correctly identify internal addresses even when dns.resolve4/dns.resolve6 return empty results. As an interim workaround, implement network-level egress controls to block outbound requests from the application server to loopback and RFC-1918 addresses, regardless of application-layer checks. Additionally, consider switching to a DNS resolver that correctly handles localhost lookups, or adding explicit blocklist checks for known internal hostnames before invoking is_url_safe() (Github Advisory, Commit 668c217).