はじめに：なぜフロントエンドエンジニアがこの脆弱性に関心を持つべきなのか

分散型Web（Web3、Fediverseなど）の発展に伴い、ActivityPubのようなプロトコルや、その基盤となるJSON-LD（JSON for Linking Data）を目にする機会が増えています。特にActivityPubは、マストドンやBluesky（AT Protocol）など、多くの分散型SNSで採用されており、私たちの開発するアプリケーションがこれらのサービスと連携する場面も少なくありません。今回ご紹介するGHSA-9rfg-v8g9-9367 / CVE-2026-42462の脆弱性は、このJSON-LDの「署名検証」に関するもので、一見バックエンド寄りの問題に見えるかもしれませんが、データの完全性やユーザー体験に直接影響するため、フロントエンドエンジニアもその仕組みとリスクを理解しておくことが非常に重要です。

この脆弱性が悪用されると、ユーザーの意図しない情報公開、データ改ざん、なりすましといった重大な問題が発生する可能性があります。あなたのアプリケーションが表示する情報が、実は悪意のある改ざんされたデータかもしれない――そう考えると、他人事ではないはずです。

脆弱性の概要：JSON-LD署名の欺瞞

この脆弱性は、Fedify（および関連プロジェクト）が採用しているLinked Data Signature（LD-Signature）の検証ロジックに起因します。LD-Signatureは、JSON-LDドキュメントの内容が正当であることを保証するためのデジタル署名メカニズムです。しかし、JSON-LDの持つ「同じ意味のデータを複数の異なる表現形式で記述できる」という特性が、この検証プロセスを複雑にし、脆弱性の温床となってしまいました。

具体的には、攻撃者は署名済みのJSON-LDドキュメントの構造を巧妙に操作することで、署名自体は有効なまま、システムに誤った内容を解釈させることができます。これにより、署名されたメッセージの「意味」が、本来の意図とは全く異なるものとして処理されてしまうのです。これは、情報の真正性、完全性、否認防止というデジタル署名が果たすべき重要な役割を根本から揺るがす問題と言えます。

具体的な攻撃シナリオ：何がどう悪用されるのか？

JSON-LDの高度な機能である`@graph`や`@reverse`は、複雑なRDFグラフ構造を表現するために使用されます。攻撃者はこれを悪用し、署名済みのアクティビティ（例：ActivityPubのメッセージ）において、本来のトップレベルのアクティビティを隠し、その中に埋め込まれた別のアクティビティをシステムにトップレベルとして認識させることができます。

例えば、ユーザーが「投稿を取り消す（Undo）」という署名済みのアクティビティを送信したとします。攻撃者はこのメッセージの中に、実は「投稿を公開する（Announce）」という別のアクティビティ情報を巧妙に埋め込みます。脆弱性のあるシステムは「Undo」の部分を無視し、「Announce」として処理してしまうため、ユーザーの意図に反して、過去の投稿が勝手に公開されてしまうといった、なりすまし行為が可能になります。

`@included`は、関連するオブジェクトをドキュメントに含めるためのキーワードです。この脆弱性を利用すると、攻撃者は署名済みの「作成（Create）」や「更新（Update）」アクティビティから、投稿内容やメタデータといった特定の重要なプロパティを削除したり隠蔽したりすることができます。システムは署名が有効であると判断してしまうため、本来の情報が欠落または改ざんされた状態でメッセージを受け取り、処理してしまいます。これにより、データの完全性や可用性が損なわれるリスクがあります。

最も深刻なのは、署名検証後のJSON-LDドキュメントが、システムが期待する標準的な形式（ローカルコンテキスト）に「コンパクト化」されていない場合です。JSON-LDは、キーワードにエイリアス（別名）を設定できるため、同じ意味を持つデータを様々な形で表現できます。コンパクト化が適切に行われないと、攻撃者はこのエイリアスの柔軟性を悪用し、非標準のエイリアスを使って既存の値を意図せず置き換えたり、メッセージのあらゆる部分を自由に書き換えたりすることが可能になります。

これにより、攻撃者は任意のActivityを完全に偽装し、メッセージの完全性や可用性だけでなく、例えばアクターの受信箱（inbox）情報の書き換えなど、機密性に関わる非常に重大な問題まで引き起こす可能性があります。これは過去にMastodonでも同様の問題が修正された経緯があり、分散型SNSエコシステムにおける根深い課題の一つです。

影響範囲とリスク

この脆弱性は深刻度「high」と評価されており、情報漏洩、なりすまし、データ破壊といった広範なリスクをシステムにもたらします。特にFediverseエコシステムのような、ActivityPubをベースとした分散型アプリケーションでは、ユーザーの投稿、フォロー、いいねといったあらゆるアクティビティがJSON-LDで表現され、署名によってその正当性が保証されています。この署名が簡単に欺瞞されるとなると、エコシステム全体の信頼性が根底から揺らぎかねません。

日本のフロントエンドエンジニアが取るべき対応策

「うちはFedifyを使ってないから関係ない」と思われた方もいるかもしれません。しかし、あなたのアプリケーションが何らかの形でActivityPubやJSON-LDを処理するバックエンドと連携している場合、間接的にこの問題の影響を受ける可能性があります。また、将来的に分散型Webアプリケーションの開発に関わる可能性も考慮し、以下の対応策や知識を共有・蓄積していくことが重要です。

ActivityPubのペイロードでは通常使用されず、処理が複雑になりがちな`@graph`、`@included`、`@reverse`といったJSON-LDの高度な機能を含むアクティビティは、**受信時に拒否する**ことを強く推奨します。これらのキーワードの検出は、受信したアクティビティをシステムが解釈する標準的なローカルコンテキストに一度「コンパクト化」した後に行ってください。これは、エイリアスが使用されている可能性があるため、元の形式でチェックするだけでは不十分だからです。

最も重要な対策の一つは、**署名が検証されたJSON-LDドキュメントであっても、必ずシステムが期待するローカルコンテキストにコンパクト化すること**です。これにより、攻撃者によるエイリアスの悪用や、非標準の記述による値の不正な書き換えを防ぎ、メッセージの整合性を確保することができます。このステップを怠ると、たとえ署名自体は有効であっても、解釈される内容が全く異なるものになるリスクがあります。

FedifyやJSON-LD関連のライブラリを使用している場合は、常に最新バージョンに更新し、公式からリリースされるセキュリティアナウンスに注意を払ってください。また、もしご自身でJSON-LDのパーシングや処理ロジックを実装している場合は、上記の問題点を踏まえ、セキュリティベストプラクティスに従っているか徹底的にレビューすることが求められます。

まとめ

GHSA-9rfg-v8g9-9367 / CVE-2026-42462は、JSON-LDの柔軟性がセキュリティリスクに転じる可能性を示した、非常に示唆に富む脆弱性です。フロントエンドエンジニアとして、私たちは単にデータを表示するだけでなく、そのデータの信頼性、完全性、そしてそれがどのように生成・伝達されているかについて、より深く理解していく必要があります。特に分散型Webの分野では、セキュリティはバックエンドだけの責任ではなく、システム全体で意識すべき共通の課題であることを再認識し、安全なアプリケーション開発に貢献していきましょう。