@silverpill The dangerous case is not that every one of those ranges is equally exploitable. For example, the documentation ranges are mostly a correctness signal.

The real concern is that this function is an SSRF boundary. Once Fedify decides “this URL is public enough to fetch,” the request is made from the server's network, not from the attacker's network.

A realistic example would be a Fedify server running in an environment where 100.64.0.0/10 is used for provider, VPN, Kubernetes, or internal service networking. If an attacker can put a URL like https://100.64.0.10/... in a remote ActivityPub object or media URL, and Fedify classifies that address as public, the Fedify server may send a request to something only reachable from inside that deployment. That could be an internal HTTP service, proxy, metadata endpoint, admin panel, or just a host that reveals reachability through timing or errors.

Similar reasoning applies to ranges like 198.18.0.0/15 in lab or benchmarking networks, and to IPv6 translation/tunneling prefixes where an address can map back to a private IPv4 destination.

So I would not phrase it as “documentation or multicast addresses are always practical SSRF targets.” The issue is that a security check whose job is to allow only public internet destinations was accepting addresses that are not public internet destinations. For SSRF mitigation, that should fail closed: allow globally routable public addresses, reject the rest.