商用 PDF エンジンへLLMを用いてゼロデイ脆弱性を探索する手法|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年02月26日更新日時: 2026年02月26日

セキュリティ企業はNovee Labsは2026年2月18日、PDFエンジンやPDF関連サービスを対象に、マルチエージェントLLM（複数のAIエージェント）を用いてゼロデイ級の脆弱性探索をスケールさせる研究手法を公開しました。

1 概要
2 原因
3 レポートが示した主な脆弱性
4 情報システム部門が押さえるべきポイント

概要

対象として取り上げられたのは、Apryse WebViewer（旧PDFTron）とFoxitのPDFクラウド／Web系コンポーネントで、同社は人間の研究者が見つけた「構造的なバグの型」をAIに学習させ、広い攻撃面を自律探索させることで、XSSからOSコマンドインジェクションまで複数カテゴリの脆弱性発見につなげたと説明しています。

このレポートのポイントは、AIが単にコードを眺めて「怪しい」と言うのではなく、信頼境界（trust boundary）を跨ぐデータフローを追い、実際に成立するPoC（概念実証）まで到達することを重視している点です。

具体的には、WebViewerのUIがURLパラメータやpostMessage、リモート設定JSONなど複数の外部入力を受け入れる構造を持つこと、さらに設定値がDOMの危険なシンク（dangerouslySetInnerHTMLやinnerHTMLなど）へ到達し得ることを示し、CVE-2025-70402、CVE-2025-70401、CVE-2025-66500として整理しています。

また、Noveeが採るマルチエージェント構成（Tracer／Resolver／Bypass）を提示し、単体モデルが陥りがちな「ノイズ」「到達性の未検証」「ミニファイされたコードの壁」をどう超えるかを説明しています。最終的に、Foxit PDF SDK for Webのデモ環境におけるOSコマンドインジェクションや、コラボレーション機能周辺でのパストラバーサルなど、XSS以外のサーバ側リスクも含めて、スウォーム（群）で探索した成果として提示しています。

原因

レポートの中で繰り返し強調される原因は、個別の実装ミスというより「信頼境界の扱い方」にあります。

PDF閲覧系のWebコンポーネントは、埋め込みiframe、URLフラグメント、クエリ文字列、リモート設定ファイル、postMessage、PDF内メタデータ（注釈の作者名など）といった多様な入力を「設定」や「文書データ」として取り込みます。しかし、これらは攻撃者がコントロールできるケースがあり、しかもUIフレームという境界を越えた瞬間に、データは「信頼された設定値」として扱われます。

さらにWeb製品特有の事情として、ミニファイや動的ディスパッチ、フレームワーク内部のDOM更新処理（Reactの内部ヘルパ関数など）に危険なシンクが隠れることで、表面的なサニタイズや単純なパターン検出では危険な到達経路を見落としやすくなります。Noveeは、AIに「innerHTMLを探せ」ではなく、「攻撃者入力がどの変換を経て、どの条件で生き残り、どのイベントで再レンダリングされるとシンクに届くか」を解かせることがポイントだとしています。

レポートが示した主な脆弱性

Apryse WebViewer：CVE-2025-70402（uiConfig経由のDOM XSS）

WebViewer UIがuiConfigパラメータをURLとして解釈し、外部のJSON設定を取得してUIに適用する設計を前提に、設定フィールドがDOMの危険なシンクに到達することでDOM XSSが成立する、というものです。特に「クエリから指定したリモート設定が、結果的にUI描画へ混入する」という境界違反が核で、リンクを踏ませるだけで成立し得る点が問題になります。レポートではSVGの取り扱いを巡り、単純なonloadやscriptが無効化される状況でも、foreignObjectを用いた回避で実行に持ち込めることを示しています。

実務上は、PDFビューアが認証済みアプリに埋め込まれている場合、XSSがアカウント乗っ取り（ATO）やトークン窃取、文書データの抜き取りに直結し得ます。UIフレーム内のXSSでも、親アプリとの連携やpostMessageの使い方次第で影響が拡大するため、「ビューアはただの部品」と見なすと危険です。

Apryse WebViewer：CVE-2025-70401（注釈Authorフィールド由来のStored DOM XSS）

PDF注釈の作者名（Title/Author相当）がNotes/Commentsパネルで不適切に描画され、ある条件でReactの再レンダリングが起きた際にinnerHTML系シンクへ到達してXSSが実行される、というものです。重要なのは、初回ロードでは発火せず、コメント欄に文字入力するなど「状態変化トリガ」が必要だと明示されている点です。現場の脆弱性評価で見落とされがちな「トリガ条件」まで含め、攻撃の成立性を説明しています。

Stored型であるため、悪性PDFや悪性URLが共有されると、閲覧者が同じ操作をしただけで繰り返し実行され得ます。PDFを共有する業務フロー（社内ポータル、顧客共有、ワークフロー製品）では、文書が「媒介」になって長期間残ることがあるため、後追いで火がつきやすい類型です。

Foxit Web Plugins：CVE-2025-66500（postMessageハンドラのorigin検証不備によるDOM XSS）

FoxitのWebコンポーネント（calculatorやsupport agent等）を埋め込むiframe群で、postMessageによる初期化コマンドを受け付ける処理が、ブラウザが保証するevent.originではなく、メッセージ本文内のoriginフィールド（攻撃者が任意に設定できる文字列）を比較してしまい、結果として外部スクリプトURLをscriptタグとして挿入できる、という問題です。

この類型は、クロスフレーム連携が前提の製品で繰り返し発生します。postMessageは正しく使えば便利ですが、検証が曖昧だと「信頼されたドメイン上で任意JSが実行される」状態になり、フィッシングやセッション情報の抜き取り、埋め込み先文書処理の改ざんなどの足場になります。

情報システム部門が押さえるべきポイント

PDFは「文書」ではなく「実行環境に近い複合物」です。閲覧コンポーネントは、外部入力を多段で受け入れるため、脆弱性が出ると影響が広くなります。特に次の観点を優先すべきです。

PDFビューアの埋め込みを信頼しない

社内ポータルや顧客向け画面にPDFビューアをiframeで埋め込む場合、ビューア側のXSSは親アプリへの影響に拡大し得ます。postMessageの設計、SameSite/CSP、iframe sandboxの適用、トークンの露出位置などを、ビューアも含めて評価対象にする必要があります。

設定経路を攻撃面として扱う

uiConfigのように「設定を外部から読み込める」仕組みは便利ですが、攻撃面になります。URLパラメータ、フラグメント、リモートJSON、ローカルストレージの読み込みは、境界を越えるデータとして検証・署名・ホワイトリスト化を検討すべきです。

postMessageはevent.originで厳格に検証する

本文内のorigin文字列比較は設計として危険です。許可する送信元オリジンの固定、メッセージスキーマ検証、受信後にURLをscript/srcへ渡すような設計自体の回避が基本になります。

デモ環境や付属サーバを放置しない

レポート後半のOSコマンドインジェクションやパストラバーサルは、SDK付属のデモ・サンプルサーバに起きやすい類型です。開発時に立ち上げた付属コンポーネントがそのまま公開されると、認証なしの危険エンドポイントが残ることがあります。デモ環境は本番同等に棚卸しし、外部公開しない・認証を入れる・不要機能を落とすことが必要です。