Rails Active Storage の脆弱性：11月7日までに確認すべき3つの設定

CVSS 9.8 の Rails Active Storage の脆弱性では、画像1枚のアップロードでサーバー上にファイルを書き込まれるおそれがあります。3つの設定の確認、アップグレード、Rails 8.0 の期限について解説します。

プロフィール画像や文書、商品写真を受け付ける Rails アプリケーションのほとんどは、そのファイルを Active Storage 経由で処理しています。2026年11月4日、Rails チームはこのアップロード経路に関する重大なセキュリティアドバイザリを公開しました。よくある構成の一部では、細工されたアップロード1件だけで、認証されていない攻撃者がサーバー上にファイルを書き込めてしまいます。

影響を受けるかどうかは、簡単に確認できる3つの設定で決まります。本記事では脆弱性の内容、各設定の確認方法、そして今日すぐにアップグレードできない場合の対処法を解説します。特に重要なのは Rails 8.0 を使っているチームです。このブランチのセキュリティサポートは2026年11月7日に終了します。

脆弱性の内容

ファイルが添付されると、Active Storage はアナライザーを実行して画像サイズなどの基本情報を読み取ります。:mini_magick プロセッサーを使っている場合、アナライザーはそのファイルを ImageMagick に渡します。ImageMagick はコーダーと呼ばれるモジュールで多くの形式に対応しており、中には強力なものもあります。修正コミットでは、アップロードされた SVG が MSL コーダーに到達する例が示されています。MSL はスクリプト形式で、スクリプト内で指定したファイルを読み書きできます。Active Storage はアップロードが到達できるコーダーを制限していなかったため、サーバーの ImageMagick ポリシーが唯一の防御策でした。

深刻さを増している点が2つあります。1つ目は、アナライザーが添付時に実行されるため、バリアントやプレビューの生成、明示的な analyze 呼び出しがなくても、アップロードを受け付けるだけで十分だという点です。2つ目は、Disk サービスでファイルを保存しているアプリケーションでは、アプリケーションプロセスが読み取れる任意のファイルを読み取らせることも可能だという点です。これには secret_key_base や他システムの認証情報も含まれ、リモートコード実行やラテラルムーブメントにつながるおそれがあります。

このアドバイザリは、GMO Flatt Security の RyotaK 氏が HackerOne を通じて報告したものです。Rails チームは、報告された攻撃チェーンは1つだが、それが唯一のものだとは考えていないとしています。アドバイザリには、この脆弱性が実際に悪用されたかどうかは記載されていません。

影響有無を判定する3つの条件

影響を受けるのは、3つの条件がすべて成り立つ場合だけです。順番に確認してください。どれか1つでも当てはまらなければこの攻撃チェーンは成立しませんが、それでもアップグレードするのが正しい対応です。

条件	確認箇所	影響を受けるケース
1. バリアントプロセッサー	config.active_storage.variant_processor と load_defaults	:mini_magick になっている（load_defaults 6.1 以前のデフォルト）
2. ImageMagick ポリシー	サーバーの policy.xml	MSL、Ghostscript 系コーダー、gs デリゲートをブロックしていない（Debian と Ubuntu のデフォルトポリシーはブロックしていません）
3. アップロードできるユーザー	アップロードフォームと API	信頼できないユーザーがファイルを添付できる

1. Active Storage はどのプロセッサーを使っているか

設定ファイルを検索し、実行中のアプリケーションにも問い合わせます。

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Rails 7.0 以降のデフォルトは :vips ですが、古いバージョンからアップグレードしてきたアプリケーションでは、古いデフォルトを読み込んだままだったり、:mini_magick を明示的に設定していたりすることがよくあります。bundle info mini_magick も確認してください。この gem がバンドルに含まれている場合は、どこで使われているかを調べましょう。

2. ImageMagick ポリシーは危険なコーダーをブロックしているか

各アプリケーションサーバーとワーカーで、ImageMagick が実際に読み込んでいるポリシーを一覧表示します。

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

MSL コーダー、PostScript と PDF のコーダー、gs デリゲートに対して rights="none" のルールがあるかを確認します。Debian や Ubuntu のパッケージ付属ポリシーを変更せずに使っている場合は、ブロックされていないものと考えてください。コンテナイメージやワーカーホストでは、Web サーバーとは異なる ImageMagick ビルドが動いている可能性がある点にも注意が必要です。

3. 信頼できないユーザーがファイルをアップロードできるか

ファイルが attach、has_one_attached、has_many_attached に到達する箇所をすべて洗い出してください。API、ダイレクトアップロード、外部からファイルを取り込む管理ツールも含みます。アバター欄のある一般公開のユーザー登録は、信頼できない入力として扱います。

