CVE-2026-61704

This CVE exposes a fundamental trust inversion in how libraries validate URLs before fetching them. The vulnerability isn't a race condition or a timing flaw—it's architectural. The library resolves the hostname to check whether it's safe, then resolves it again to fetch it, and both queries go to the same nameserver. If an attacker controls the DNS resolver for their domain (which is trivially easy to set up), they can serve any IP they want during validation and switch to a different IP during the actual fetch. The library believes it's protecting against SSRF by checking resolveDNSHost first; the attacker knows this check is deterministic and adversarial. The deeper problem is that DNS rebinding makes pre-flight validation structurally unsound. A hostname doesn't have a stable IP address—it's a lookup that can return different results on each query. Validating before connecting is like checking whether a door is locked while someone else holds the key. For defenders: the deployment context matters more than the CVSS score. This library powers link preview functionality in comment systems, issue trackers, CMS plugins, and content-aggregation platforms—anywhere a server renders previews of URLs submitted by users. If your application passes user-supplied URLs to this library for server-side preview generation, you have a direct SSRF vector to your internal network. The fix in 4.0.4 presumably implements IP pinning or connection-time validation, but the real question is whether your deployed version is patched and whether your usage pattern actually triggers the vulnerable code path. Low EPSS scores for library vulnerabilities are often misleading—they measure exploitability in controlled environments, not exposure in content-aggregation pipelines processing untrusted input.

Reviewed through automated stages and approved by a human before publication.