洪 民憙 (Hong Minhee) :nonbinary:'s avatar

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

1,116 following1,914 followers

An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in , , , & . They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

@botkit@hackers.pub

If you use BotKit, update to a patched release now. Three vulnerabilities affect Fedify versions included by BotKit as a dependency: 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 bot's inbox as coming from any actor.

CVE-2026-96625 affects signature verification for incoming activities. Fedify verified the signature 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. No account on the receiving server was required. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs were all affected. The same flaw affected getKeyOwner() and Context.getSignedKeyOwner(), so applications using those methods for authorized fetch access control could also expose resources reserved for the impersonated 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. Fedify's built-in key cache automatically stops reading entries cached before the fix. If your application passes a custom KeyCache to verifyRequest(), verifyJsonLd(), or verifyObject(), discard its contents when upgrading: a patched process would still trust unverified ownership in a stale custom cache entry.

CVE-2026-96623 affects inbox requests and remote document fetching. Fedify parsed JSON bodies without a byte limit, including inbox bodies and fetched 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. Oversized inbox requests receive HTTP 413, and oversized WebFinger descriptors resolve to null. HTML alternate-link discovery retains its existing 1 MiB limit. The JSON limit is fixed in these patch releases, so legitimate JSON-LD documents larger than 16 MiB will now be rejected too.

CVE-2026-96624 affects outbound activity delivery to inbox URLs learned from remote actors. The delivery path checked neither the advertised inbox URL nor redirect destinations. A remote actor could point its inbox at a loopback address, a link-local cloud 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 fix validates the initial destination and every redirect target before sending a request. The authenticated document-loader fix in CVE-2026-77632, included in BotKit 0.4.6 and 0.5.2, covered a separate fetch path and did not protect outbound delivery. Applications that explicitly enable Fedify's allowPrivateAddress option continue to allow private inbox URLs and private redirect targets. Keep that option limited to testing or closed federation environments where you control the actors you federate with.

BotKit 0.4.x versions through 0.4.6 and BotKit 0.5.x versions through 0.5.3 include Fedify versions affected by all three vulnerabilities. Patched releases are BotKit 0.4.7 and 0.5.4. BotKit 0.4.7 uses Fedify 2.1.24, and BotKit 0.5.4 uses Fedify 2.3.8.

For BotKit 0.5.x, update @fedify/botkit:

npm  update  @fedify/botkit
yarn upgrade @fedify/botkit
pnpm update  @fedify/botkit
bun  update  @fedify/botkit
deno update  @fedify/botkit

For BotKit 0.4.x, update @fedify/botkit:

npm  update  @fedify/botkit@0.4.7
yarn upgrade @fedify/botkit@0.4.7
pnpm update  @fedify/botkit@0.4.7
bun  update  @fedify/botkit@0.4.7
deno update  @fedify/botkit@0.4.7

Check that your resolved Fedify version is at least 2.1.24 on the 2.1.x line or 2.3.8 on the 2.3.x line. If you depend directly on @fedify/vocab-runtime or @fedify/webfinger, update those packages too; their parsing fixes use the same patched version numbers.

After updating, redeploy. The GitHub Security Advisories are GHSA-q9f8-5hc7-898f, GHSA-mc44-6cfg-2v6w, and GHSA-f59r-8gcj-68f2. See also Fedify's own announcement.

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, feel free to ask on GitHub Discussions or Matrix.

matrix.to

You're invited to talk on Matrix

You're invited to talk on Matrix

@hongminhee@hollo.social

JSConf JP 2026で登壇することになりました。11月22日(日)、東京のベルサール神田で開催されます。

タイトルは「Oseo:SBCLスタイルのJavaScript/TypeScript AOTコンパイラ」。SBCLやChez Schemeのように、動的型付き言語でありながらプログラム全体を事前にネイティブコードへコンパイルするJavaScriptエンジンを作っている、その話をします。TypeScriptの型注釈は最適化のヒントとして使うだけで、決して鵜呑みにしない。ヒントが嘘でも動作は変わらない。そんな設計の話です。

発表は日本語、30分枠、14:10からトラックCです。詳細はこちら。

https://jsconf.jp/2026/ja/talks/hong-minhee

会場でお会いできたら嬉しいです。

jsconf.jp

Oseo:SBCLスタイルのJavaScript/TypeScript AOTコンパイラ | JSConf JP 2026

