Fedify had security updates for two vulnerabilities. Please update your Fedify to 2.0.30, 2.1.26, 2.2.15, 2.3.10, or 2.4.0 now!
hackers.pub
Fedify security updates: 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0
Fedify has released security updates addressing two vulnerabilities: an unbounded alternate-document fetch chain issue that allows attackers to trigger indefinite HTTP loops to exhaust server resources, and a routing flaw where unverified activity documents could bypass dereference verification. The patches introduce a strict 20-hop limit across redirects, preserve fetch cancellation signals, and ensure that dereferenced activities properly replace unverified JSON-LD documents during inbox routing. Upgrading Fedify across affected 2.x versions and migrating from 1.x is critical to securing federated servers against resource exhaustion and spoofed payload processing.
Two vulnerabilities have been fixed: GHSA-97w4-f4rq-mgqm, unbounded alternate-document fetch chains vulnerability and GHSA-39gj-rchc-q5m3, unverified activity routed after dereference verification vulnerability.
The patched releases are 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0. Both vulnerabilities affect the preceding releases on those lines: 2.0.28 and 2.0.29, 2.1.24 and 2.1.25, 2.2.13 and 2.2.14, 2.3.8 and 2.3.9. If you still use Fedify 1.x, change your dependency to patched 2.x release because package-manager update commands do not cross the declared major-version range.
Unbounded alternate-document fetch chains (GHSA-97w4-f4rq-mgqm, high, CVSS 7.5)
GHSA-97w4-f4rq-mgqm affects Fedify's document loaders when fetching remote keys and ActivityPub documents. Fedify follows alternate-document links supplied through HTTP Link headers and HTML, but following an alternate document reset the redirect counter and visited-URL history. An attacker could therefore make two URLs refer to each other as alternate documents and cause Fedify to fetch them indefinitely. Following an alternate link also dropped the caller's cancellation signal, so aborting the original operation did not stop the fetch chain.
An unauthenticated inbox request could exploit this by referencing an attacker-controlled signing-key URL. Resolving the key could then enter an unbounded alternate-document chain, continuously issuing HTTP requests and DNS lookups and eventually exhausting server resources. Both getDocumentLoader() and getAuthenticatedDocumentLoader() were affected, including their use in @fedify/vocab-runtime and @fedify/fedify.
The fix makes alternate-document links and ordinary HTTP redirects share the same 20-hop limit and visited-URL history. It also preserves the caller's cancellation signal throughout the entire fetch chain. This closes a gap left by the earlier redirect-loop fix for CVE-2026-34148.
Unverified activity routed after dereference verification (GHSA-39gj-rchc-q5m3, medium, CVSS 6.5)
GHSA-39gj-rchc-q5m3 has been present since Context.routeActivity() was introduced in Fedify 1.3.0. Context.routeActivity() verifies an activity before passing it to inbox listeners. When an activity has no verifiable Object Integrity Proof, Fedify dereferences its id and verifies the fetched copy. However, only the Activity object was replaced with the verified copy; the original, unverified JSON-LD document supplied by the caller was retained.
With an inbox queue configured, that unverified document was enqueued and later delivered to inbox listeners without being verified again. An attacker who knew the ID of any dereferenceable activity could therefore submit a document with the same ID but an actor, object, and addressing of their choice, causing the application to process attacker-controlled data as authenticated. Without a queue, listeners received the verified Activity object, but their InboxContext still contained the unverified document, which InboxContext.forwardActivity() could forward to other servers.
Applications that never call Context.routeActivity() are not affected. Activities successfully authenticated using an Object Integrity Proof are also unaffected, as is the HTTP inbox, which does not use this routing path.
The fix replaces both the Activity object and its JSON-LD document with the verified copy when Context.routeActivity() falls back to dereferencing. Inbox queues, InboxContext, and forwarding therefore all operate on the same document that was actually authenticated.
Updating
Update @fedify/fedify:
npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedify
Check if your resolved dependency versions are at least 2.0.30, 2.1.26, 2.2.15, 2.3.10, or 2.4.0 on the corresponding release line. Please redeploy every Fedify-based servers, after updating.
The full Github Security Advisories are GHSA-97w4-f4rq-mgqmand GHSA-39gj-rchc-q5m3.
Thanks to @adelzaitri for reporting unverified activity is routed after dereference verification issue.
Ask below if anything is unclear.
github.com
adelzaitri - Overview
Security researcher & engineer | CISSP | Incoming PhD student in Offensive Cyber Engineering - adelzaitri
