The CVE-2026-73058 bypass through the unspecified IPv6 address (::) is a textbook example of why blocklist-based SSRF protection is a structural losing strategy — not because developers made a mistake, but because the entire approach requires exhaustively predicting every syntactic variant of a forbidden target. You almost certainly blocked 127.0.0.1. You probably blocked localhost. You almost certainly did not block ::, ::1, 0:0:0:0:0:0:0:1, and the other RFC-compliant IPv6 loopback representations that exist in the wild. This is not a knowledge gap in the narrow sense — it's a threat modeling gap compounded by the fact that IPv6 variants don't surface in most local testing environments. Your test suite iterates 127.0.0.1 and passes; it never tries ::, so it never catches the gap.
The /proxy and /embed endpoints where this bypass was possible are telling: these are business features that inherently require making outbound requests, not security primitives that were misconfigured. Security was retrofitted as a blocklist after the feature shipped. That retrofit pattern is where the real exposure lives — time pressure, feature complexity, and the invisibility of IPv6 in testing workflows all ensure the blocklist is perpetually incomplete.
The 0.15.0 patch that blocks :: addresses this instance but not the class. The critical question is whether stoatchat now uses allowlisting for these endpoints, or whether other IPv6 loopback variants remain unblocked. Even if :: is explicitly blocked, the blocklist-as-security-boundary architecture remains inherently incomplete — every hardcoded string in that list is both a detection point for defenders to maintain and a discovery target for attackers. The historical record is unambiguous: IPv4-mapped IPv6 addresses (::ffff:127.0.0.1) bypassed IPv4-only blocklists years ago; DNS rebinding defeated hostname checks; HTTP redirects escaped perimeter restrictions. Each time, the postmortem is identical — developer blocked the obvious representation, attacker found one they missed, patch added the specific variant. The pattern reinforces itself with every CVE.
For practitioners: treat this as a design failure, not an implementation oversight. Audit whether your SSRF protection uses blocklists or allowlists — if it's a blocklist, assume it's incomplete until proven otherwise. For IPv6 specifically, there is no equivalent of the IPv4 testing tooling that helps developers verify coverage. You will need to explicitly enumerate every RFC 4291 loopback representation and test against each one. The MEDIUM severity rating on this CVE (5.8) reflects theoretical impact, not organizational exposure — if your /proxy endpoint is accessible to external users against a network where internal services listen on loopback, the effective severity is materially higher. Consider whether these endpoints should exist at all, or whether restricting to pre-approved destinations (allowlisting) reduces the maintenance burden that blocklists inevitably accumulate over time.