Common LispのSBCLやSchemeのChez Schemeは動的型付き言語でありながら、プログラム全体を事前にネイティブコードへコンパイルし、何十年もプロダクションで使われてきました。一方JavaScriptは今なお、速く動くにはインタプリタと複数段のJIT、その上に載るデオプティマイゼーション機構が要る言語だと見なされています。この違いはどこから来るのか。この問いから始まったプロジェクトがOseoです。 Oseoはすべての関数を二重にコンパイルします。言語のフルセマンティクスを実装するジェネリックパスが一つあり、値の種類や形状に対して安価なランタイムガードを掛けられる箇所には、その隣に特殊化されたパスを並べます。ガードが失敗すれば、バイナリの中にすでにコンパイルされているジェネリックパスへ分岐するだけです。インタプリタへ落ちることも、デオプティマイズすることもありません。TypeScriptの型表記やJSDocはこの特殊化パスを選ぶヒントとして使われますが、決して鵜呑みにされることはありません。`any`や型アサーション、素のJavaScriptとの相互運用のせいで`: number`という表記はいつでも誤りうるので、Oseoはその可能性をガードで防ぎます。 この発表では、このアイデアが実際にどう動くのかをコードとバイナリで直接お見せします。Node.jsもDenoも使わず、V8が一切リンクされていない純粋なネイティブ実行ファイルがどう作られるか。`--dump-mir`と`--emit-c`で覗いた生成コードの中で、一つのガードが実際にどんな比較と分岐にコンパイルされるか。型ヒントが実行結果を変えてはならないという原則も、同じ領域にある別プロジェクトとの具体的な比較を通じて見ていきます。 Oseoはまだ完成したプロジェクトではありません。この発表は、これまでに証明できたことと、まだ残っている道のりを一緒にお見せする場でもあります。ネイティブI/O、ガベージコレクタ、セルフホスティングまで、システムプログラミングに関心がある方なら貢献できる余地がまだたくさんあります。

FedifyのCVE-2026-96625、CVE-2026-96623、CVE-2026-96624の三件のセキュリティ脆弱性に対するセキュリティアップデートがリリースされました。速やかに2.0.28、2.1.24、2.2.13、2.3.8、またはそれ以降のバージョンにアップデートしてください。セキュリティアップデートの詳細については、こちらをご覧ください。

github.com

Fedify security updates: 2.0.28, 2.1.24, 2.2.13, and 2.3.8 · fedify-dev/fedify · Discussion #1075

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-ser...

@fedify@hackers.pub

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.

github.com

euriconicacio - Overview

Full-time pirate. 🏴‍☠️. euriconicacio has 73 repositories available. Follow their code on GitHub.

Fedify의 CVE-2026-96625, CVE-2026-96623, CVE-2026-96624 세 保安(보안) 脆弱(취약)点(점)에 對(대)한 保安(보안) 업데이트가 릴리스되었습니다. 早速히(조속히) 2.0.28, 2.1.24, 2.2.13, 2.3.8 또는 그보다 最新(최신) 버전으로 업데이트 바랍니다. 仔細(자세)한 保安(보안) 업데이트 案內(안내)는 이쪽을 參考(참고)하세요.

github.com

Fedify security updates: 2.0.28, 2.1.24, 2.2.13, and 2.3.8 · fedify-dev/fedify · Discussion #1075

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-ser...

@fedify@hackers.pub

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.

github.com

euriconicacio - Overview

Full-time pirate. 🏴‍☠️. euriconicacio has 73 repositories available. Follow their code on GitHub.

@hongminhee@hollo.social

Security updates have been released for three vulnerabilities in : CVE-2026-96625, CVE-2026-96623, and CVE-2026-96624. Please update as soon as possible to version 2.0.28, 2.1.24, 2.2.13, 2.3.8, or later. For more information about the security updates, see here.

github.com

Fedify security updates: 2.0.28, 2.1.24, 2.2.13, and 2.3.8 · fedify-dev/fedify · Discussion #1075

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-ser...

@fedify@hackers.pub

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.

github.com

euriconicacio - Overview

Full-time pirate. 🏴‍☠️. euriconicacio has 73 repositories available. Follow their code on GitHub.

@fedify@hackers.pub

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.

github.com

euriconicacio - Overview

Full-time pirate. 🏴‍☠️. euriconicacio has 73 repositories available. Follow their code on GitHub.

@hongminhee@hollo.social · Reply to tatmius(タミアス)

@tatmius もしよろしければ、月曜日の午前中に少しコーヒーでもいかがでしょうか?ご予定があれば、どうぞ遠慮なくお断りください!ただ、日本語は読む・書くのに比べて会話が苦手なので、少しもどかしい思いをさせてしまうかもしれません。

@hongminhee@hollo.social

