Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Fedify: ActivityPub server framework@fedify@hollo.social (2026-06-08 23:56:47)
Fedify security updates: 1.9.12, 1.10.11, 2.0.20, 2.1.16, and 2.2.5
If you use Fedify, update to a patched release now. CVE-2026-50131 affects Fedify's public URL validation for remote document and media loading. An attacker could use special-use IP address ranges to bypass Fedify's SSRF protections and cause a Fedify server to initiate requests to non-public or special-use network destinations, depending on the deployment environment and network routing.

Fedify validates remote ActivityPub document and media URLs before fetching them, including direct IP literals and hostnames resolved through DNS. The vulnerable path is validatePublicUrl(): affected versions rejected common private and local addresses, but still treated several special-use IPv4 ranges as public internet destinations. That gap could allow outbound requests to ranges such as carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks.

The fix makes Fedify validate resolved addresses against public-network expectations instead of relying on the incomplete denylist. It rejects additional special-use IPv4 ranges and IPv6 translation or tunneling prefixes, including NAT64, Teredo, and 6to4 addresses, before remote document or media fetching proceeds.

Current patched releases are 1.9.12, 1.10.11, 2.0.20, 2.1.16, and 2.2.5. The GitHub Security Advisory is GHSA-xw9q-2mv6-9fr8, and the CVE ID is CVE-2026-50131.

Update @fedify/fedify:


npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify
If your project depends directly on @fedify/vocab-runtime, update that package too.

After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to Chaitanya Vilas Garware for the report and responsible disclosure.

If anything is unclear, ask below.
---Reply---
silverpill@silverpill@mitra.social (2026-06-09 04:54:57)
@fedify

That gap could allow outbound requests to ranges such as carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks

Why this is considered dangerous?

---Replies---

洪 民憙 (Hong Minhee) :nonbinary:@hongminhee@hollo.social (2026-06-09 13:19:31)
@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.