Rails Active Storageの画像解析に重大な脆弱性｜更新後に処理制限と鍵を確認

Ruby on Railsは2026年11月4日、セキュリティ修正版8.0.5.2と8.1.4.1を公開しました。Railsの11月4日付リリースには21件の修正が含まれます。この記事では、外部から受け付けた画像をActive StorageがImageMagickで解析すると、サーバー上のファイルが書き換えられるおそれがあるCVE-2026-122006を中心に扱います。添付をDiskサービスに保存する構成では、アプリケーションプロセスが読めるファイルも流出し得ます。

対象の運用者は、Railsとactivestorageを修正版に更新し、画像処理を担うすべてのプロセスで新しいポリシーが有効かを確認してください。Diskサービスで影響条件を満たす場合は、更新に加えて秘密情報の交換が必要です。画像の縮小表示を提供していないから対象外とは判断できません。Railsの画像解析に関する個別勧告によると、添付の時点で解析が動くためです。

対象はアップロードの入口と実際の処理構成で判定する

開発元の勧告が挙げる成立条件は、信頼できない利用者からファイルを受け付け、Active Storageの画像処理にImageMagickを使い、実際に読み込まれるImageMagickのポリシーが関連するコーダーを禁止していないことです。コーダーは画像形式に応じた入出力処理を担う部分で、一部は画像本体以外のファイルも参照します。ImageMagickは入力内容から使うコーダーを選ぶことがあるため、画面で画像を受け付けているという説明だけでは処理範囲が分かりません。

設定名は config.active_storage.variant_processor です。:mini_magick を指定したアプリや、古い初期設定を引き継いだアプリを確認します。開発元は load_defaults が6.1以前の場合、:mini_magick が既定だったと説明しています。Railsを8系に上げたことだけで、既存アプリの設定が別の画像処理系へ変わったとは判断できません。環境別の設定や初期化コードがある場合は、実際の本番構成を優先します。

アップロード経路を洗うときは、一般公開フォーム、会員のプロフィール、取引先の添付、外部システムからの取り込みを分けます。ログイン必須のサイトでも、登録した利用者や取引先が送るファイルを信頼済みとみなせるとは限りません。逆に、ライブラリを依存関係に含むだけで、外部の入力が画像解析に届くとは限りません。画面やAPIから受け付けたファイルが、どの処理で添付として確定し、その後どこで解析されるかを追うと、修正を優先するサービスを絞れます。

Railsガイド：Active Storageで説明されている直接アップロードを使う構成では、ファイル転送先と添付を登録するアプリが分かれます。ストレージへ直接送ったから画像解析が外部に隔離されるわけではありません。アップロード完了後に添付を作る処理と、解析を実行するワーカーまで確認します。Webのアクセスログだけでは、どのプロセスが実際にファイルを処理したかが分からない場合があります。

ファイル書き込みとDiskサービスでの読み出しを分ける

修正前のActive Storageは、画像解析に呼び出すImageMagickのコーダーを制限していませんでした。攻撃者が加工したファイルを添付できる場合、利用者が変換済み画像を開かなくても処理に到達する可能性があります。開発元は、サーバーへの任意ファイル書き込みと、Diskサービスを使う場合の任意ファイル読み出しを区別しています。後者はアプリケーションプロセスが読めるファイルが対象で、秘密鍵や外部サービスの認証情報を取得された場合には、追加の侵害やコード実行に発展し得ます。

DiskサービスはActive Storageの保存方式を指します。コンテナで運用しているか、アプリケーションがクラウド上にあるかとは別の設定です。逆に、オブジェクトストレージを使っているというだけで、サーバー側のファイル書き込みの懸念は消えません。環境別のストレージ設定だけでなく、添付の種類ごとに保存先を変えていないかも調べます。同じサイト内でも、書類添付と画像添付で設定が異なる場合は、外部入力が届く範囲を個別に判断します。

この問題はGitHub Advisory DatabaseのCVE-2026-122006でも追跡できます。深刻度は開発元の勧告でCritical、CVSS 3.0の基本値は9.8です。勧告には研究者から攻撃経路の報告があったと記載されていますが、個別の本番環境で実際に悪用されたかは、その記述やスコアからは判断できません。

修正版の配備とポリシーの適用を別々に確認する

開発元が案内する修正版は8.0系が8.0.5.2、8.1系が8.1.4.1です。Rails本体の表記だけで済ませず、Gemfile.lockと配備済み環境で読み込まれるactivestorageの版を照合してください。ImageMagickをMiniMagick経由で使う構成では、ポリシーを適用するため mini_magick 5.1以上が必要です。開発元によると、:mini_magick の構成でこれより古い版が残ると起動時に例外になります。ビルドが通ることと、起動後に添付を処理できることは別に確認します。