最近、ハンバーグ嘉がソウルにも開店した。ちょうど家の近くなので、昨日を除いて先週の土曜日から今日まで毎日通っている。今も夕食を食べに来ている。

instagram.com

ハンバーグ 嘉 Hamburg Yoshi on Instagram: "ハンバーグ嘉 🌳🇰🇷 "韓国 ソウルの森" 🇰🇷🌳 @hamburgyoshi_korea 📢 1月10日プレオープン ✨ 📢 1月13日グランドオープン ✨ ハンバーグ嘉 海外1号店がついに! ソウルの森にオープンです! 日本で修行をした職員が、 日本と同様炭火で美味しく焼き上げます。🔥 日本からも応援に4名が駆けつけ、 一緒に韓国のお客様をお迎えします! 良いオープンニングになるように盛り上げて行きます🥰 10日~12日のプレオープンも、 どなたでもお越しいただけます。 プレオープンの際は、 何かと不手際がありご迷惑をおかけすることもあるかと存じますが、 暖かい目で見守っていただけると幸いです。 みなさまのソウル店へのご来店をお待ちしております。 スタッフ一同 ━━━━━━━━━━ 일본 최고 함바그 맛집 <YOSHI> 🌳 "한국 서울숲" 🌳 @hamburgyoshi_korea   🔈 1월 10일 프리오픈 ✨ 🔈 1월 13일 그랜드 오픈 ✨ 도쿄 시부야에서 줄서서 먹는 햄버거집 YOSHI가 드디어 서울의 숲에 오픈합니다! 일본에서 연수한 직원이 맛있게 구워드립니다.🇯🇵 일본에서는, 일본에서도 많은 직원들이 왔습니다! 한국 매장이 더욱 활성화되기를 기원합니다!🔥🔥🔥 10일~12일 프리 오픈은 누구나 방문하실 수 있습니다.✨ 프리오픈 기간 중에는 다소 불편한 점이 있을 수 있으니 양해해 주시기 바랍니다. 즐거운 식사 시간이 될 수 있도록 최선을 다하겠습니다! 🙇 여러분의 서울점 방문을 기다리겠습니다. 주소 : 서울시 성동구 서울숲6길 22, 1층 ━━━━━━━━━━ YOSHI Hamburg 🌳🇰🇷 Seoul Forest, Korea 🇰🇷🌳 @hamburgyoshi_korea 🔈 Pre-opening on January 10 ✨ 🔈 Grand opening on Jan. 13 ✨ YOSHI, the hamburger restaurant with a long queue in Shibuya, Tokyo finally opened in Seoul Forest, Seoul, Korea ‼️ The staff trained in Japan will cook delicious hamburgers. Anyone can come to the pre-opening on Jan. 10~12. Please you understand that there may be some inconvenience during the pre-opening. We will do our best to make this an enjoyable meal time! 🙇✨ We look forward to seeing you at our Seoul store."

235 likes, 4 comments - hamburg__yoshi on January 8, 2024: "ハンバーグ嘉 🌳🇰🇷 "韓国 ソウルの森" 🇰🇷🌳 @hamburgyoshi_korea 📢 1月10日プレオープン ✨ 📢 1月13日グランドオープン ✨ ハンバーグ嘉 海外1号店がついに! ソウルの森にオープンです! 日本で修行をした職員が、 日本と同様炭火で美味しく焼き上げます。🔥 日本からも応援に4名が駆けつけ、 一緒に韓国のお客様をお迎えします! 良いオープンニングになるように盛り上げて行きます🥰 10日~12日のプレオープンも、 どなたでもお越しいただけます。 プレオープンの際は、 何かと不手際がありご迷惑をおかけすることもあるかと存じますが、 暖かい目で見守っていただけると幸いです。 みなさまのソウル店へのご来店をお待ちしております。 スタッフ一同 ━━━━━━━━━━ 일본 최고 함바그 맛집 <YOSHI> 🌳 "한국 서울숲" 🌳 @hamburgyoshi_korea   🔈 1월 10일 프리오픈 ✨ 🔈 1월 13일 그랜드 오픈 ✨ 도쿄 시부야에서 줄서서 먹는 햄버거집 YOSHI가 드디어 서울의 숲에 오픈합니다! 일본에서 연수한 직원이 맛있게 구워드립니다.🇯🇵 일본에서는, 일본에서도 많은 직원들이 왔습니다! 한국 매장이 더욱 활성화되기를 기원합니다!🔥🔥🔥 10일~12일 프리 오픈은 누구나 방문하실 수 있습니다.✨ 프리오픈 기간 중에는 다소 불편한 점이 있을 수 있으니 양해해 주시기 바랍니다. 즐거운 식사 시간이 될 수 있도록 최선을 다하겠습니다! 🙇 여러분의 서울점 방문을 기다리겠습니다. 주소 : 서울시 성동구 서울숲6길 22, 1층 ━━━━━━━━━━ YOSHI Hamburg 🌳🇰🇷 Seoul Forest, Korea 🇰🇷🌳 @hamburgyoshi_korea 🔈 Pre-opening on January 10 ✨ 🔈 Grand opening on Jan. 13 ✨ YOSHI, the hamburger restaurant with a long queue in Shibuya, Tokyo finally opened in Seoul Forest, Seoul, Korea ‼️ The staff trained in Japan will cook delicious hamburgers. Anyone can come to the pre-opening on Jan. 10~12. Please you understand that there may be some inconvenience during the pre-opening. We will do our best to make this an enjoyable meal time! 🙇✨ We look forward to seeing you at our Seoul store.".