修正方法：ブランチごとのアップグレード手順

修正版は Rails 8.1.4.1 と Rails 8.0.5.2 です。この2つのリリースでは合わせて21件のセキュリティ問題が修正されているため、今回の脆弱性の影響を受けない場合でもインストールする価値があります。

利用中のブランチ	対応
8.1	8.1.4.1 にアップグレードする
8.0	今すぐ 8.0.5.2 にアップグレードし、そのうえで 8.1 への移行を計画する（8.0 のセキュリティサポートは2026年11月7日に終了）
7.2 以前	修正版はリリースされません。後述のポリシーによる回避策を適用し、8.0 以降へアップグレードする

:mini_magick を使っているアプリケーションでは、mini_magick 5.1 以降も必要です。古いバージョンのままだと修正版は起動時にエラーを発生させるため、両方の gem を一緒に更新し、ステージング環境で起動を確認してください。

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

修正版には独自の ImageMagick ポリシーが同梱されていますが、それが実際に ImageMagick に届いているかを確認してください。アプリケーションが起動後に MiniMagick.cli_env を置き換えている場合、MiniMagick.cli_prefix を使っている場合、独自の MiniMagick::Shell を組み込んでいる場合は適用されないため、システムポリシーにルールを追加する必要があります。GraphicsMagick は ImageMagick のポリシーをまったく読み込みません。また、同梱ポリシーはサーバーの policy.xml を置き換えるのではなく追加される形なので、そこにワイルドカードを含む許可ルールがあると、ブロックが上書きされてしまいます。

同じリリースでは、2つ目の脆弱性 GHSA-v924-7rp8-4mxh（CVSS 8.8）も修正されています。Active Storage はアップロードされたファイルを、元の拡張子を残した一時ファイル名で ImageMagick や FFmpeg に渡していたため、ファイル名と申告するコンテンツタイプを操作できる攻撃者は、どのデコーダーが実行されるかに影響を与えられました。この脆弱性に対する Rails の回避策は FFmpeg のみを対象としており、回避策に頼らずアップグレードすべき理由がまた1つ増えています。

一度きりではなく、繰り返されるパターン

2026年7月には、libvips を使うアプリケーションに影響する別の重大な Active Storage の脆弱性 CVE-2026-66066 がありました。ImageMagick を使うアプリケーションはその経路の影響を受けませんでしたが、今回の脆弱性の影響は受けます。サポートされている2つの画像ライブラリの両方を通じて、4か月で2件の重大な脆弱性が見つかったことから得られる教訓は同じです。画像処理は大きな攻撃対象領域であり、Active Storage は見知らぬ相手から届いたファイルに対して、添付された瞬間にその処理を実行します。

プロセッサーを切り替えるだけでは対策になりません。身を守るには、画像ライブラリを攻撃対象領域の一部として扱うことが大切です。フレームワークと同じようにパッチを適用し続け、ポリシーで制限をかけ、どのホストで動いているかを把握しておきましょう。特に ImageMagick のポリシーはアプリケーションコードではなく OS イメージに含まれるサーバー設定であるため、見落としがちです。

すぐにアップグレードできない場合

Rails は 8.1 と 8.0 向けのパッチコミットも公開しています。修正版をデプロイできるまでは、次のチェックリストに沿って対応してください。

1. アップロードを処理するすべてのホストで、アドバイザリに記載された最小限のルールを ImageMagick のシステムポリシー（例：/etc/ImageMagick-7/policy.xml）に追加します。
2. 同じファイル内の許可ルールやワイルドカードがそれらを上書きしていないことを確かめ、magick -list policy で確認します。
3. ImageMagick で PDF や PostScript をレンダリングしている場合は、gs デリゲートと必要なコーダーだけを再度許可し、一定のリスクが残ることを受け入れます。
4. アップロードを制限します。ファイルを添付できるユーザーを一時的に絞り込むか、匿名でのアップロードを停止します。
5. Disk サービスを使っている場合は、secret_key_base、マスターキー、config/credentials.yml.enc の内容、ストレージとデータベースの認証情報、サードパーティのトークンのローテーションを計画します。漏えいした可能性のあるシークレットをフォールバックとして残さないでください。

アドバイザリで公開されている最小限のルールは次のとおりです。

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

詳細は Rails のセキュリティアドバイザリをご覧ください。

LOGIQ がお手伝いできること

LOGIQ は、OS イメージからアプリケーションランタイムまで、Linux 上でオープンソーススタックを運用するチームを支援しています。サーバー全体の ImageMagick ポリシーの確認や、サポート終了を迎えるブランチからの移行計画についてお手伝いが必要でしたら、お気軽にご相談ください。