Rails Active Storageの緊急脆弱性｜画像添付でファイル書き込み・読み取り、修正は8.0.5.2/8.1.4.1

Ruby on Rails の Active Storage に、未認証の攻撃者がサーバのファイルを書き込める Critical 脆弱性（CVSS 9.8）が見つかり、2026-11-04 に公開・同時に修正版が出た。rails/rails の公式アドバイザリは GHSA-f3w6-w445-fwh9。細工した画像を添付するだけで成立し、添付を Disk サービスで保存している場合はファイルの読み取りもできてしまう。読まれる先には secret_key_base や外部システムの資格情報が含まれやすく、そこから RCE（リモートコード実行）や他サービスへの横移動につながりうる。報告は HackerOne のリサーチャー ryotak による。

土台の考え方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説、同じ Active Storage の別件は Rails CVE-2026-66066（libvips）、画像ライブラリ由来の脆弱性としては Pillow の脆弱性 も参照。以下は rails/rails の GHSA-f3w6-w445-fwh9 を一次とした整理だ。攻撃の再現手順・PoC は扱わない（防御が目的）。

何が起きたのか——画像の添付だけで成立する

アドバイザリの Impact はこうだ——「ImageMagick で添付を処理する Rails アプリは、未認証の攻撃者がサーバに任意のファイルを書き込み、添付を Disk サービスで保存している場合はアプリプロセスが読めるファイルを読み取れる可能性がある」。そして「それらのファイルには通常 secret_key_base や外部システムの資格情報が含まれ、RCE への昇格や他システムへの横移動につながりうる」。

根っこは ImageMagick の仕組みにある。ImageMagick は、ファイルを名前ではなく中身を見て coder（形式ハンドラ）を選ぶ。そして一部の coder は、画像の中で名指しされた別のファイルに作用する。Active Storage はこれらの coder を一切制限しておらず、しかも image analyzer が添付された瞬間に走る。だから攻撃者は、細工したアップロードを添付するだけでよい。

なお原因の表現は GHSA の「coder 選択の仕組みと、別ファイルに作用する coder」に留める。具体的にどの coder でどんな副作用が起きるかの手口は、攻撃を助けるため本記事では展開しない。

影響する条件（3つ揃ったときだけ）

アドバイザリは影響範囲を厳密に切っている。次の3つがすべて真のときだけ影響する。

1. ImageMagick で画像処理している。config.active_storage.variant_processor = :mini_magick の構成で、これは load_defaults 6.1 以前のアプリの既定だ。
2. 該当 coder を拒否する policy が無い。ImageMagick を、問題の coder を既に拒否していない security policy の下で動かしている。Debian・Ubuntu が同梱する policy ではこれを塞げていない、とアドバイザリが名指しで書いている。
3. 信頼できないユーザーからのアップロードを受ける。外部ユーザーがファイルを添付できる。

逆に言えば、libvips（:vips）に切り替えているアプリや、policy で該当 coder を既に deny しているアプリ、外部アップロードを受けないアプリは、原則この脆弱性の対象ではない。ただし libvips 側には別件（後述の CVE-2026-66066）があったので、「vips だから無条件に安全」ではない。

影響を受けるバージョンと修正版は次のとおり。

AWS・クラウド／デプロイでの注意

「クラウドだから安全」という話ではなく、どの image processor と、どの ImageMagick policy で動いているかで決まる。とりわけ Ubuntu・Debian ベースの EC2 やコンテナで素の ImageMagick（imagemagick パッケージ同梱の policy）を使っていると、条件2「policy が該当 coder を塞いでいない」に当てはまりやすい。アドバイザリが両ディストロの同梱 policy を名指ししている点は重く見たい。

Disk サービスを使っているかも分かれ目だ。添付を S3 等のオブジェクトストレージではなくサーバのローカルディスク（Disk サービス）に置いていると、書き込みに加えて読み取りまで成立し、secret_key_base の流出 → RCE という最悪系に届きうる。コンテナ／EC2 で Disk サービスのまま運用しているなら、更新に加えて秘密情報のローテーション（後述）まで一気通貫で対応したい。

対策——更新と、更新できないときの緩和

本筋は更新だ。修正版は ImageMagick security policy（セキュリティポリシー）を同梱し、その置き場を MiniMagick.cli_env 経由で MAGICK_CONFIGURE_PATH の先頭に追加する。これで MiniMagick が起動するすべての ImageMagick プロセスにポリシーが効く。ポリシーは MSL スクリプティング coder／他ファイルを読み書き・削除する coder／リモート・ローカル参照を取得する coder／Ghostscript 由来の全 coder と gs デリゲート／@filename 間接参照を拒否する。既存のホスト側ポリシーを置き換えず追加する作りだ。