@tatmius@vivaldi.net

大韓民国歴史博物館、韓国近代史観を知るにはかなりよかった。思ってるより最近まで政治は全然色々あって、大変やなぁという感じ。

@hongminhee@hollo.social · Reply to Jeff

@box464 Yeah, October 1st is too tight; I can't promise v0.6.0 by then. Moving somewhere else first makes sense. Mastodon's 30-day migration cooldown only applies to the account that moved, so your new account can move to a BotKit bot once 0.6 ships. I'll let you know when it's out. Thanks for being willing to try it!

@hongminhee@hollo.social · Reply to Jeff

@box464 Thanks for this post! It gave me an idea for a new BotKit feature: letting an existing account move its followers to a bot.

BotKit 0.6.0 should be out in early to mid October, and I expect it to include fedify-dev/botkit#48, which is what your move needs. Could you wait until then?

If things go well and I find the time, v0.6.0 might even cover everything under fedify-dev/botkit#47. Please don't count on that part, though.

github.com

Support account migration (FEP-7628) · Issue #47 · fedify-dev/botkit

BotKit has no notion of account migration. A bot's actor object carries no alsoKnownAs, the inbox listener chain has no handler for Move, and a bot has no way to point its followers somewhere else....

@julian@fietkau.social · Reply to Chuckles

@celeduc Good timing, @hongminhee just recently published a proposal for what you're asking: hollo.social/@hongminhee/01a0a

I would describe this as mature work on the protocol level, but no one can know in advance when (or if ever) it'll be added to other popular ActivityPub platforms.

hollo.social

I've been working on a <abbr t…

I've been working on a <abbr title="Fediverse Enhancement Proposal">FEP</abbr> draft for the past few days: [FEP-22cd Attributing translations][draft PR]. [Hackers' Pub] already machine-translates articles, but I want authors to be able to publish their own translations too, and let organizations split the work across members. Once you do that, Activity Streams doesn't give you much to work with. `attributedTo` names an author, not a translator. Nothing distinguishes a language a human translated from one an AI produced. And nothing says whether a translation still matches the current text or was written against an older version of the article. [Schema.org] already has [`translator`], [`translationOfWork`], and [`inLanguage`] for exactly this, so the FEP mostly reuses those instead of minting new vocabulary. I had to decide whether to give each language its own object, linked back to the original, or keep everything on one object the way `contentMap` already does. Splitting it looked cleaner at first, but it also means spreading replies and reactions across separate posts for each translation. I don't want adding a translation to split the conversation. I kept everything on one object, using `contentMap` for the text in each language. The draft adds a `translations` property to record who translated each version and whether it was translated by a human, generated by a machine, or generated by a machine and reviewed by a human. A timestamp lets you tell whether a translation still matches the current text, without publishing the server's private edit history. You can discuss it on [SocialHub] or in the [draft PR]. If you run anything that touches multilingual content, I'd like to hear where this breaks. [draft PR]: https://codeberg.org/fediverse/fep/pulls/922 [Hackers' Pub]: https://hackers.pub/ [Schema.org]: https://schema.org/ [`translator`]: https://schema.org/translator [`translationOfWork`]: https://schema.org/translationOfWork [`inLanguage`]: https://schema.org/inLanguage [SocialHub]: https://socialhub.activitypub.rocks/t/fep-22cd-attributing-translations/8897

@celeduc@mastodon.social

Casually deciphering posts in languages I don't know is enjoyable and is good mental exercise. I'm glad it doesn't automatically translate everything.

That having been said, sometimes I'd like to publish multilingual posts where I control the translation, the same way you can publish different subtitles for a video (or use automated translation). Same for alt text.

This may be the thing that motivates me to learn something about

