UnRTFの文書変換でDoSの可能性！アップロード後の解析処理も更新対象に

JVNは2026年10月20日、GNU ProjectのUnRTFに境界外書き込みの脆弱性があると公表しました。対象は0.21.12より前の版で、CVE-2026-109831が割り当てられています。細工されたRTFファイルをユーザーが開くことでサービス運用妨害（DoS）になる可能性が示され、最新版への更新が案内されています。

本稿の確認日は10月21日です。JVNの評価はCVSS v4.0が5.1、v3.0が5.4です。本記事の構造化スコアにはv4.0を使います。公表資料はDoSの可能性を説明しており、遠隔コード実行や実際の攻撃被害を確認したという意味ではありません。Webサイトで文書変換を自動化している場合にも、利用する実体の確認が必要です。

一次資料：UnRTFにおける境界外書き込みの脆弱性（JVN#29783594）。以下の運用手順と仮想例は本サイトの提案です。

画面に出ない文書変換ツールを探す

UnRTFはRTFの変換処理に使われるツールです。Webサイトでは、添付のテキスト抽出、全文検索の索引作成、プレビュー、社内文書の取り込みなどの裏側へ外部コマンドが組み込まれていることがあります。ここで挙げる利用例は一般的な確認対象であり、特定のCMSやサービスが今回影響すると断定するものではありません。

棚卸しでは、アプリの直接依存だけでなく、コンテナのOSパッケージ、変換スクリプト、バッチ用イメージ、文書解析サービスの設定を調べます。フロントのアプリサーバーに入っていなくても、キューの後ろにあるワーカーで実行される場合があります。実行ファイルのパスと実際のパッケージを対応付けてください。

SBOMやパッケージ一覧があっても、実際の稼働環境と同じ時点のものかを確認します。以前のビルドの一覧だけを見て未使用と判断すると、後から追加された解析ツールを落とします。逆に、依存一覧に名前があるだけで外部入力を処理していると決めつけず、呼び出す経路と入力元を調べます。

ファイルを受け取る権限と解析する権限を分ける

JVNはユーザーがファイルを開く条件を示しています。自社の自動変換にどう当てはまるかは、入力をどのプログラムでどのように解析するかを確かめる必要があります。ファイルのアップロードが成功したことと、変換処理を安全に実行できたことは別の結果です。

本サイトでは、受信、保存、検査、変換、表示を段階ごとに整理することを勧めます。受信サーバーがそのまま強い権限で変換コマンドを起動する構成より、限定した作業領域と権限を持つワーカーへ渡す構成の方が、異常終了の影響を局所化しやすくなります。

拡張子やContent-Typeを確認するだけでは、パーサーが処理する内容を安全と保証できません。ファイル形式を識別しても、その内部構造が正しいか、変換プログラムに未知の問題がないかは別です。利用する版の更新と、失敗時の隔離・資源制限を組み合わせます。

更新は稼働中の変換環境へ届ける

公式にはUnRTF 0.21.12が修正先として案内されています。OSの配布元が修正をバックポートしている場合は、上流番号だけで判定せず、配布元の告知と導入済みパッケージを照合します。本稿では未確認のディストリビューション別パッケージ番号を並べません。

コンテナを使う環境では、開発機で更新しただけでなく、ワーカーイメージを再ビルドして実際に置き換えます。古いタグや停止中のジョブ定義から再作成されないかも確認します。手動でコンテナ内の実行ファイルだけ変えると、次の再起動で消えるため、元のビルド定義へ反映してください。

変換サービスを委託している場合は、製品名だけでなく、UnRTFを使うか、影響版が残るか、更新完了をどう確認できるかを提供元へ問い合わせます。分からない状態を対象外にせず、回答待ちとして管理します。利用が確認できなかっただけで他の文書解析ツールも安全だと拡張しないことが大切です。

DoSをワーカー全体の停止へ広げない

本サイトの提案として、変換ごとに時間、メモリー、CPU、作業ディスク、出力サイズを制限します。単にHTTPのタイムアウトを短くしても、裏側の子プロセスが動き続ければ資源を使い切る可能性があります。要求の終了と解析プロセスの終了が連動するかを確認します。

同時実行数とキューの上限も別に必要です。一つのファイルが異常終了しなくても、大量の重い変換で全ワーカーが埋まれば、正規の処理が進まなくなります。利用者や組織ごとの上限、優先度、混雑時の応答を決め、Webの主要機能と変換処理の容量を分離します。

変換ワーカーにインターネット通信、クラウド認証情報、本番DBの書き込み権限が本当に必要かを確認します。今回の公表はDoSですが、パーサーの今後の問題も考えた運用として、不要な権限を減らす価値があります。別の影響が今回確認されたかのように書かず、防御設計上の提案として扱います。

失敗した文書を無限に再送しない

