If you use an affected Fedify release, update now. Two server-side request forgery vulnerabilities have been addressed: GHSA-r48c-xx2h-fv4g, a DNS rebinding bypass of Fedify's private address checks, and GHSA-cj5r-cw77-6gwp, unvalidated page and favicon requests in `fedify nodeinfo`. Deno deployments need additional network restrictions; upgrading Fedify alone does not close the DNS rebinding vulnerability. The patched releases are 2.0.35, 2.1.31, 2.2.20, 2.3.15, and 2.4.5. Update to the corresponding release on your minor line, with the runtime mitigations described below. The affected releases on these lines are 2.0.34 and earlier, 2.1.30 and earlier, 2.2.19 and earlier, 2.3.14 and earlier, and 2.4.4 and earlier. For ongoing support, the security policy covers the latest two minor lines, 2.3 and 2.4. Users on releases before 2.0 should move to a supported release. ## DNS rebinding bypasses SSRF protection (GHSA-r48c-xx2h-fv4g, medium, CVSS 5.4) Fedify checked that a hostname resolved only to public addresses, then let `fetch()` resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection, causing requests to reach internal services. Redirects and alternate-document links were subject to the same gap. This affects document loading, including authenticated document loading, outbound activity delivery, NodeInfo lookups, and WebFinger lookups in `@fedify/fedify`, `@fedify/vocab-runtime`, and `@fedify/webfinger`. On Node.js and Bun, the fix makes connections only to addresses that passed validation. Calling `validatePublicUrl()` before an application's own `fetch()` still does not pin that connection. Setting `allowPrivateAddress: true` continues to permit private destinations. On Bun, deployments with `HTTP_PROXY`, `HTTPS_PROXY`, or `ALL_PROXY` set, including their lowercase forms, should upgrade to Bun 1.4.3 or later. Alternatively, unset those variables for the Fedify process or configure the proxy to refuse private destinations. Older Bun versions may send requests through a proxy that resolves the hostname again. On Bun versions before 1.3.11, Fedify now refuses HTTPS requests to non-default ports because those Bun versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance. Deno's `fetch()` cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented `--deny-net` list and a Unix domain socket behind a reverse proxy, plus network-level restrictions for private IPv6 ranges. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation. ## Unvalidated page and favicon requests (GHSA-cj5r-cw77-6gwp, low, CVSS 3.1) An operator running `fedify nodeinfo` against a malicious instance could cause the CLI to send a GET request to a loopback, link-local, or private address from the operator's machine. The NodeInfo lookup validated destinations, but the subsequent page and favicon requests used plain `fetch()` with automatic redirects. A malicious favicon URL or page redirect could therefore reach an internal endpoint. The attacker does not directly receive the response body, but the request can affect an internal endpoint with GET side effects. The fix validates page, favicon, and redirect destinations, skipping the favicon when a destination is private while still showing the NodeInfo document. Upgrade `@fedify/cli` separately from the library. Until then, `--no-favicon` or `--raw` avoids these page and favicon requests. The Bun and Deno caveats above also apply to the CLI. ## Updating Use the command for your package manager to install 2.4.5 explicitly: npm install @fedify/fedify@2.4.5 yarn add @fedify/fedify@2.4.5 pnpm add @fedify/fedify@2.4.5 bun add @fedify/fedify@2.4.5 deno add jsr:@fedify/fedify@2.4.5 If you stay on another minor line, substitute `2.0.35`, `2.1.31`, `2.2.20`, or `2.3.15` as appropriate. Update direct dependencies on `@fedify/vocab-runtime` and `@fedify/webfinger` to the same release as well. Check the resolved versions in your lockfile, since an ordinary update command can stay within a vulnerable dependency range or leave a transitive dependency locked. Apply the runtime mitigations above and redeploy all web and worker processes. For an npm-installed global CLI: npm install -g @fedify/cli@2.4.5 For other installation methods, reinstall the corresponding patched version using the CLI installation instructions. Check `fedify --version` before using it against an untrusted instance. Thanks to @finalchild for reporting the DNS rebinding issue and to Zachariah Mithani for reporting the favicon request issue. If anything is unclear, ask below.

