@silverpill Yeah, I think that is a fair distinction. Documentation and multicast ranges are not the main practical SSRF targets here, especially for ordinary HTTP fetching.

The practical risk is clearer for ranges like 100.64.0.0/10, 198.18.0.0/15, and IPv6 translation/tunneling prefixes, which can map to provider, VPN, lab, Kubernetes, or enterprise-internal networks. A request made by the Fedify server may reach something the attacker cannot reach directly.

For documentation ranges, the “in theory” case would be a non-compliant internal network using TEST-NET addresses. For multicast, I would mostly treat it as a correctness/fail-closed issue rather than a likely standalone exploit.

The security bug is that validatePublicUrl() was an SSRF boundary but did not enforce public/global address semantics. At that boundary, I do not think we should maintain a list of “non-public but probably harmless” exceptions. If it is not globally routable public address space, the fetch should be rejected.