The critical failure in CVE-2026-72860 isn't simply that IPv4-mapped IPv6 addresses bypass the guard — it's that the assertPublicUrl function checks a string that the WHATWG URL parser has already transformed. When the code passes a caller-supplied baseUrl through new URL(), the parser canonicalizes the input before JavaScript ever sees it. The developer who wrote the IPv6 regex branch understood the RFC representation (::ffff:127.0.0.1 format), but the parser converts this to a standard IPv6 representation that the regex never matches. The guard exists as security infrastructure that cannot fail safely — it silently passes requests it was designed to block because the pattern literally cannot match the input it receives.
This creates a compounding failure. The requireLogin toggle converts authenticated SSRF into unauthenticated SSRF with a single configuration change. Organizations that disable login for operational convenience — health checks, monitoring probes, dashboard integrations — inherit an internet-facing SSRF with credential forwarding. The apiKey gets forwarded as a Bearer token to arbitrary internal hosts, meaning the SSRF isn't just a read primitive; it's a pivot mechanism that authenticates to internal services as the compromised key owner. Combined with the 200-byte response truncation on non-2xx/401/403 responses, you have an oracle that leaks internal error content starting at byte one.
The remediation priority is straightforward: disable the requireLogin toggle immediately if it's enabled, then audit whether the apiKey scope justifies forwarding to arbitrary internal hosts — it likely doesn't. The guard itself needs to operate on parsed URL components at construction time, not as a post-parse string comparison. If your deployment has requireLogin disabled, treat the endpoint as an intentionally unauthenticated HTTP proxy with credential forwarding until the patch is applied — the SSRF is a feature of that configuration, not a defect in the guard.