キューに再試行機能がある場合、同じ壊れた文書を何度も処理すると、更新後の正常性を確認する前にサービスを圧迫するおそれがあります。入力の識別子、試行回数、終了理由を保存し、一定回数で隔離して人へ通知する経路を用意します。ログに文書本文や個人情報を丸ごと残す必要はありません。

説明用の仮想例として、毎晩取り込む文書の一つが変換を繰り返し失敗し、そのジョブを先頭からやり直す構成を考えます。一つの入力が後続の全件を止めるなら、ファイル単位の結果とジョブ全体の状態を分けて持つ必要があります。毒になる入力を外して残りを進められる設計にします。

隔離したファイルは誰でもダウンロードできる場所へ置かず、保持期間と調査担当を決めます。調査目的で担当者の通常端末へ移して開くと、隔離の意味が薄れます。必要な再現試験は、更新した解析環境と制限された権限で行ってください。

更新後の試験は成功と失敗を両方見る

正常なRTFを用いて、文字コード、段落、表、画像参照など、自社が必要とする出力を確認します。セキュリティ修正を優先しながらも、変換結果が空になったり文字が欠けたりすると、検索やプレビューの品質へ影響します。以前の代表データと結果を比較し、利用者が必要とする項目を明確にします。

壊れた入力、極端に大きい入力、時間制限に達する入力では、処理が停止し、資源が解放され、後続ジョブが進むことを確かめます。本番へ攻撃用ファイルを無計画に投入する必要はありません。許可された試験環境で、通常の異常系テストと提供元の案内に沿った検証を行います。

監視には、失敗率、処理時間、キューの滞留、ワーカーの再起動回数を含めます。アプリ画面が正常でも変換が止まっている場合があるため、成功した処理の最終時刻も見ると異常を把握しやすくなります。更新直後の増減は、データの変化や試験の影響と区別します。

対応を閉じるための記録

索引と原本を分ける復旧の設計

仮想の文書検索サービスで、原本を保存してからテキストを抽出し、検索索引へ登録するとします。変換で失敗しても、原本の保存成功と索引の登録成功を同じ状態にしなければ、どの段階をやり直すべきかを判断できます。利用者へは受信済み、処理中、変換失敗など実際の状態を返し、完了していない検索結果を完成と見せない設計にします。

修正後に再処理する場合も、全原本を一度にキューへ戻すと負荷が急増します。失敗していた入力から少量ずつ試し、時間、メモリー、出力の品質を見て対象を広げます。過去に失敗した原因が今回の脆弱性とは限らないため、修正版ならすべて成功するとは仮定しません。

変換結果をキャッシュするサービスでは、実行ファイルを更新しても以前の空の結果やエラー結果が残る場合があります。キャッシュの識別子に変換プログラムの版や設定を反映するか、対象を限定して再生成する方法を検討します。原本と結果の対応を失わないことが、利用者の問い合わせへ答えるためにも役立ちます。

本番データで品質を評価する必要がある場合は、アクセス権と目的を確認し、担当者が必要な範囲だけ参照します。取り込んだ文書には契約書や個人情報が含まれることがあるため、デバッグ用の一時ファイルや失敗時のダンプへ内容が残る経路も確認します。セキュリティ修正の試験で別の漏えいを作らないことが重要です。

同じ変換処理を複数サービスが使うなら、共有ライブラリーとして一度更新したつもりでも、各サービスが独自の実行ファイルを同梱していないかを確認します。修正を受け取る担当と、その成果物を取り込む担当を分けて管理し、どの配備で反映されたかを記録します。

定期的な棚卸しでは、受信できる形式と解析に使うツールの対応表を更新します。RTFだけを止めても別形式が同じ処理へ到達する可能性は構成次第です。今回の対象以外を一律に危険と呼ぶ必要はありませんが、入力の見た目と実際の解析プログラムの関係を把握しておくと、次の公表への対応が早くなります。

文書変換の停止が利用者へ及ぼす影響も、あらかじめ整理します。検索に出ないだけなのか、登録自体を完了できないのかで代替手順が違います。変換を一時停止する場合は、原本の受付を続けるか、保留中の入力を後で処理できるかを確認し、利用者へ伝える状態と内部のキューを一致させてください。

対応票には、UnRTFの実体、入力経路、修正の根拠、稼働イメージ、試験結果、再試行の上限、隔離先を残します。対象外なら、その判断が未導入なのか、外部入力を渡さないのか、別の修正済み配布物なのかを明示します。後任が同じ調査をやり直さずに済む記録が必要です。

文書のアップロード機能を守る範囲は、受信画面だけではありません。今回のUnRTFの修正を機に、解析処理の実行環境と失敗の扱いを確認してください。外部から受け取った文書を処理する限り、更新、資源制限、隔離、再試行制御を一つの運用として維持することが重要です。