If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in `@fedify/fedify`: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a flaw in the key ownership check that could authenticate activities as the wrong actor under specific actor-document configurations. The releases containing both fixes are 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4. We recommend 2.4.4, or 2.3.14 if you are staying on the 2.3 line. Under the security policy, Fedify supports the latest two minor lines, currently 2.4 and 2.3. Backported fixes are also available in the releases listed above for 2.0, 2.1, and 2.2, but users on those older lines should plan to move to a supported line. Users on affected 1.x releases need to change their dependency to a supported 2.x release. ## Inbox activity origin mismatch (GHSA-4qhx-hhwf-8685, medium, CVSS 6.5) GHSA-4qhx-hhwf-8685 affects applications receiving activities through Fedify's inbox listeners. The inbox authenticated an activity's actor but accepted an activity `id` on an origin different from the actor's. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim. Since version 1.9.0, Fedify's property accessors have trusted embedded objects whose IDs share the activity's origin. By choosing an activity ID on a victim server's origin, an attacker could make `Create.getObject()` and other accessors return forged objects claiming to live on that server without fetching them from it. Depending on the application's attribution and authorization checks, this could cause it to store or display forged content under another server's object ID. The same missing check also let an attacker reserve a genuine activity's idempotency cache entry by submitting a forged activity with its ID first. The genuine delivery then received `202 Accepted` but did not reach the listeners for one day. When a message queue was configured, the suppression applied across all inboxes on the receiving server. This behavior was confirmed in 1.8.15 and subsequent releases before the fixes; releases before 1.8 were not tested. The first fixes shipped in 2.0.33, 2.1.29, 2.2.18, 2.3.13, and 2.4.3. Earlier releases on each of those 2.x lines are affected. Update to the newer releases recommended above to receive both fixes. The inbox now returns `401 Unauthorized` for non-portable activities whose IDs have a different origin from their actors, before they reach listeners, the queue, or the idempotency cache. The same origin check applies to queued and manually routed activities. Setting `skipSignatureVerification` bypasses this protection along with signature verification. ## Actor document identity mismatch (GHSA-8863-8468-7hq7, medium, CVSS 5.9) GHSA-8863-8468-7hq7 lists the affected version range as `<= 2.4.3`, with fixes in 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 on their respective release lines. When confirming that a key belongs to an actor, Fedify fetched the actor's document and checked that it listed the key, but did not require the document's `id` to match the actor ID it requested. An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link to the attacker's document, including on another origin, or when the victim's server directly served a different same-origin actor's document. The attacker cannot normally arrange this: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. No account on the receiving Fedify server is required. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's `id` to exactly match the requested actor ID, in addition to the existing origin check. An actor whose ID redirects to a document with a different `id` can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Servers that normalize actor URLs should use the canonical actor ID as their keys' `owner` or `controller` and their activities' `actor`. The built-in `KvStore`-backed key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If you supply a custom `KeyCache` implementation, clear it once when upgrading. Otherwise, previously cached false ownership claims can remain trusted after the upgrade. Downgrading to an earlier release is not safe. ## Updating Update `@fedify/fedify` using the command for your package manager: npm update @fedify/fedify yarn upgrade @fedify/fedify pnpm update @fedify/fedify bun update @fedify/fedify deno update @fedify/fedify Check the installed or locked version: it should be 2.0.34, 2.1.30, 2.2.19, 2.3.14, or 2.4.4 on the corresponding line. Update commands can stay within your declared dependency range. If that range excludes the recommended release, change it explicitly. For example, to move to 2.4.4: npm install @fedify/fedify@2.4.4 yarn add @fedify/fedify@2.4.4 pnpm add @fedify/fedify@2.4.4 bun add @fedify/fedify@2.4.4 deno add jsr:@fedify/fedify@2.4.4 Clear any custom key cache as described above, then redeploy. If you run other Fedify-based servers, update those too. The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7. Thanks to @2chanhaeng for reporting the inbox activity origin mismatch. The actor document identity mismatch was found by the Fedify maintainers with AI assistance. If anything is unclear, ask below.

Critical security vulnerabilities have been patched in the `@fedify/fedify` package, addressing flaws in inbox origin validation and actor key ownership verification. The first vulnerability, GHSA-4qhx-hhwf-8685, allowed attackers to provide forged embedded objects or suppress genuine activities through idempotency cache abuse due to missing origin checks between activity IDs and their actors. The second vulnerability, GHSA-8863-8468-7hq7, allowed improper authentication under specific actor document redirect or alternate-document configurations when dereferencing keys. Fixes have rolled out across versions 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4, enforcing strict origin matching and document ID equality while automatically invalidating affected built-in cache entries. Upgrading immediately and clearing any custom key caches is essential to protecting Fedify-powered federated applications from activity suppression and identity spoofing.

Critical security vulnerabilities have been patched in the `@fedify/fedify` package, addressing flaws in inbox origin validation and actor key ownership verification. The first vulnerability, GHSA-4qhx-hhwf-8685, allowed attackers to provide forged embedded objects or suppress genuine activities through idempotency cache abuse due to missing origin checks between activity IDs and their actors. The second vulnerability, GHSA-8863-8468-7hq7, allowed improper authentication under specific actor document redirect or alternate-document configurations when dereferencing keys. Fixes have rolled out across versions 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4, enforcing strict origin matching and document ID equality while automatically invalidating affected built-in cache entries. Upgrading immediately and clearing any custom key caches is essential to protecting Fedify-powered federated applications from activity suppression and identity spoofing.

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.

