--- title: "Railsに21件まとめて修正、未認証でファイル読み書きのCriticalも。8.0系は11月7日で守りが切れた" description: "Ruby on Railsの開発チームは2026年11月4日、セキュリティ修正版8.0.5.2と8.1.4.1を公開し、21件の脆弱性をまとめて修正した。最も深刻なのはActive Storageの画像解析で、ログインしていない攻撃者がサーバーへ任意のファイルを書き込み、条件次第で秘密情報まで読み取れる欠陥。8.0系のセキュリティサポートは11月7日で終了済みで、旧版利用者は修正版への更新と8.1系への移行計画が同時に必要になる" url: https://itpostjp.com/security/rails-security-releases-8-0-5-2-8-1-4-1-21-vulnerabilities-active-storage/ category: "セキュリティ" published_at: 2026-11-09T02:35:00Z updated_at: 2026-11-09T02:35:00Z author: "IT Post編集部" editor: "編集長 千田智也" publisher: "IT Post by Rice Studio Lab" language: ja-JP ai_generated: true ai_model: muse-wonder terms: ["クロスサイトスクリプティング（XSS）", "リモートコード実行（RCE）", "脆弱性"] --- # Railsに21件まとめて修正、未認証でファイル読み書きのCriticalも。8.0系は11月7日で守りが切れた IT Post編集部 ＆ 編集長 千田智也 Ruby on Railsの開発チームは2026年11月4日、セキュリティ修正版8.0.5.2と8.1.4.1を公開し、21件の脆弱性をまとめて修正した。最も深刻なのはActive Storageの画像解析で、ログインしていない攻撃者がサーバーへ任意のファイルを書き込み、条件次第で秘密情報まで読み取れる欠陥。8.0系のセキュリティサポートは11月7日で終了済みで、旧版利用者は修正版への更新と8.1系への移行計画が同時に必要になる ## 30秒で分かる結論 - Ruby on Railsの開発チームは2026年11月4日、セキュリティ修正版の8.0.5.2と8.1.4.1を公開し、合わせて21件の脆弱性を修正しました。対象はファイル管理機能のActive Storageを中心に、Action Pack、Action View、Active Supportなど広範囲に及びます。 - 最も深刻な1件（GHSA-f3w6-w445-fwh9、深刻度Critical）は、画像解析に使うImageMagickの処理に関する欠陥です。条件を満たすアプリでは、ログインしていない攻撃者が細工したファイルをアップロードするだけで、サーバーへ任意のファイルを書き込めます。保存先がDiskサービスの場合は、アプリが読める任意のファイル（秘密鍵や外部サービスの認証情報を含む）まで読み取られる可能性があります。 - 8.0系のセキュリティサポートは2026年11月7日で終了しました。8.0より古い版はもともとサポート対象外です。今回の修正版へ上げたうえで、8.1系への移行計画まで一気に進める必要があります。 ## まず初めに 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）](https://itpostjp.com/security/rails-active-storage-rce-cve-2026-66066/)を伝えています。今回は別の欠陥群であり、前回の修正を当てただけでは足りません。 ![Railsセキュリティ修正版（2026年11月4日）の内容](/images/articles/rails-security-releases-8-0-5-2-8-1-4-1-21-vulnerabilities-active-storage-inline-1.webp) ## 最も深刻な欠陥——アップロードするだけでファイルが書ける 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では、新しい公式情報が確認できれば、本記事を更新します。 ## 情報源 「一次情報」は資料の出所を示す区分で、編集部による独立した実測や、すべての主張の実証を示すものではありません。確認の範囲や未確認の点は、本文の説明と併せてご覧ください。 - [Rails security releases: 8.0.5.2 and 8.1.4.1](https://discuss.rubyonrails.org/t/rails-security-releases-8-0-5-2-and-8-1-4-1/91802) — Ruby on Rails（公式フォーラム）（一次情報） - [Rails Releases Security Update Covering 21 Vulnerabilities](https://www.isec.news/2026/11/05/rails-security-update-21-vulnerabilities/) — iSec News ## この記事に出てくるIT用語 - [クロスサイトスクリプティング（XSS）](https://itpostjp.com/terms/cross-site-scripting-xss/): Webサイトの入力処理の不備を突いて、悪意あるプログラムを閲覧者や管理者のブラウザ上で実行させてしまう攻撃手法です。 - [リモートコード実行（RCE）](https://itpostjp.com/terms/remote-code-execution/): 攻撃者が、遠く離れた場所から対象のコンピューターやサーバーで、任意のプログラムを実行できてしまう状態を指します。 - [脆弱性](https://itpostjp.com/terms/vulnerability/): ソフトウェアやシステムに存在する、悪用されると情報の窃取や不正操作につながりかねない設計・実装上の欠陥のことです。 --- この記事は、公開情報と出典URLの検証、文章作成の一部に生成AIを使用しています。内容の責任はIT Post by Rice Studio Labが負います。 出典表記: IT Post by Rice Studio Lab — https://itpostjp.com/security/rails-security-releases-8-0-5-2-8-1-4-1-21-vulnerabilities-active-storage/