洪 民憙 (Hong Minhee)

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.

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.

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.

스팀에서 박정희 미화물을 발견했습니다. 혹시 가능하시다면 박정희가 저지른 만행과 그 출처를 담아 신고 부탁 드립니다.

《한겨레》에서 만든 〈나는 얼마나 進步(진보) 或은(혹은) 保守(보수)일까?〉 테스트를 해 봤는데, 「全(전)國民(국민) 中(중) 99%보다 進步(진보) 性向(성향)입니다」라고 떴다.

https://policy-survey-2026.hani.co.kr/results?s=0015yJot

This FEP draft proposes translation credits for language-tagged Activity Streams objects. The metadata records who translated the text into each language and whether the translation was machine-assisted or human-reviewed. It also tracks how up to date each translation is with the source. Servers don't have to expose their private revision history.

It grew out of [Hackers' Pub]'s work on letting authors publish their own article translations.

https://codeberg.org/fediverse/fep/pulls/922

Feedback welcome, thanks!

[Hackers' Pub]: https://hackers.pub/

This FEP draft proposes translation credits for language-tagged Activity Streams objects. The metadata records who translated the text into each language and whether the translation was machine-assisted or human-reviewed. It also tracks how up to date each translation is with the source. Servers don't have to expose their private revision history.

It grew out of [Hackers' Pub]'s work on letting authors publish their own article translations.

https://codeberg.org/fediverse/fep/pulls/922

Feedback welcome, thanks!

[Hackers' Pub]: https://hackers.pub/