Fedify security updates: 2.0.28, 2.1.24, 2.2.13, and 2.3.8 #1075
dahlia
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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()andContext.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
KeyCacheimplementation toverifyRequest(),verifyJsonLd(), orverifyObject(), 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-runtimeand@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: truetocreateFederation(). 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: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-runtimeand@fedify/webfingeras 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.
All reactions