修正版はImageMagick用のポリシーを同梱し、その場所をMiniMagickが起動するプロセスの検索パスに加えます。スクリプト処理や外部参照などに関わるコーダーや、Ghostscriptの呼び出しが制限されます。ホストのポリシーを置き換える仕組みではなく、既存の制限に追加して適用されます。また、適用範囲はActive Storageが呼ぶ処理に限らず、同じ構成でMiniMagickが起動するImageMagickのコマンドにも及びます。運用者は別の機能で同じ画像処理ライブラリを使っていないか確認してください。

起動後に MiniMagick.cli_env を上書きするコード、cli_prefix で環境変数を除去する設定、独自のShell実装がある場合、同梱ポリシーが届かないと開発元は警告しています。該当する構成では、ImageMagick自身が参照するシステムポリシーに必要な制限を持たせます。GraphicsMagickはImageMagickのポリシーを読みません。バイナリの名前やライブラリの設定だけで適用されたと結論せず、実行先と、その処理が参照するポリシーを対応付けます。

確認は、開発機ではなく画像処理ワーカーと同じイメージ、ユーザー、起動設定の検証環境で行います。ImageMagickのポリシー一覧を手元のシェルで表示しても、アプリが子プロセスへ渡す環境が違えば結論は変わります。正常系は普段許可しているJPEGやPNGの添付から解析、表示までを確かめます。拒否側は無害な検証用ファイルと隔離した環境を使い、禁止した処理が起動しないことを確かめます。本番で攻撃用ファイルを試す必要はありません。

PDFと動画は画像の回避策だけで片付けない

更新をすぐに配備できない場合、開発元は修正版に含まれる規則をホスト側のImageMagickポリシーに組み込む方法を案内しています。最低限の制限としてMSL、Ghostscript関連のコーダー、gsデリゲートを挙げています。暫定措置を行った場合も、別のノードやジョブ実行環境に反映されていなければ、そちらの処理は残ります。反映を確認できない間は、業務上許される範囲で信頼できない添付の受け付けや処理を止めることも検討します。これは本サイトからの運用提案です。

PDFやPostScriptをImageMagickで描画する機能は、新しい制限で挙動が変わり得ます。開発元は、必要な場合はホストのpolicy.xmlで利用するコーダーとgsを許可する手順に言及しています。業務機能を復旧するため広く許可する前に、外部から受け付ける添付と同じ処理環境で再許可することの影響を確認してください。必要な機能と入力が分離できるなら、信頼できる書類向けの処理だけを別環境へ切り出す方が、許可範囲を把握しやすくなります。

同日公開のRailsの一時ファイル拡張子に関する個別勧告は別の問題です。アップロードされたファイルを外部ツールに渡す際、一時ファイルの拡張子が処理方式に影響します。修正版では記録されたコンテンツタイプと拡張子が一致する場合に限って拡張子を残すよう変更されています。AviSynthを使う経路には対応してビルドされたFFmpegとランタイムが必要ですが、勧告は、ほかの拡張子依存の処理経路までその条件に限られるとはしていません。FFmpegを停止したことをImageMagickの修正確認の代わりにせず、両方を更新対象として扱います。

Disk構成では秘密の交換と過去の調査を残す

影響条件を満たしDiskサービスを使う構成について、開発元は secret_key_base、Railsのマスターキーと暗号化された設定の中身、ストレージやDBの認証情報、第三者サービスのトークンなど、プロセスが読めた秘密情報を交換するよう求めています。既に読み出された秘密は、パッチを当てただけでは無効になりません。旧キーを互換性維持のための予備として受理し続けないことも勧告の要点です。

実務では、先に未修正の処理経路を閉じてから、新しい秘密を修正済みのプロセスにだけ配ります。マスターキーを交換して暗号化ファイルを作り直す作業と、その中に入っている外部サービスのトークンを発行元で失効させる作業は別です。鍵の切り替えは既存セッションや署名付きURLなどに影響するため、利用者の再ログインや必要なリンクの再発行を準備します。切り戻し時も、漏えいの可能性がある旧キーを受け入れる構成に戻さないよう、手順を先に決めます。

調査ではアップロード受付の時刻、添付を記録した時刻、ワーカーの処理記録、保存先やファイルの変更を時系列で照合します。可能なら、処理プロセスが使っていた資格情報で外部サービスに不審な操作がなかったかも確認します。エラーがない、あるいはログが残っていないことだけで読み出しや書き込みを否定することはできません。更新の終了条件には、稼働中の版と処理制限の確認を、事故対応の終了条件には、過去の調査と必要な秘密の失効を、それぞれ記録してください。