Railsに21件まとめて修正、未認証でファイル読み書きのCriticalも。8.0系は11月7日で守りが切れた

まず初めに

21件まとめて修正、という数字だけ見ると「大掃除が終わった家」のように見える。だが中身は違う。玄関の鍵穴に細工ができる欠陥と、窓の目隠しが剥がれる欠陥が、同じ段ボールに雑に詰め込まれている。そのうえ8.0系は、修正版が出た3日後に「もう守らない」と宣言された側である。掃除の話ではなく、引っ越し期限の話だ。

※個人の感想です

何が起きたのか

Ruby on Railsは、Webサービスを作るためのRuby製フレームワークです。開発チームは2026年11月4日、公式フォーラムで8.0.5.2と8.1.4.1の公開を案内し、「できるだけ早くアップグレードすることを強く勧める」としました。

修正された21件の内訳は、深刻度Criticalが1件、Highが4件、Mediumが13件、Lowが3件です。テーマは、Active Storageの画像・動画処理でのファイル読み書きとコード実行、Strong Parametersの回避、Forwardedヘッダー経由のIPアドレス偽装（8.1のみ）、Action ViewヘルパーやMessagePackシリアライザのXSS（クロスサイトスクリプティング）、複数のサービス拒否（DoS）、Google Cloud Storageへの直接アップロードでのContent-Type未署名とファイルサイズ制限の回避、セッションの復元やクッキー漏えい、キャッシュ汚染、Mailgun連携での署名リプレイなど、多岐にわたります。

Active Storageの欠陥については、本サイトでも2026年8月のActive Storageのリモートコード実行の脆弱性（CVE-2026-66066）を伝えています。今回は別の欠陥群であり、前回の修正を当てただけでは足りません。

最も深刻な欠陥——アップロードするだけでファイルが書ける

CriticalのGHSA-f3w6-w445-fwh9は、Active StorageがImageMagickで画像を解析する際の欠陥です。ImageMagickはファイルの中身を見て処理方式（コーダー）を選びますが、一部のコーダーは画像そのものではなく、画像の中に書かれた名前のファイルへ作用します。Active Storageはこのコーダーを制限しておらず、ファイルが添付された時点で解析が走るため、細工したファイルをアップロード（添付）するだけで攻撃が成立し得ます。プレビューやバリアント生成を呼ばなくてもよい、という点が厄介です。

影響を受けるのは、次の条件をすべて満たすアプリです。

• Active Storageの画像処理にImageMagickを使っている（variant_processor = :mini_magick。load_defaults 6.1以前の既定）
• 動いているImageMagickのセキュリティポリシーが、関係するコーダーを既に禁止していない（DebianやUbuntuが配布するポリシーは禁止していない、とアドバイザリは説明しています）
• 信頼できない利用者からのファイルアップロードを受け付けている

書き込めるだけでなく、添付ファイルの保存先がDiskサービスの場合は、アプリのプロセスが読める任意のファイルまで読み取られます。アドバイザリは、その対象には secret_key_base や外部システムの認証情報が典型的に含まれ、結果としてリモートコード実行や外部システムへの横移動につながり得るとしています。発見はHackerOne経由で研究者のRyotaK氏が報告しました。公式発表の範囲では、この欠陥が実際の攻撃に使われたという情報は示されていません。

もう1つのHighと、残りの顔ぶれ

Highの筆頭はGHSA-v924-7rp8-4mxhで、動画のプレビューや解析、画像処理の過程で任意のファイル読み取りとリモートコード実行につながり得る欠陥です。残りのHighは、Strong Parametersの Parameters#each_key による回避、Action Dispatchの RemoteIp でのIP偽装（8.1のみ）、Active Supportの safe_constantize のDoSです。

Medium以下にも、実務で刺さるものが並びます。破棄したはずのセッションがCacheStore経由で復元される問題、Active Storageのプロキシモードでセッション情報が漏れる問題、セッションクッキーへのSameSite属性の欠落（Low）など、認証まわりの欠陥が複数含まれます。1件ずつの深刻度は中程度でも、「ログイン状態の扱い」がまとめて緩む構成です。

対策——更新が本筋、Disk利用者は秘密情報の交換まで

対策の本筋は、activestorageを含む各gemを修正版（8.0系は8.0.5.2、8.1系は8.1.4.1）へ上げることです。すぐに上げられない場合、各アドバイザリにパッチへのリンクがあります。あわせて、アドバイザリが示す注意点は次のとおりです。

• 修正版はImageMagickのセキュリティポリシーを同梱し、MiniMagick経由の全プロセスへ適用します。variant_processor = :mini_magick のアプリは、mini_magick 5.1以上が必要です（古いと起動時に例外になります）。
• PostScriptやPDFをImageMagickで描画するアプリは、Ghostscriptのデリゲートとコーダーを自前のポリシーで改めて許可する必要があります。逆に、起動後に MiniMagick.cli_env を差し替える構成では同梱ポリシーが効かず、システム側のポリシーへ規則を書く必要があります。
• 代替策として、同梱ポリシーの規則を /etc/ImageMagick-7/policy.xml のようなシステムポリシーへ写す方法も示されています。最低限、MSLコーダー、Ghostscript系コーダー、gs デリゲートを禁止する形です。
• 添付ファイルの保存先がDiskサービスのアプリは、secret_key_base と、アプリのプロセスが読める全ての秘密情報（マスターキー、認証情報ファイルの中身、ストレージやデータベースの認証情報、外部サービスのトークン）を交換し、漏れた可能性のある旧値を予備として残さないことが求められます。

8.0系は「修正版を当てて終わり」ではない

もう1つの期限が、バージョンの寿命です。公式発表は、8.0より古い版はサポート対象外としたうえで、8.0系のセキュリティサポートが2026年11月7日で終わることを明記しています。本記事の公開時点では、既に終了しています。

つまり8.0系の利用者にとって今回の修正版は「当面の安全」ではなく「移行までの猶予」です。8.0.5.2へ上げて穴を塞ぎ、その足で8.1系への移行を計画する、という二段構えが前提になります。サポートが終わった系統に残り続けると、次に同種の欠陥が出ても、公式の修正版はもう出てきません。

IT Postの見方

IT Postでは、今回の一番の論点は21件という件数ではなく、「アップロードを受け付ける普通のRailsアプリ」が、特別な設定ミスなしに未認証のファイル書き込みを抱えていた点だと考えます。条件は3つありますが、どれも「攻め側に都合のよい特殊な構成」ではなく、古くからある既定の組み合わせです。既定のまま長く運用してきたアプリほど、対象に近づく。フレームワークの欠陥は、利用者の落ち度とは切り分けて見るべき話です。

もう1つは出し方である。サポート終了の3日前に、終了する系統向けの最後の修正を出す。順序としては誠実だが、受け取る側の作業は「緊急更新」と「移行計画」が同時に降ってくる。IT Postでは、8.0系の利用者は今回の更新を移行プロジェクトの開始合図として扱うのが正解だと考えます。穴を1つ塞いで安心する回ではない。

今後どうなりそうか

今後の確認点は、個別の欠陥の技術詳細や検証コードの公開状況、実際の悪用の報告が出るかどうか、そして各社の8.1系への移行の進み具合です。21件の中には、パッチを当てれば終わるものと、Diskサービス利用者のように秘密情報の交換まで必要なものが混ざっています。自社の構成がどちらに当たるかを、アドバイザリの条件と突き合わせて確認してください。

IT Postでは、新しい公式情報が確認できれば、本記事を更新します。