If you use an affected Fedify release, update now. Three vulnerabilities have been fixed: CVE-2026-96625, a critical actor impersonation vulnerability; CVE-2026-96623, a high-severity denial-of-service vulnerability in remote document parsing; and CVE-2026-96624, a medium-severity server-side request forgery vulnerability in outbound activity delivery. Treat the actor impersonation issue as an immediate upgrade: anyone on the internet could have an activity accepted by your inbox as coming from any actor. The patched releases are 2.0.28, 2.1.24, 2.2.13, and 2.3.8. All three vulnerabilities affect the preceding releases on those lines: 2.0.27, 2.1.23, 2.2.12, and 2.3.7, respectively. If you still use Fedify 1.x, change your dependency to a patched 2.x release because package-manager update commands do not cross the declared major-version range. ## Actor impersonation (CVE-2026-96625, critical, CVSS 9.1) CVE-2026-96625 has been present since Fedify's first public release, 0.1.0. Fedify verified the signature on an incoming activity, but trusted the signing key document's own claim about whom the key belonged to. An attacker with an ordinary HTTP server could serve a key document naming any actor as its owner and have activities accepted under that actor's identity, even if the actor did not exist. No account on the receiving server was required. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs were all affected; the latter two did not require an HTTP signature on the request. The same vulnerability affected `getKeyOwner()` and `Context.getSignedKeyOwner()`. A forged key document could pass ownership checks under another actor's identity, allowing an attacker to read resources that an application's authorized fetch access control reserved for that actor. The fix resolves the claimed owner's actor document and requires it to link back to the key. It also validates the origin of fetched actor documents, so a host serving a key cannot speak for an actor on another origin. A key without an explicit owner is attributed to the actor whose document carried it. Public keys cached before this release recorded ownership that had not been verified. Fedify's built-in key cache automatically stops reading those entries. If you pass a custom `KeyCache` implementation to `verifyRequest()`, `verifyJsonLd()`, or `verifyObject()`, discard its contents when you upgrade. A patched process reading a stale entry from a custom cache would still trust the unverified owner in it. ## Unbounded document parsing (CVE-2026-96623, high, CVSS 7.5) CVE-2026-96623 affects deployments that accept inbox requests or fetch remote documents. Fedify parsed JSON bodies without a byte limit, including inbox bodies and responses fetched for keys, actors, objects, JSON-LD contexts, WebFinger descriptors, and NodeInfo documents. An attacker who caused Fedify to fetch a URL they controlled could exhaust memory and CPU with a large response. A small compressed response could expand substantially before parsing, so an inbound body limit at a reverse proxy did not protect the outbound fetch paths. The fix limits JSON bodies to 16 MiB after decompression. HTML alternate-link discovery retains its existing 1 MiB limit. Oversized inbox requests receive HTTP 413, and oversized WebFinger descriptors resolve to `null`. The JSON limit is fixed in these patch releases; applications that exchange legitimate JSON-LD documents larger than 16 MiB will now have those documents rejected. The parsing fixes also ship in `@fedify/vocab-runtime` and `@fedify/webfinger`. If you depend on either package directly, update it too. They use the same patched version numbers listed above. ## Outbound delivery SSRF (CVE-2026-96624, medium, CVSS 5.8) CVE-2026-96624 affects applications that deliver activities to inbox URLs learned from remote actors. The delivery path validated neither the advertised inbox URL nor redirect destinations. A remote actor could point its inbox at a loopback address, a link-local metadata service, or a private network host, or redirect delivery there. On the RSA delivery path, the redirected request remained a POST carrying the activity body and was re-signed for the internal host. The vulnerable delivery path dates back to JSR release 0.1.0 and npm release 0.5.0. The fix validates the initial destination and every redirect target before sending a request. The authenticated document-loader fix in CVE-2026-77632 covered a separate fetch path and did not protect outbound activity delivery. If you deliberately deliver to private addresses for local testing or a closed federation, these releases will refuse those deliveries unless you pass `allowPrivateAddress: true` to `createFederation()`. That option permits both private inbox URLs and private redirect targets, restoring the exposure described here. Keep it to environments where you control the actors you federate with. ## 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 that your resolved dependency versions are at least 2.0.28, 2.1.24, 2.2.13, or 2.3.8 on the corresponding release line. Update any direct dependencies on `@fedify/vocab-runtime` and `@fedify/webfinger` as well, and clear any custom key cache as described above. After updating, redeploy. If you run other Fedify-based servers, update those too. The full GitHub Security Advisories are CVE-2026-96625, CVE-2026-96623, and CVE-2026-96624. Thanks to @kaimandalic and @moreal for independently reporting the actor impersonation issue. Thanks also to @kaimandalic for the unbounded document parsing report and @euriconicacio for the outbound delivery SSRF report, and to all three for responsible disclosure. If anything is unclear, ask below.