GHSA-cpjf-6666-r8fx: SSRF
The existing advisory GHSA-4gp8-rjrq-ch6q / CVE-2026-43897 states that the SSRF issue was fixed in 4.0.1. However, 4.0.3 remains bypassable when the documented resolveDNSHost mitigation is used.
Root cause: The library validates one resolved IP address through resolveDNSHost, but later performs fetch() against the original hostname without pinning the connection to the validated IP. An attacker-controlled DNS server can return a public IP during validation and a loopback/internal IP during the final connection.
Impact: This allows an attacker to bypass the documented SSRF mitigation and make the server-side fetch reach loopback or internal addresses under DNS rebinding conditions.
This appears to be either an incomplete fix for CVE-2026-43897 or a new DNS rebinding SSRF bypass affecting the latest version.
The PoC was reproduced in a local-only controlled environment to avoid targeting production or third-party systems. Evidence and reproduction details can be provided privately.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/link-preview-jsto a version that resolves this vulnerability.Fixed in 4.0.4
Event History
Frequently Asked Questions
What conditions are required for exploitation?
The deployment must rely on the documented resolveDNSHost mitigation, and the attacker must be able to control DNS responses for the hostname being fetched. The DNS server returns a public IP during validation and a loopback or internal IP when the later fetch() connection occurs.
Which deployments are realistically exposed?
Deployments using link-preview-js for server-side fetching and relying on resolveDNSHost to prevent requests to loopback or internal addresses are exposed under DNS rebinding conditions. The issue affects the gap between validating a resolved address and connecting to the original hostname.
Does version 4.0.3 fully prevent this bypass?
No. The available information states that 4.0.3 remains bypassable when resolveDNSHost is used, despite the earlier advisory stating that the SSRF issue was fixed in 4.0.1.