@2chanhaeng@hackers.pub

For non-Korean gamers:

TL;DR: This game is a piece of trash that glorifies Park Chung-hee, the Korean Hitler. Please report this game.

This store page casts Park Chung-hee as a potential "father of a nation" and frames his coup as "national renewal," but never mentions his regime's abuses: about 1,770 "vagrants" were held for unpaid forced labor in Seosan, with beatings and forced mass weddings; the 1972 Yushin Constitution allowed unlimited re-election, and its key emergency decrees were ruled unconstitutional; in 1979 martial law troops crushed the Bu-Ma protests, arresting 1,058.

Sources:

hackers.pub

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

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

@2chanhaeng@hackers.pub

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

스팀에서 발견된 박정희 미화한 게임.
ALT text

스팀에서 발견된 박정희 미화한 게임.

@2chanhaeng@hackers.pub

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

스팀에서 발견된 박정희 미화한 게임.
ALT text

스팀에서 발견된 박정희 미화한 게임.

@hongminhee@hollo.social

今年(금년) 中(중)에 日本(일본) 한 番(번) 가고 싶은데, 갈 理由(이유)가 딱히 없다… JSConf JP 2026 發表(발표)도 떨어졌고… 😂

@nnanananami@planet.moe

일본 페미니스트들 “천황제에 종지부를” 집회 연 이유 ildaro.com/10545
"그런데, 일본의 페미니스트들 사이에서는 다른 목소리가 제기되었다. 여성도 천황이 될 수 있게 해 달라는 게 아니라, 애초에 혈통과 성별에 따라 누군가의 지위와 삶을 규정하는 천황제를 유지해선 안 된다는 것이다."

ildaro.com

일본 페미니스트들 “천황제에 종지부를” 집회 연 이유 | 일다

일본 국회는 7월 17일 황족 수 확보를 위한 개정 황실전범을 통과시켰다. 1947년 현행 황실전범 시행 이후 처음 이뤄진 개정법의 핵심은 두 가지다. 첫째는

@bootlegrydia@treehouse.systems

I'm 92%

however it seems the questionnaire lacks some "neutral" options

like the 7th question about housing prices, the "curb speculative demands" option might slide into "curb foreign nationals" kind of xenophobia

also how I view "a person with different political leaning become my child's spouse" well I don't have a child but it's my child's choice anyway and I don't think I have the power to interfere

the "gender" options also don't contain "non-binary" but I don't expect that much out of an east-asian society

hollo.social

《한겨레》에서 만든 〈나는 얼마나 進步 或은 保守일까?…

《한겨레》에서 만든 〈나는 얼마나 進步 或은 保守일까?〉 테스트를 해 봤는데, 「全國民 中 99%보다 進步 性向입니다」라고 떴다. https://policy-survey-2026.hani.co.kr/results?s=0015yJot

@hongminhee@hollo.social

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

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

《한겨레》 〈나는 얼마나 進步 혹은 保守일까?〉 檢查 結果 畫面. 全體 調查 應答者 中 1/100, 30代 男性 中 1/100, 더불어民主黨 投票層 中 3/100으로 「全國民 中 99%보다 進步 性向」이라는 文句와 함께, 左右 軸의 맨 左側(進步) 끝에 「나」의 位置가 表示된 막대그래프.
ALT text

《한겨레》 〈나는 얼마나 進步 혹은 保守일까?〉 檢查 結果 畫面. 全體 調查 應答者 中 1/100, 30代 男性 中 1/100, 더불어民主黨 投票層 中 3/100으로 「全國民 中 99%보다 進步 性向」이라는 文句와 함께, 左右 軸의 맨 左側(進步) 끝에 「나」의 位置가 表示된 막대그래프.

@hongminhee@hollo.social

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

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

《한겨레》 〈나는 얼마나 進步 혹은 保守일까?〉 檢查 結果 畫面. 全體 調查 應答者 中 1/100, 30代 男性 中 1/100, 더불어民主黨 投票層 中 3/100으로 「全國民 中 99%보다 進步 性向」이라는 文句와 함께, 左右 軸의 맨 左側(進步) 끝에 「나」의 位置가 表示된 막대그래프.
ALT text

《한겨레》 〈나는 얼마나 進步 혹은 保守일까?〉 檢查 結果 畫面. 全體 調查 應答者 中 1/100, 30代 男性 中 1/100, 더불어民主黨 投票層 中 3/100으로 「全國民 中 99%보다 進步 性向」이라는 文句와 함께, 左右 軸의 맨 左側(進步) 끝에 「나」의 位置가 表示된 막대그래프.