CVE-2026-61704 in link-preview-js
Summary
by MITRE • 08/20/2026
Link Preview JS extracts web links information. Prior to 4.0.4, the resolveDNSHost mitigation in index.ts validates one resolved IP address but fetches the original hostname, allowing an attacker-controlled DNS server to return a public address during validation and a loopback or internal address during the final connection. This DNS rebinding condition bypasses the SSRF protection and can cause the server-side preview fetch to reach internal HTTP resources. Redirect handling is affected by the same validation-to-fetch mismatch. This issue is fixed in version 4.0.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Link Preview JS prior to version 4.0.4 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in an inconsistent DNS resolution and hostname validation strategy. The core technical defect lies within the resolveDNSHost mitigation logic implemented in index.ts, which attempts to prevent SSRF attacks by validating that resolved IP addresses do not belong to private or loopback ranges. However, this security control suffers from a fundamental race condition known as DNS rebinding. Specifically, the library validates only one resolved IP address against its internal allowlist of safe networks but subsequently fetches content using the original hostname provided by the user rather than re-resolving and validating that same hostname at the time of connection establishment. This architectural mismatch creates a window of opportunity for an attacker who controls or can manipulate DNS responses to bypass security checks entirely.
In a typical exploitation scenario, an attacker provides a malicious domain name as input to the link preview feature. During the initial validation phase, the resolveDNSHost function queries the configured DNS server and receives a response containing a public IP address that passes the SSRF protection filters. The application then proceeds with this validated state but retains the original hostname for the actual HTTP request. If an attacker controls the authoritative DNS server or can perform a man-in-the-middle attack on the DNS resolution process, they can return different IP addresses at different times. By returning a public address during the validation step and switching to a loopback (127.0.0.1) or internal network address for subsequent queries triggered by the final connection attempt, the attacker effectively tricks the application into connecting to an otherwise protected internal resource while satisfying the initial security check.
The operational impact of this vulnerability is severe, as it allows remote attackers to force the server-side preview fetch mechanism to access internal HTTP resources that are not intended to be exposed externally. This can lead to unauthorized data exfiltration from internal services such as metadata endpoints, administrative interfaces, or other backend APIs running on localhost or within a private network segment. Furthermore, the vulnerability extends beyond simple direct connections; redirect handling is also affected by this validation-to-fetch mismatch. If an initial request redirects to another URL that resolves to an internal address via DNS rebinding, the same bypass mechanism applies, allowing attackers to traverse through multiple hops to reach protected infrastructure. This capability significantly expands the attack surface from a single endpoint to potentially any service reachable within the network topology accessible by the vulnerable server.
This flaw aligns with CWE-918 Server-Side Request Forgery (SSRF) and specifically exploits weaknesses in DNS resolution handling often categorized under CWE-643 Improper Mitigation of XPath Injection or more accurately CWE-20 Improper Input Validation when considering the failure to validate inputs at all points of use. In terms of offensive security frameworks, this technique maps directly to ATT&CK T1557 Adversary-in-the-Middle, where DNS spoofing is used to intercept and alter communications, as well as ATT&CK T1048 Exchange Traffic for Lateral Movement if the internal resources are leveraged to pivot further into a network. The vulnerability underscores the critical importance of ensuring that security validations are applied consistently at every stage of request processing, particularly when dealing with external inputs like hostnames and URLs.
To mitigate this risk, organizations must upgrade Link Preview JS to version 4.0.4 or later, where the developers have addressed the DNS rebinding issue by likely implementing stricter hostname validation strategies such as resolving the hostname immediately before each connection attempt and verifying that the resulting IP address matches the expected safe range without relying on cached resolution data from earlier in the request lifecycle. Additionally, defensive measures should include deploying network-level controls such as egress filtering to restrict outbound connections to only known legitimate destinations, implementing strict DNS security extensions (DNSSEC) where possible to prevent spoofing, and configuring application firewalls to detect anomalous patterns of internal IP access originating from web-facing services. Regularly auditing third-party dependencies for similar validation inconsistencies is also recommended to maintain a robust defense-in-depth posture against SSRF attacks.