FlawOpen

flawopen.com/Teardowns/cve-2026-105751-docling-odf-file-disclosure

● CVE-2026-105751 · CVSS v4 6.9 · 中
セキュリティ研究 · FlawOpen

CVE-2026-105751：Docling ODFのファイル漏えい

DoclingのODFバックエンドは、文書内の画像参照をローカルパスとして扱い、アーカイブ外のファイルを読み取る可能性がありました。2.120.3へ更新してください。修正では共有のリソース制御コンポーネントを通じて読み込みます。

CVSS ベクトルCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N
💡 わかりやすい解説 (ELI5)

司書がアルバムの中から写真を探します。見つからないと、欠陥のある読み取り処理はアルバムのラベルに書かれたパスを使ってファイル棚を開き、ローカルファイルを取得しないという図書館の規則を確認しません。修正では、他の文書形式と同じ保護されたリソース窓口を使います。

主要な概念と専門用語

OpenDocument Format (ODF)
.odt文書などを含むオフィス文書形式のファミリーです。Doclingは文書XMLから画像参照を読み取ります。
draw:image
画像を表すODFのXML要素です。xlink:hrefの値がリソースを示します。
xlink:href
ODF画像要素に含まれるリソース参照です。文書からの入力であり、ファイルシステムの認可判断に使ってはいけません。
ImageResourceLoader
Docling共通の画像ローダーです。ローカル/リモート取得オプション、パス解決、リモートURLの安全確認を適用します。
enable_local_fetch
対応バックエンドがローカル画像を取得できるかを制御する設定です。共有ローダーを迂回するバックエンドでは、この制御も迂回されます。

フレームワーク対応

  • このガイドで説明する弱点の CWE 参照： CWE-22

根本原因の分析 (Root Cause)

影響を受けるDoclingでは、_image_ref_from_odf_image() が最初にODFアーカイブ内でdraw:imageリソースを探していました。検索でデータが得られない場合、フォールバックは文書が指定したxlink:hrefを直接Pathへ変換し、パスが存在するとread_bytes()を呼び出していました。そのため共有ImageResourceLoaderが迂回され、ODF処理ではenable_local_fetch、enable_remote_fetch、共通のリソース解決ルールが適用されませんでした。画像種別フィルターも空の拡張子を許可しており、拡張子のないパスが通る状態でした。画像デコードより前にファイルが読まれる場合があります。データが画像としてデコードできる場合、生成文書での漏えいも確認されています。ベンダーアドバイザリは、ローカルファイルの任意読み取りとDocling出力形式での画像内容漏えいを記載し、後者を画像としてデコード可能なデータに限定しています。このCVEは、ローカルファイルにアクセスできるプロセスが提供された文書を変換するケースです。すべてのDocling環境がネットワークから到達可能だと示すものではありません。修正は外部参照をローカルのbase pathなしでImageResourceLoader.load_image_data()へ渡し、ODFの走査処理全体にローダーを伝播し、許可する画像拡張子から空文字を除外します。共有ローダーは既定でローカル取得を拒否し、有効化した場合も制限されたbase pathを要求します。GitHub CNAはCVSS 4.0 6.9（Moderate、UI:A）と評価しています。別の到達可能なサービスと変換経路を確認せずに、未認証のリモート攻撃と表現しないでください。

ステップ・バイ・ステップの攻撃フロー

ステップ 1

文書がODF変換経路に入る

対象はDocling 2.107.0〜2.120.2で処理されるOpenDocumentファイルです。問題はODF画像バックエンドにあり、Doclingの全形式やすべてのHTML/RAG統合が対象ではありません。

ステップ 2

画像参照は文書XMLから渡される

ODFのdraw:image要素がxlink:hrefを指定します。Doclingは最初にアーカイブ内でリソースを探します。

ステップ 3

アーカイブにない項目がホスト上のパスにフォールバックする

アーカイブ内検索に失敗すると、脆弱なhelperは同じ参照をPathとして直接読み込みました。フォールバックでは共有ローカル取得設定を確認せず、パスをアーカイブ内に制限していませんでした。

ステップ 4

Doclingがバイト列を画像リソースとして処理する

ファイルシステムの読み取りは画像デコード前に起きます。内容が対応画像なら、そのバイト列がDoclingDocumentやHTML、Markdown、JSON出力に埋め込まれる可能性があります。

ステップ 5

修正後のローダーがリソース境界を戻す

Docling 2.120.3は外部ODF参照をImageResourceLoaderに渡し、ローカルbase pathを渡さず、拡張子のない参照を除外します。信頼できない文書を変換する場合はローカル取得を無効にしてください。

ソースコード比較：脆弱 vs 堅牢化

これは上流コードの該当箇所を抜粋したもので、単独で適用できるパッチではありません。修正ではバックエンドのenable_local_fetchとenable_remote_fetchを設定したImageResourceLoaderを作成してODF処理に渡し、外部参照の読み込みに使います。base_path=Noneの場合、ローカル取得を明示的に有効にしても、制限ディレクトリを決められないためローカルパスは拒否されます。パッチは空の画像拡張子も拒否します。この抜粋だけをコピーせず、2.120.3以降に更新してください。

ソース抜粋: docling/backend/opendocument_backend.py — ソースコードの該当箇所

脆弱な実装
# アーカイブにリソースがないと、文書指定のパスへフォールバックしていた。
if image_data is None and image_url:
    image_path = Path(image_url)
    if image_path.is_file():
        image_data = image_path.read_bytes()
堅牢化されたセキュアパッチ
# 修正経路：バックエンド設定を使う共有ローダーを通す。
if image_data is None and image_url and image_loader is not None:
    image_data = image_loader.load_image_data(image_url, base_path=None)

エンジニアリング＆システム堅牢化チェックリスト

参考資料