C2PAの証明書検証に修正｜Content Credentials SDKを使うWebサイトの確認点

画像や動画の来歴を表示する機能は、情報を信頼する手掛かりになります。しかし、その検証に使うソフトウェアが証明書を正しく扱えなければ、表示する信頼の根拠も揺らぎます。Content Credentials SDKを組み込むWeb開発者は、画像ファイルだけでなく検証する側の版を確認する必要があります。

Adobeは2026年10月13日、Content Credentials SDKのセキュリティ更新を公表しました。JVN iPediaは10月16日、証明書検証に関するCVE-2026-100122を掲載しています。本記事の情報確認日は10月18日です。公表日、国内データベースへの掲載日、確認日は異なり、10月18日に新しい事件が発生したという意味ではありません。

まず確認できた事実を限定する

AdobeのAPSB26-163は、証明書検証などに関わる複数の修正を含みます。本記事は主にCVE-2026-100122を取り上げます。Adobeはこの問題を不適切な証明書検証によるセキュリティ機能の迂回として扱い、CVSS v3.1の基本値を7.5としています。JVN iPediaにも同じ基本値が掲載されています。

Adobeは公表した更新について、実環境での悪用を認識していないと記しています。これは公表文書の記述であり、世界中で悪用がないことや、個々のサイトが侵害されていないことを証明するものではありません。確認した一次資料から、AIによる攻撃や特定の被害を断定することもできません。

以下の点検順序、画面の例、検証計画は本サイトの提案です。実際の攻撃入力を再現したものではなく、修正を確実に利用環境へ届け、表示の意味を誤らせないための確認を中心にします。

出典：Adobe APSB26-163 Content Credentials SDKのセキュリティ更新、JVN iPedia JVNDB-2026-038493 CVE-2026-100122。

対象はSDKを組み込んだ処理や配布物

Adobeの文書は、Rust SDK、C2PA Tool、JavaScript SDKを対象として、更新する版を案内しています。画像へ来歴情報が付いていることだけで、その画像を置くすべてのWebサイトが当該SDKの脆弱性を持つわけではありません。

対象を調べる入口は、依存関係の定義、ロックファイル、CLIを入れたサーバー、コンテナ、ブラウザーへ配布するJavaScriptの成果物です。自分がSDKを直接追加していなくても、CMSの拡張やメディア処理基盤が内部で利用している場合があります。

外部サービスへ検証を委ねている場合は、提供元が更新を管理する範囲と、自分で配布するコードの範囲を分けます。サービス名だけから対象外とせず、利用機能と提供元の更新情報を確認してください。

修正版の案内と本番で動く版を照合する

Adobeが修正版として案内するのは、Rust SDKのc2pa-v0.91.1、C2PA Toolのc2patool-v0.28.1、JavaScript SDKの@contentauth/c2pa-web@0.15.3です。実際の更新では、その後の対応版も含め、利用環境に適した修正を含む版を確認します。

組み込み先	Adobeが案内する更新版	本番で確認するもの
Rust SDK	c2pa-v0.91.1	ビルド時の依存と稼働成果物
C2PA Tool	c2patool-v0.28.1	実行するCLIの配置先と版
JavaScript SDK	@contentauth/c2pa-web@0.15.3	配布バンドルと読み込み元

JVN iPediaはCVE-2026-100122の影響範囲を各製品の修正版未満として掲載しています。一方、Adobeの一覧は複数の問題をまとめたものです。版の一覧だけで個別のCVEや独自の派生版への影響を推測せず、利用しているコードと提供元の情報を照合します。

リリースタグの日付とセキュリティ文書の公表日も別です。修正版の取得先を確認したからといって、文書の公表日と同日にすべてのバイナリが初めて公開されたと書き換えないことが重要です。

来歴情報の意味と限界：C2PA Content Credentials Explainer 2.2。

来歴の検証と内容の真偽を分ける

C2PAの公式解説は、来歴情報だけでは、デジタルコンテンツの内容が真実、正確、事実であるかまでは判断できないと説明しています。どこから来て、どのような履歴を持ち、関連する情報が改変されていないかという手掛かりと、写真の場面が本当に起きたかは違う問いです。

