--- title: "Railsの脆弱性21件：8.1.4.1・8.0.5.2の修正内容とActive Storageの回避策" url: "https://www.issoh.co.jp/tech/details/19374/" published: 2026-11-05 updated: 2026-11-05 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Railsの脆弱性21件：8.1.4.1・8.0.5.2の修正内容とActive Storageの回避策 Ruby on Railsは2026年11月4日、8.0.5.2と8.1.4.1を公開し、21件のセキュリティ問題を修正しました。最も深刻なのは、Active Storageが画像を解析するときに、細工したファイル1枚でサーバー上のファイルを読み書きされる問題で、CVSSは9.8です。この記事では、影響を受ける条件の見分け方、Gemfile.lockと設定値での判定、更新の手順、すぐ上げられない場合の回避策、秘密情報を入れ替えるべき条件を、2026年11月5日時点の一次情報で整理します。 ## まとめ：8.1.4.1へ上げ、画像処理の方式とアップロード経路を当日中に点検 対応の本線は、8.1系なら8.1.4.1、8.0系なら8.0.5.2への更新です。ただし8.0系のセキュリティ修正は2026年11月7日で終わるため、8.0系の利用者は続けて8.1系への移行計画も要ります。7.2系以前には修正版が出ません。Railsを土台にするパッケージ製品は、製品側の更新を待つことになります。たとえば国産CMSのSHIRASAGIは、2026年11月5日公開のv1.21.1でもRails 8.1.3.1を同梱しています（[SHIRASAGIの脆弱性2件：影響版の確認とv1.21.1への更新手順](https://www.issoh.co.jp/tech/details/19376/)）。 当日中に確かめるのは、Active Storageの画像処理がImageMagick（`:mini_magick`）かどうかと、誰でもファイルをアップロードできる画面があるかの2点です。両方に当てはまり、保存先がDiskサービスなら、更新に加えて`secret_key_base`などの秘密情報の入れ替えを検討します。 Railsアプリが複数あり、どれが条件に当てはまるか洗い出せない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でアップロード経路の棚卸しから始めると漏れが出にくくなります。 ## 2026年11月のRailsセキュリティリリース：21件の内訳と修正版が出る系統 [Rails公式ブログの告知](https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-have-been-released)によると、内訳はCritical1件、High4件、Medium13件、Low3件です。21件のうち8件がActive Storageで、残りはAction Pack・Action View・Active Support・Action Mailboxなどに分かれます。 ### Critical1件とHigh4件の内訳：画像解析と入力・接続元の問題 画像解析・Strong Parameters・RemoteIpなどがこの5件の対象です。個別の内容は、各GitHub Security Advisory（GHSA）に書かれています。いずれも2026年11月5日時点で「No known CVE」で、CVE番号は振られていません。 | 深刻度 | GHSA | 部品 | 内容 | CVSS | | -------- | -------------- | --------------- | ---------------------- | ---- | | Critical | f3w6-w445-fwh9 | Active Storage | 画像解析での任意ファイル読み書き | 9.8 | | High | v924-7rp8-4mxh | Active Storage | 動画・音声解析での読み取りとRCE | 8.8 | | High | wm3x-v3qw-4jh3 | Action Pack | each\_keyでパラメータ許可制限を回避 | 7.5 | | High | 8474-xrp6-wh69 | Active Support | safe\_constantizeでのDoS | 7.5 | | High | 2gff-2mmg-m73p | Action Dispatch | ForwardedでのIP詐称（8.1のみ） | 7.4 | Criticalの[GHSA-f3w6-w445-fwh9](https://github.com/rails/rails/security/advisories/GHSA-f3w6-w445-fwh9)は、添付した瞬間に走る画像解析だけで成立します。ImageMagickはファイルの中身から読み込み方式（コーダー）を選び、一部のコーダーには画像に書かれた別のファイルを読みに行く動作があるためです。変換やプレビューを呼んでいなくても、攻撃者は認証なしでファイルを書き込めます。Disk保存なら、アプリのプロセスが読める任意のファイルも読まれます。 Highの4件で見落としやすいのは2つです。[safe\_constantizeのDoS](https://github.com/rails/rails/security/advisories/GHSA-8474-xrp6-wh69)は、Action Cableが`subscribe`の`channel`値を渡すため、新規アプリが既定でマウントする`/cable`から未認証で届きます。[RemoteIpの詐称](https://github.com/rails/rails/security/advisories/GHSA-2gff-2mmg-m73p)は、Rack 3で動く8.1.0〜8.1.4だけが対象で、`rate_limit`の既定の`by:`がすり抜けます。各指標の読み方は[CVSSv3のスコアの目安と計算式](https://www.issoh.co.jp/tech/details/5094/)で確かめてください。 ### 7.2系以前と8.0系の扱い：修正版が出ない系統と11月7日のサポート終了 GHSAの影響範囲は、多くが「8.0.5.2未満」と「8.1以上8.1.4.1未満」です。7.2系や7.1系も8.0.5.2未満に含まれるため、該当する機能を使っていれば対象です。 それでも修正版は出ません。[Railsの保守ポリシー](https://rubyonrails.org/maintenance)の表に載っているのは8.1系と8.0系だけで、8.1系のセキュリティ修正は2027年10月10日まで、8.0系は2026年11月7日までです。[RubyGemsの版一覧](https://rubygems.org/gems/rails/versions)でも、7.2系の最新は9月24日の7.2.4で止まっています。 7.2系のサポート終了日と、8.1へ上げるときに壊れやすい設定は[Rails 7.2のEOLと8.1への移行](https://www.issoh.co.jp/tech/details/3362/)で整理しています。7.2系のまま止めるなら、下の回避策を当てたうえで移行の期日を決めてください。 ## 自分のアプリが対象か判定する手順：Gemfile.lockと設定値の確認コマンド 判定は「版」と「使っている機能」の2段で行います。21件すべてが全アプリに当てはまるわけではありません。 ### Gemfile.lockとActive Storageの画像処理方式の確認コマンド ``` # 動いているRailsと関連gemの版 bundle exec rails -v bundle list | grep -E "activestorage|actionpack|actionview|mini_magick|image_processing| rack " # Active Storageの画像処理方式（:mini_magickならCriticalの対象候補） bin/rails runner 'p Rails.application.config.active_storage.variant_processor' # 保存先サービス（Diskなら読み取り被害の対象） grep -n "service:" config/storage.yml grep -rn "active_storage.service" config/environments/ # ImageMagickの版と、いま効いているポリシー magick -version || convert -version magick -list policy || convert -list policy ``` Criticalの対象になるのは、`:mini_magick`を使い、ImageMagickのポリシーが危険なコーダーを拒否しておらず、信頼できない利用者のアップロードを受ける場合です。`load_defaults 6.1`以前で作ったアプリは、設定を書いていなくても`:mini_magick`が既定になります。GHSAは、DebianとUbuntuの標準ポリシーでは拒否されないと書いています。 コマンドはRailsとImageMagickの標準コマンドで、私たちは今回の判定には実行していません。CarrierWaveなどActive Storage以外でImageMagickを呼んでいる場合は、この表の対象外でも同じコーダーの問題を抱えます。両者の違いは[CarrierWaveとActive Storageの使い分け](https://www.issoh.co.jp/tech/details/3522/)で解説しています。 ### git grepで入力処理・HTML出力・セッション保存の使用箇所を洗い出す each\_key・strip\_tags・cache\_storeをgit grepで検索し、次の使用箇所を確認してください。アプリのコードの書き方しだいで当たる問題は、検索で絞れます。 ``` # Strong Parameters回避：each_keyの戻り値をnew・update等に渡していないか git grep -n "each_key" -- app/ lib/ # strip_tagsのXSS：属性値の中で出力していないか git grep -n "strip_tags" -- app/views/ app/helpers/ # 破棄済みセッションの復元：セッションをキャッシュに置いていないか git grep -n "cache_store" -- config/ # safe_constantizeに外部入力を渡していないか git grep -n "safe_constantize" -- app/ lib/ ``` [each\_keyの問題](https://github.com/rails/rails/security/advisories/GHSA-wm3x-v3qw-4jh3)は、2020年のCVE-2020-8164の修正で`each_key`だけが直っていなかったものです。ブロック付きで呼ぶと許可前のハッシュが返り、それを`update`に渡すと管理者フラグなどを書き換えられます。[strip\_tagsの問題](https://github.com/rails/rails/security/advisories/GHSA-rq8q-p985-fjq7)は、`title`属性や``の中で出力しているときだけ成立し、本文として出している箇所は対象外です。[CacheStoreの問題](https://github.com/rails/rails/security/advisories/GHSA-2586-8ghr-69fj)は`config.session_store :cache_store`のアプリに限られ、CookieStoreは当たりません。 ## 8.1.4.1・8.0.5.2への更新手順と画像処理gemの前提条件 bundle updateで更新し、mini\_magickを使う場合の前提は5.1以上です。パッチ版の更新なので、アプリのコードを書き換える場面は限られます。ただし今回は、更新後に起動しなくなる条件が1つあります。 ### Rails関連gemだけを更新するbundle updateの実行手順 ``` # Gemfile：8.1系なら gem "rails", "~> 8.1.4", ">= 8.1.4.1" # 8.0系なら # gem "rails", "~> 8.0.5", ">= 8.0.5.2" # Rails関連gemだけを上げ、ほかの依存は動かさない bundle update --conservative rails bundle exec rails -v # mini_magickを使う場合は5.1以上が必要 bundle update --conservative mini_magick bundle list | grep mini_magick ``` `--conservative`を付けると、Railsが直接要求しない依存は今の版に留まります。公式ブログはgemのSHA-256も載せているので、社内のミラーを通す組織は照合に使えます。上の手順はBundlerの標準機能をもとに書いたもので、私たちは未実行です。 ### 更新後の起動・通信で例外が出る条件：画像処理gemの版とプロキシ設定 mini\_magickの版とIpSpoofAttackErrorの発生条件を含め、先に確かめたい変化は3つあります。 1. mini\_magickが5.1未満だと、起動時に例外で止まります。GHSA-f3w6-w445-fwh9は、修正版の前提としてmini\_magick 5.1以上を挙げています。 2. PDFやPostScriptのプレビューを作っているアプリは、修正版が同梱するポリシーで`gs`デリゲートとPDF系コーダーが拒否されます。必要ならホストの`policy.xml`で許可し直します。 3. 8.1系でプロキシの裏に置いたアプリは、`Forwarded`と`X-Forwarded-For`の値が食い違うと`ActionDispatch::RemoteIp::IpSpoofAttackError`になります。プロキシが両方を書く構成では、ステージングで1度通してから本番に出します。 PDFの添付を受ける業務システムでは、2が最も気づきにくい変化です。プレビュー画像が出なくなっても例外にならない画面があるため、手動で1件アップロードして確かめます。更新から再起動までを定例化する仕組みは[パッチ管理の手順](https://www.issoh.co.jp/tech/details/19309/)で扱っています。 ## すぐ更新できないときの回避策：ImageMagickのpolicy.xmlと設定の外し方 回避策はどれも、特定の経路を塞ぐだけです。修正版への更新の代わりにはなりません。 ### ImageMagickのシステムポリシーでMSLやPDF系コーダーを拒否する設定 GHSA-f3w6-w445-fwh9は、修正版が同梱する`policy.xml`の規則を、ホストのシステムポリシー（例：`/etc/ImageMagick-7/policy.xml`）へ写すよう示しています。最低限、次の3行を``の中に入れます。 ``` ``` 入れたあとは`magick -list policy`で反映を確かめます。`MiniMagick.cli_env`を後から置き換えている、`MiniMagick.cli_prefix`で環境変数を消している、独自の`MiniMagick::Shell`を使っている、のどれかに当てはまると、修正版でもシステム側のポリシーを自分で管理する必要があります。GraphicsMagickはImageMagickのポリシーを読まないので、この設定は効きません。 ### 動画解析の無効化・Forwarded無視・Action Cableの認証で塞ぐ範囲 ``` # config/initializers/security_workarounds.rb（修正版へ上げたら削除） # GHSA-v924-7rp8-4mxh：動画・音声の解析とプレビューを止める Rails.application.config.active_storage.previewers -= [ActiveStorage::Previewer::VideoPreviewer] Rails.application.config.active_storage.analyzers -= [ ActiveStorage::Analyzer::VideoAnalyzer, ActiveStorage::Analyzer::AudioAnalyzer ] # GHSA-2gff-2mmg-m73p（8.1のみ）：Forwardedを無視しX-Forwarded-Forだけを見る Rack::Request.forwarded_priority = [:x_forwarded] # GHSA-8474-xrp6-wh69：Action Cableを使わないならエンドポイントを外す Rails.application.config.action_cable.mount_path = nil ``` 動画の回避策で塞げるのは、`--enable-avisynth`付きのFFmpegが`.avs`をスクリプトとして実行する経路です。[GHSA-v924-7rp8-4mxh](https://github.com/rails/rails/security/advisories/GHSA-v924-7rp8-4mxh)によると、ffmpeg.orgが配るWindows・Linux向けのGPLビルドはAviSynthが有効で、一般的なディストリのパッケージは無効です。ImageMagickが拡張子で読み込み方式を選ぶ問題は、この設定では残ります。 `forwarded_priority`はRack 3.0.0以降で使え、scheme・host・portの判定でも`Forwarded`を見なくなります。Action Cableを使うアプリは、`ApplicationCable::Connection#connect`で未認証の接続に`reject_unauthorized_connection`を呼びます。これは攻撃できる人をログイン済みの利用者に絞るだけで、問題そのものを解消する対策ではありません。接続認証の書き方は[Action CableのWebSocket実装](https://www.issoh.co.jp/tech/details/5809/)で確かめられます。上のコードは各GHSAの記載から書いたもので、私たちは未実行です。 ## 秘密情報のローテーション判断：Disk保存で漏えいを前提にする条件と順番 CriticalとHighの各1件について、GHSAは条件に当てはまるアプリに秘密情報の入れ替えを求めています。ここは更新と別の作業として計画します。 ### secret\_key\_baseを替えると無効になるものと、入れ替えの順番 入れ替えの対象は、`secret_key_base`、マスターキー、`config/credentials.yml.enc`の中身、ストレージとデータベースの認証情報、外部サービスのトークンなど、アプリのプロセスが読めた秘密情報すべてです。`secret_key_base`を替えると、セッション、署名・暗号化したCookie、署名付きGlobalID、Active StorageのURLがまとめて無効になります。 順番は、外部サービスのトークンとデータベースの認証情報を先に替え、利用者の再ログインが発生する`secret_key_base`を最後にします。GHSAは、漏れた値をフォールバック（旧値）として残さないよう求めています。古いCookieを読める期間を設けると、攻撃者もその期間だけ署名を偽造できるからです。トークンの失効手順は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)でまとめています。 ### ローテーションを見送るアプリと、個人情報の報告義務を検討する場面 私たちの判断は、条件で線を引きます。画像処理が`:vips`、または保存先がS3などのクラウドで、かつ動画の解析にAviSynth付きのFFmpegを使っていないアプリは、更新だけで済ませて構いません。`:mini_magick`とDisk保存の組み合わせで、誰でもアップロードできる画面を持っていたアプリは、痕跡が無くても入れ替えます。読み取りはログに残りにくく、無いことを証明できないからです。 読まれた可能性のある認証情報で、個人データを持つデータベースに入れた場合は、漏えいの「おそれ」の段階で報告義務が生じえます。速報と確報の期限は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で確かめてください。社内で判断材料を揃えられない場合は、[脆弱性診断の種類と外注時の判断基準](https://www.issoh.co.jp/column/details/13101/)を参考に、外部の診断で痕跡の確認を進める方法もあります。 ## Railsの脆弱性8.1.4.1・8.0.5.2の対応でよく受ける質問と回答 更新作業の前後で出やすい疑問に、2026年11月5日時点の一次情報の範囲で答えます。 ### Active Storageを使っていないアプリも更新が必要ですか？ 必要です。21件のうち13件はActive Storage以外で、Action Viewのヘルパーで起きるXSS4件や、Action Cable経由で未認証から届くDoSを含みます。`/cable`は新規アプリで既定でマウントされるため、使っているつもりが無くても入口が開いていることがあります。Active Storageの有無に関わらず、8.1.4.1か8.0.5.2へ上げてください。 ### CVE番号が無いのは、深刻ではないということですか？ 違います。CriticalのGHSA-f3w6-w445-fwh9もCVSS 9.8で、2026年11月5日時点で全件が「No known CVE」の表示です。CVE番号が無いと、JVNやNVDを見る脆弱性管理ツールでは検知されないことがあります。Railsの問題はGHSAで追い、DependabotなどGitHub Advisory Databaseを参照する仕組みで照合します。 ### Rails 7.2系向けの修正パッチはありますか？ 公式の7.2系向けリリースは出ていません。各GHSAには8.1系と8.0系のコミットのパッチが載っていますが、7.2系に当たるかは自分で検証する必要があります。7.2系は自前でパッチを当て続けるより、上の回避策で時間を稼ぎつつ8.1系へ上げる方が保守の手間は小さく済みます。 ### Rubyの脆弱性とRailsの脆弱性は別々に対応しますか？ 別々です。Ruby本体の問題はRubyの版を上げて直し、Railsの問題はgemを上げて直します。ただし今回の`safe_constantize`のDoSは、Rubyの正規表現コンパイラの不具合を突くものです。Ruby側の修正状況は[Rubyの正規表現エンジンの脆弱性](https://www.issoh.co.jp/tech/details/19129/)で確かめ、両方を同じ保守枠で上げると再起動が1回で済みます。 ### 実際に悪用されているかはどこで確かめられますか？ 2026年11月5日時点で、公式ブログと各GHSAに悪用を確認したという記載はありません。悪用の有無は、米CISAのKEVカタログへの登録と、GHSAの更新で追います。Criticalは認証なしで、ファイルを1枚送るだけで成立します。悪用の確認を待たずに更新を進めてください。日々の実装で守る基本は[Railsガイドのセキュリティ章](https://guides.rubyonrails.org/security.html)にまとまっています。 ## 関連記事 - [Rubyの脆弱性：正規表現エンジン4件の修正版とRailsでの影響箇所の洗い出し](https://www.issoh.co.jp/tech/details/19129/)：Ruby本体側の脆弱性と、Railsアプリへの波及の調べ方です。 - [Rails 7.2のEOLは2026年8月9日｜最終版7.2.4と8.1への移行で壊れる設定](https://www.issoh.co.jp/tech/details/3362/)：修正版が出ない7.2系から8.1系へ移る手順です。 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：秘密情報を入れ替えたあとのトークン失効と認可の見直しです。 - [パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順](https://www.issoh.co.jp/tech/details/19309/)：gemとOSの更新を定例化する仕組みづくりです。 - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：アップロード経路の棚卸しを外部に頼むときの判断材料です。 --- 出典: [Railsの脆弱性21件：8.1.4.1・8.0.5.2の修正内容とActive Storageの回避策]()（株式会社一創）