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.

HTTP署名やWebFingerなどActivityPub実装の面倒な部分を肩代わりしてくれるTypeScript製フェデレーションフレームワーク、Fedifyの特徴からインストール、実践的な使い方までを解説します。

If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in `@fedify/fedify`: CVE-2026-77632, a high-severity server-side request forgery vulnerability in the authenticated document loader, and CVE-2026-69132, a medium-severity denial-of-service vulnerability in the outbound delivery circuit breaker. CVE-2026-77632 affects versions 1.6.1 through 2.3.4. Fedify uses an authenticated document loader when it fetches remote documents such as actors and public keys with a signed HTTP request. Affected versions checked that the initial URL was public, but did not apply the same check when that URL returned an HTTP redirect. An attacker who controlled the public URL could redirect the signed request to a loopback address, a link-local metadata service, or an RFC 1918 host. In the ordinary inbox path, Fedify may fetch a signature's `keyId` before it can verify the signature, so a bogus signature is enough to reach this path. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker. The fix validates every redirect target before it is fetched. The existing `allowPrivateAddress` option still permits private destinations when an application explicitly opts in, such as for a closed federation or test environment. CVE-2026-69132 affects versions 2.3.0 through 2.3.4. Fedify 2.3 introduced an outbound delivery circuit breaker that records failures in the configured key–value store, using the remote inbox's `host:port` as part of the key. An attacker could send signed `Follow` activities from actors whose inbox URLs pointed to distinct ports where delivery would fail. Each failure created a separate record, allowing the attacker to grow circuit-breaker state until storage or memory was exhausted. Versions 2.3.0 and 2.3.1 were vulnerable with every circuit-breaker configuration. In versions 2.3.2 through 2.3.4, the vulnerable configuration was a custom `failure` policy without an explicit `stateTtl`. The fix gives custom failure policies a bounded default `stateTtl`, equal to `recoveryDelay` plus `heldActivityTtl` (7 days 30 minutes with the default values). On stores that support compare-and-set operations, Fedify also sweeps circuit-breaker state left by affected releases and stamps it with a TTL. Applications that need a different retention period for a custom failure policy can continue to set `stateTtl` explicitly. The SSRF fix first appeared in 2.0.25, 2.1.21, 2.2.10, and 2.3.5; the circuit-breaker fix first appeared in 2.3.5. The current releases on those lines are 2.0.26, 2.1.22, 2.2.11, and 2.3.6, and those are the versions we recommend installing. The circuit-breaker issue only affects the 2.3 line; the authenticated document-loader issue affects every Fedify release from 1.6.1 through 2.3.4. If you still use Fedify 1.x, change your dependency to a current 2.x release because package-manager update commands do not cross the declared major-version range. The GitHub Security Advisories are GHSA-cxc3-7q96-6cpx and GHSA-fx98-wc5v-jrg5. Update `@fedify/fedify`: npm update @fedify/fedify yarn upgrade @fedify/fedify pnpm update @fedify/fedify bun update @fedify/fedify deno update @fedify/fedify After updating, redeploy. If you run other Fedify-based servers, update those too. Thanks to Jace and @nyanrus for the reports and responsible disclosure. If anything is unclear, ask below.

If you use Fedify, update to a patched release now. CVE-2026-62857 affects Fedify's NodeInfo client. An attacker who runs any instance your server looks up could cause that server to fetch non-public network destinations and return their contents to your application, depending on the deployment environment and network routing. Fedify can look up a remote instance's NodeInfo document to learn what software it runs. The lookup happens in two steps: it fetches the instance's `/.well-known/nodeinfo` document, then follows the NodeInfo document URL that response advertises. The vulnerable path is `getNodeInfo()`, along with the `Context.lookupNodeInfo()` method that wraps it: affected versions sent both requests without validating the destination against public-network expectations. Because that second URL comes straight out of the remote server's response body, the instance being looked up fully controls it, and could point it at a loopback address, a link-local metadata endpoint, an RFC 1918 host, or a `data:` URL. Servers are exposed only if they look up NodeInfo, but that lookup is routine for peer discovery and instance metadata. The fix routes both requests through the same public-address validation Fedify already applied to WebFinger lookups and remote document loading. Every request is now checked before it is sent, including each redirect hop, so a public URL cannot bounce a request to an internal address. Redirects are followed with a cap and are refused if they cross protocols, and non-HTTP(S) URLs such as `data:` are rejected outright. These are patch releases, so they tighten behavior without adding new API. If you deliberately look up NodeInfo on a private or intranet address, such as in a closed federation or a test environment, these releases will now refuse it. An `allowPrivateAddress` opt-out is coming in 2.4.0. Current patched releases are 1.9.13, 1.10.12, 2.0.22, 2.1.18, 2.2.7, and 2.3.2. The GitHub Security Advisory is GHSA-hqph-j65v-8cq5, and the CVE ID is CVE-2026-62857. Update `@fedify/fedify`: npm update @fedify/fedify yarn upgrade @fedify/fedify pnpm update @fedify/fedify bun update @fedify/fedify deno update @fedify/fedify After updating, redeploy. If you run other Fedify-based servers, update those too. Thanks to @rvzsec and @manus-use for the report and responsible disclosure. If anything is unclear, ask below.

A curated directory of Fedify projects, packages, examples, tutorials, and talks.

Summary Closes #561 Adds a new @fedify/debugger package that provides an embedded real-time ActivityPub debug dashboard. It works as a proxy implementing the Federation interface, wrapping the orig...

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.