• activestorage を 8.0.5.2 / 8.1.4.1 へ更新する。
• variant_processor が :mini_magick のアプリは、mini_magick 5.1 以上も必須。ポリシー適用に必要で、古い mini_magick のままだと起動時に例外で止まる。
• PDF や PostScript を ImageMagick で描画しているアプリは、同梱ポリシーが gs を止めるため、ホストの policy.xml で gs デリゲートを明示的に再許可する必要がある。

次のケースは同梱ポリシーが効かないので、ルールを自分で system policy へ写す必要がある——起動後に MiniMagick.cli_env を差し替える／MiniMagick.cli_prefix で環境をクリアする／独自の MiniMagick::Shell を使う構成。また GraphicsMagick は ImageMagick の policy を読まないので、GraphicsMagick 利用時は別途対処が要る。

すぐ更新できないときは、system の policy.xml（例: /etc/ImageMagick-7/policy.xml）に最低限の拒否を入れて緩和する（更新の代替であって根本対処ではない）。

<!-- 更新できるまでの暫定緩和：最低限 MSL・Ghostscript 系・gs デリゲートを拒否 -->
<policymap>
  <policy domain="coder" rights="none" pattern="MSL" />
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="delegate" rights="none" pattern="gs" />
</policymap>

自分のアプリの確認

まず、自分のアプリが条件に当てはまるかを確認する。

# activestorage の版（8.0.5.2 / 8.1.4.1 以上か）
bundle list | grep -i activestorage

# variant_processor が :mini_magick か（load_defaults 6.1 以前の既定）
bin/rails runner 'puts Rails.application.config.active_storage.variant_processor'

# :mini_magick なら mini_magick の版も（5.1 以上が必要）
bundle list | grep -i mini_magick

# ImageMagick の policy が問題の coder を塞いでいるか（IM7 は magick、IM6 は convert）
magick -list policy  2>/dev/null | grep -iE 'MSL|ghostscript|gs|PDF|PS' || \
convert -list policy 2>/dev/null | grep -iE 'MSL|ghostscript|gs|PDF|PS'

ただし、この結果だけでは安全とは言えない。表示される版や設定は「条件に当てはまりうるか」を示すだけで、すでに攻撃を受けたかどうかを判定するものではない。迷うなら、条件の精査より先に更新を当てるのが安全側だ。アップロードの受け口を持つアプリでは、不審なアップロードがログに無いかも合わせて見ておきたい。

影響範囲と、秘密情報のローテーション

Disk サービスで添付を保存している場合は、更新だけでは足りない。アドバイザリは、secret_key_base と、アプリプロセスが読めるすべての秘密情報を入れ替えるよう求めている。具体的には master key、config/credentials.yml.enc の中身すべて、ストレージ・データベースの資格情報、サードパーティのトークンだ。そして 露出した秘密をフォールバックとして残さないこと——古い鍵を「念のため」併用し続けると、流出済みの鍵で入られる口が開いたままになる。

今回の修正は、8.0.5.2 / 8.1.4.1 に含まれる 21 件のセキュリティ修正の一つだ。ほかにも Strong Parameters のバイパス、8.1 の Forwarded ヘッダによる IP 詐称、Action View の複数の XSS、DoS、セッション Cookie の問題などが含まれる。また Active Storage の動画プレビュー・解析経由のファイル読み取り／コード実行という High の別件も同時に修正されている。更新は個別パッチではなくこの版へ上げるのが正解だ。

ImageMagick に画像処理をさせる設計の危うさは、Rails に限らない。今年だけでも、Active Storage の別件 CVE-2026-66066（libvips） は実際に攻撃に使われたと報告され、WordPress では細工した PostScript を Ghostscript に渡すコード実行が、Discourse では画像パイプラインを連鎖させたサーバファイル読み取りが報じられた。教訓は毎回同じだ——画像ツールは「絵を開く」以上のことをする。信頼できないアップロードには厳格な制限（policy）を前提に置くしかない。

参照ソース

• GHSA-f3w6-w445-fwh9（rails/rails Security Advisory）（Critical・CVSS 9.8・2026-11-04 公開。影響・条件・修正の一次記述）
• GHSA-wgv4-95jc-33jm（GitHub Advisory Database・CVE-2026-122006）（Advisory DB 側の複製エントリ。CVE 番号と NVD リンク）