そのため、SDKを更新した後も「検証成功だから内容は正しい」と表示しないようにします。署名や証明書の検証結果、信頼する発行元の扱い、履歴情報の有無、編集上の事実確認を、それぞれ区別して利用者へ伝える必要があります。

同じ理由で、来歴情報が付いていない画像を一律に偽物と扱うべきでもありません。C2PAの解説は、利用が任意であり、資格情報の有無だけで素材全体の信頼性を決めない考え方を示しています。

画面が検証結果を一つの成功表示へ潰していないか

仮想の画像投稿サイトで、SDKが返す結果を真偽値へ変換し、何かのデータが取れたらすべて緑の印を出す構成を考えます。検証に失敗した状態、情報がない状態、処理できない状態が区別されなければ、修正版の判定を画面で誤って伝える可能性があります。

本サイトは、利用するSDKの現行仕様に沿って状態を整理し、画面の言葉を対応させることを勧めます。具体的なステータス名や返り値は、採用する言語と版の資料で確認してください。一般化した独自の状態名を、実際のAPIが返すものとして扱わないようにします。

検証が失敗したとき、信頼済みの表示へ進める例外がないかも調べます。旧SDKの結果を前提にした変換処理や、エラーを無視する互換処理が残っていないかを確認します。

ブラウザー用のコードとキャッシュへ更新を届ける

ソースコードの依存を更新しても、古いJavaScriptを配り続けていれば利用者側の処理は変わりません。ビルドされたファイル、配布先、CDN、HTMLが指す資源を確認し、本番の実際の読み込み先と対応させます。

サーバー側のCLIやワーカーも、複数の配置先に古い版が残る場合があります。管理用の端末で新しい版を確認しただけで、バッチやコンテナの処理も更新済みとは判断しないでください。

独自にフォークしたコードや別のパッケージに組み込んだ構成では、修正が入っているかを保守担当者と確認します。単に同じ名前のライブラリがあるかではなく、検証に使うコードと成果物を追うことが重要です。

更新後は表示と処理の両方を試す

管理下のテスト素材を使い、通常の来歴情報、情報がない素材、改変した無害なテスト素材などを代表させます。各ケースでSDKの結果と画面の表示が一致することを確かめます。信頼の設定や証明書の条件は採用するSDKの資料に従ってください。

読み込みの失敗や時間切れでも、信頼済みの表示が残らないことを確認します。以前に検証した結果をキャッシュしている場合は、どの版と条件で判定した結果かを追えるようにし、必要な再検証を計画します。

実ファイルの読み込みから後片付けまでを確認し、検証のために第三者の秘密や攻撃用の素材を本番へ持ち込まないようにします。大きいファイルや未対応形式の扱いも、通常の機能試験に含めます。

利用者と編集者へ説明する範囲をそろえる

画像を採用する編集者には、来歴表示が示す範囲と、別に必要な事実確認を伝えます。証明書を含む検証の結果が変わったときに、過去の掲載素材がすべて偽物だったと早合点しないようにします。

逆に、画面が成功表示を出し続けていたという理由だけで、過去の判定が正しかったとも言えません。必要に応じて、採用していた版、信頼の設定、検証結果、掲載の判断を分けて振り返ります。確認できたことと未確認のことを区別してください。

機能を一時停止する場合は、来歴を表示しないこととコンテンツを非公開にすることを同じ操作へまとめないようにします。必要な案内を用意し、利用者へ不正確な信頼の表示を返さない状態を優先します。

優先するのは組み込み先と判定の流れの確認

今回の点検は、まずSDKとCLIを利用している場所を調べ、次に修正版を含む成果物を本番へ届け、最後に判定と表示を再確認する順序で進めることを提案します。通常の画像を配信しているだけなのか、来歴を解析・検証する処理があるのかを最初に区別すると対象を絞れます。

調査の記録には版、配置先、検証した素材の分類、表示の結果を残し、素材に含まれる個人情報や秘密を無差別に保存しないようにします。更新作業と侵害の有無の調査は別です。不審なアクセスなどがある場合は、記録を保全して正規の担当者へ相談します。

来歴の仕組みは信頼を判断するための材料です。その材料を検証する実装を更新し、何を確かめた表示なのかを正しく伝えることが、画像や動画を扱うWeb運営で必要な対応になります。