Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 4.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The library did not check for IPv6 loopback attacks. There was also a DNS attack, where an address could be resolved into an internal IP. This could cause internal data leaks. Patches Problem has been patched in version 4.0.1. However, it cannot be completely solved by the package alone. The regex used for validation has been tightened for IPv6 addresses. The DNS resolving, however, is more difficult. The regex has been tightened to prohibit .internal, .local, .nip.io and .sslip.io addresses, however there can be other services not on the list, therefore it is imperative that users use the resolveDNSHost option to do DNS resolution before fetching content. To that regard a (scary) error message has been added when the option is not set. Workarounds Users can do their own validation before fetching content. Reported by https://github.com/Andrew-most-likely
Recommended action: Upgrade to 4.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The package link-preview-js before 2.1.17 are vulnerable to Server-side Request Forgery (SSRF) which allows attackers to send arbitrary requests to the local network and read the response. This is due to flawed DNS rebinding protection.
Recommended action: Upgrade to 2.1.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.