CVE-2026-66066 Rails の脆弱性｜libvips 8.13 要件と鍵の再発行手順

はじめに

2026 年 7 月 29 日、Ruby on Rails のセキュリティチームから Active Storage に関する重大な脆弱性 CVE-2026-66066 が公表されました。攻撃者が細工したファイルをアップロードすることで、サーバー上の任意のファイルを読み取られる可能性があるというものです。発見者によって KindaRails2Shell と名付けられています。

自社サービスに Rails アプリケーションが含まれている場合、まず気になるのは「うちは該当するのか」「どのバージョンに上げればよいのか」という点だと思います。加えて本件は、修正版を適用するだけでは対応が完結しないという特徴があります。

結論として、影響を受ける条件は「Active Storage の画像処理に libvips を使用していること」と「信頼できないユーザーからの画像アップロードを許可していること」の 2 点です。修正版は activestorage 7.2.3.2 / 8.0.5.1 / 8.1.3.1 の 3 系列で、適用にあたっては libvips 8.13 以降と ruby-vips 2.2.1 以降が前提となり、条件を満たさない環境ではアプリケーションが起動時に例外を送出します。さらに、影響を受けた可能性がある環境では secret_key_base をはじめとする秘密情報のローテーションが推奨されています。

CVE-2026-66066 の概要と深刻度

CVE-2026-66066 は、Active Storage が画像のバリアント処理を libvips に委ねる際の初期設定に起因する脆弱性です。単独の実装バグではなく、安全でないデフォルト値がそのまま運用されていた点が問題の中心にあります。

起点は任意ファイル読み取り

公式 Advisory によれば、デフォルト構成の Rails アプリケーションで画像バリアントを表示している場合、認証されていない攻撃者がサーバー上の任意のファイル、およびプロセスの環境変数を読み取れる可能性があります。環境変数には通常 secret_key_base や外部システムの資格情報が含まれるため、そこからリモートコード実行や他システムへの横展開に発展する可能性がある、という位置づけです。

つまり、脆弱性そのものは任意ファイル読み取りであり、リモートコード実行は読み取られた秘密情報を起点として成立しうる二次的な結果です。「RCE の脆弱性」という表現で流通していますが、対処を検討する際はファイル読み取りと秘密情報の漏えいを前提に考えるほうが、対応範囲を見誤りにくくなります。

技術的な背景としては、libvips がファイル形式の読み書きに使用する「ローダー」「セーバー」のうち、一部が「unfuzzed」（信頼できないコンテンツの処理には適さない）として区別されている点が挙げられます。Active Storage はこれらを無効化していなかったため、細工されたファイルをアップロードできる攻撃者が該当のローダーを呼び出せる状態にありました。

CVSS v4 は 9.5、CWE-1188

GitHub が CNA として付与した CVSS v4 のベーススコアは 9.5（Critical）で、ベクターは CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H です。脆弱性タイプは CWE-1188（Initialization of a Resource with an Insecure Default、安全でないデフォルト値でのリソース初期化）に分類されています。

ネットワーク経由で、認証も利用者の操作も不要という条件が、スコアの高さに反映されています。

技術詳細は前倒しで公開された

当初、Rails チームは攻撃チェーンの技術的な詳細を Advisory から意図的に除外し、遅くとも 2026 年 8 月 28 日までに Rails Security Announcements で開示する方針を示していました。未更新のアプリケーションへの攻撃を容易にしないための判断です。

ところが、複数の研究者が短期間で攻撃手法をリバースエンジニアリングし、実証コードを公開したことを受けて、Rails チームは 2026 年 7 月 31 日に攻撃の詳細とフォレンジック用のツール群を前倒しで公開しました。

参考: [CVE-2026-66066] Attack details, and tools to perform a forensic investigation（Ruby on Rails Discussions）
“several researchers quickly reverse-engineered the attack and have already published proofs-of-concept”
（複数の研究者が短期間で攻撃をリバースエンジニアリングし、すでに実証コードを公開しています）
https://discuss.rubyonrails.org/t/cve-2026-66066-attack-details-and-tools-to-perform-a-forensic-investigation/91441

実証コードが公開されていない期間を猶予として見込む前提は、この種の脆弱性では成り立ちにくくなっています。同時期に公表された WordPress の wp2shell についても同様の傾向がみられました。対応の進め方は関連記事『WordPress wp2shell 対応｜更新確認とアクセスログ点検の手順』でも整理しています。

なお本件は、Ethiack の 0xacb 氏、s3np41k1r1t0 氏、castilho 氏と、GMO Flatt Security の RyotaK 氏によって、それぞれ独立に報告されたものです。

影響を受ける条件と対象バージョン

自社のアプリケーションが該当するかどうかは、バージョンと構成の 2 軸で確認します。

対象となる activestorage のバージョン範囲

公式 Advisory は、パッケージを Rails 本体ではなく RubyGems の activestorage 単位で定義しています。影響を受けるのは 7.2.3.2 未満、8.0 以上 8.0.5.1 未満、8.1 以上 8.1.3.1 未満の各バージョンで、修正版は 7.2.3.2 / 8.0.5.1 / 8.1.3.1 です。

インストール済みのバージョンは、アプリケーションのディレクトリで次のように確認できます。

bundle list | grep activestorage
bundle exec rails -v

libvips がデフォルトになる条件

構成面の判定基準は、バリアントプロセッサーの設定値です。

参考: Possible arbitrary file read and remote code execution in Active Storage variant processing（GitHub Security Advisory GHSA-xr9x-r78c-5hrm）
“Generating variants is not a separate requirement.”
（バリアントを生成していることは、別途の要件ではありません）
https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm

Advisory が挙げる条件は、config.active_storage.variant_processor = :vips を使用していること（load_defaults 7.0 で設定され、それ以降のデフォルトでも変更されていません）と、信頼できないユーザーからの画像アップロードを許可していることの 2 点です。バリアントの生成有無は独立した条件ではありません。

Rails Guides の Configuring Rails Applications でも、7.0 のデフォルト値として config.active_storage.variant_processor: :vips が記載されています。実際の設定値は、次のように確認できます。

bundle exec rails runner 'puts Rails.application.config.active_storage.variant_processor'

出力が vips であれば、構成面の条件に該当します。mini_magick であれば、この経路では影響を受けません。

なお、config.load_defaults の指定値が 7.0 未満のまま運用されているアプリケーションでは、明示的に :vips を指定していない限り mini_magick のままです。Rails 本体のバージョンだけで判断せず、実際の設定値を確認することをおすすめします。

Rails 6.x 系と ImageMagick 構成の扱い

Rails 6.x 系については、Advisory の影響範囲（7.2.3.2 未満）に形式上は含まれますが、修正版はリリースされていません。6.x 系はデフォルトのバリアントプロセッサーが mini_magick であるため、:vips を明示的に設定している場合に限って影響を受ける構成となります。

6.x 系を運用している場合の選択肢は、サポート対象の系列へアップグレードするか、バリアントプロセッサーを mini_magick に変更するか、libvips 側で unfuzzed なローダーを無効化するか、のいずれかになります。libvips 側での回避手順は後述のセクションで扱います。

ImageMagick（MiniMagick）を使用している場合、本脆弱性の経路では影響を受けません。ただし、libvips が内部で ImageMagick に処理を委譲する構成もあるため、vips -l の出力で委譲先を確認しておくと判断しやすくなります。

影響を受けやすい実行環境

libvips は、環境によってビルド時に多様なローダーが有効化されます。Rails が生成する公式の Docker イメージや、Debian / Ubuntu 系のパッケージで導入された libvips は、攻撃に必要なライブラリを標準で含む構成になっていると報告されています。一方で、ディストリビューションやベースイメージによっては、必要なローダーが含まれず攻撃が成立しない場合もあります。

この点はインフラ側の担当範囲に直結します。同一のアプリケーションコードでも、コンテナのベースイメージやビルド時のパッケージ構成によって成立条件が変わるため、開発環境で再現しないことをもって本番環境が安全であると判断しない運用が求められます。

公開された攻撃の流れと読み取られる情報

攻撃の詳細が公開されたことで、なぜこの脆弱性が成立するのかを構造として把握できるようになりました。防御側にとっては、影響範囲の見積もりと調査対象の絞り込みに直結する情報です。

二段階の形式判定が食い違う

Rails 公式のフォレンジックリポジトリの説明によれば、成立の起点は「ファイルの種類を誰が判定するか」が二重になっている点にあります。Rails はダイレクトアップロードでクライアントが指定した content_type の値を読んで、その blob を画像処理の対象としてよいかを決めます。バイト列そのものは検査されません。一方 libvips は、ファイル先頭のマジックバイトを見て実体を判定します。

この結果、先頭のバイト列が MATLAB 形式を名乗るファイルは libvips の MATLAB ローダーへ渡され、そこから libmatio に引き継がれます。libmatio は別のバイト範囲を見て MAT 7.3 形式、すなわち HDF5 であると判断します。HDF5 には External File List という仕組みがあり、データセットの実体をパスとオフセットで指定した別ファイルに置くことができます。したがって、この「画像」を描画する処理が、攻撃者の指定したサーバー上のファイルを読み取り、その内容をピクセル値として返す動作になります。

互いのフィールドを参照できない 2 つの層で、同じ種類の取り違えが 2 回発生しているという構造です。Rails 側の入力検証だけでも、libvips 側の形式判定だけでも捕捉しきれないため、Active Storage 側で unfuzzed なローダーを一括して無効化する方針が修正版で採られています。

読み取られる可能性がある情報

読み取り対象は、アプリケーションプロセスの権限で参照できるファイルです。実務上は、Linux であればプロセスの環境変数を保持する領域が最初の標的になると考えられます。ここには secret_key_base や RAILS_MASTER_KEY、データベースやオブジェクトストレージの資格情報が含まれることが一般的です。

署名鍵が渡ってしまうと、Active Storage の署名付き URL やバリアント指定を攻撃者が自ら生成できる状態になります。リモートコード実行に発展しうるとされている理由はここにあります。すでに攻撃を再現するモジュールが公開ツールへ提出されたとの報道もあり、「実証コードが出回っていないうちは猶予がある」という前提は成り立たない状況です。

調査が可能な理由

対応を検討するうえで押さえておきたいのが、この攻撃が痕跡を残すという点です。

参考: rails-forensics-CVE-2026-66066（Ruby on Rails 公式リポジトリ）
“This repository deliberately ships no code that builds crafted files, and no crafted files.”
（このリポジトリは、細工されたファイルを生成するコードも、細工されたファイル自体も、意図的に同梱していません）
https://github.com/rails/rails-forensics-CVE-2026-66066

攻撃は強度の異なる 3 種類の痕跡を残し、そのうち最も強い証拠は生成されたバリアントそのものです。読み取られたバイト列がピクセル値として、自社のオブジェクトストレージ内に残っている可能性があります。この性質を利用した調査手順は、後述のセクションで扱います。

修正版への更新手順と libvips 8.13 要件

修正版の適用は、通常のパッチ適用と同じ手順で進められます。ただし、libvips と ruby-vips のバージョン要件が加わる点が本件の特徴です。

修正版へのアップデート

Gemfile のバージョン指定を修正版に合わせたうえで、次のように更新します。--conservative を付けることで、Gemfile.lock 内の他の gem を巻き込まずに Rails のみを更新できます。

# Rails のみを修正版へ更新
bundle update rails --conservative

# 適用後のバージョン確認
bundle exec rails -v
bundle list | grep -E 'activestorage|ruby-vips'

コンテナで運用している場合は、キャッシュされた古いレイヤーが残らないよう、イメージを再ビルドしたうえでデプロイする流れになります。

docker build --no-cache -t your-app:patched .

libvips 8.13 と ruby-vips 2.2.1 の要件

修正版の実装は、libvips 側の機能に依存しています。

参考: Active Storage Overview（Ruby on Rails Guides）
“Active Storage disables all of them while your application boots, before any initializer runs.”
（Active Storage は、イニシャライザーが実行される前、アプリケーションの起動中にそれらをすべて無効化します）
https://edgeguides.rubyonrails.org/active_storage_overview.html

Rails Guides では、libvips が unfuzzed と印を付けている読み込み・書き出し処理を Active Storage が起動時に一括で無効化すること、そのために libvips 8.13 以降と ruby-vips 2.2.1 以降が最低要件となることが明記されています。ruby-vips がインストールされていて、いずれかの要件を満たさない場合、Active Storage は安全を確保できない環境で動作を続けるのではなく、起動時に RuntimeError を送出します。

この挙動は、パッチ適用作業を計画するうえで最も注意したい点です。 アプリケーションのバージョンだけを上げてデプロイした結果、libvips が古いままの実行環境ではプロセスが起動しません。事前に次の 2 点を確認しておくことをおすすめします。

# libvips のバージョン確認
vips --version

# ruby-vips のバージョン確認
bundle list | grep ruby-vips

libvips はディストリビューションのパッケージで導入されることが多いため、ベースイメージによっては 8.13 未満のまま固定されている場合があります。その場合はベースイメージの更新や、libvips のビルド方法の見直しが先行作業になります。

変換できなくなる画像形式

Guides では、ImageMagick 自体が unfuzzed なローダーとして扱われ、デフォルトで無効化されることも示されています。多くのプラットフォームで libvips は BMP、ICO、PSD の読み込みを ImageMagick に委譲しているため、これらの形式の添付ファイルはデフォルトでは変換できなくなります。

添付やダウンロード自体は引き続き動作しますが、該当形式のバリアント生成を行っているアプリケーションでは、更新後にエラーが発生する可能性があります。ユーザーがアップロードしてきた形式の実績を事前に集計しておくと、影響の有無を判断しやすくなります。

すぐに更新できない場合の暫定回避

Advisory では、libvips のバージョンに応じた回避策が示されています。

画像解析の用途でのみ ruby-vips を依存に含めているアプリケーションであれば、Gemfile から ruby-vips を外すことで libvips への依存を解消できる場合があります。Active Storage を使用していないアプリケーションでは、同様に ruby-vips を外すことで起動時チェックを回避できます。

いずれも恒久対処ではなく、修正版を適用するまでの時間を確保するための手段という位置づけです。

WAF による仮想パッチも、更新までの緩和策として検討できます。ただし、ダイレクトアップロードのリクエスト自体は正規の機能であり、判定の手がかりはアップロードされたファイルの先頭のバイト列に限られます。検知ルールの精度と誤検知の兼ね合いを踏まえた運用が求められます。WAF の役割と限界については関連記事『WAF の仕組みと導入判断のポイント』で整理しています。また、更新前の時間稼ぎとして仮想パッチを使う考え方は『FortiGate の仮想パッチ機能の設定手順』でも扱っています。

多層防御としての画像処理の隔離

今回の件を受けて、画像処理を高い権限のプロセスから切り離す動きも出ています。Rails のフォーラムでは、Discourse が Linux の Landlock を利用して画像処理プロセスの権限を制限する取り組みを進めていることが共有されました。環境変数の除去、リソース制限、ネットワークアクセスの遮断などを組み合わせ、画像処理ライブラリに脆弱性があった場合の影響範囲を抑える考え方です。

画像処理ライブラリは多数のサードパーティライブラリに処理を委譲するため、同種の問題が再発する余地は残ります。個別の CVE への対応と並行して、画像処理を最小権限のプロセスに閉じ込める設計を検討しておくと、次回の同種の脆弱性に対する備えになります。

秘密情報のローテーションと侵害調査

本件の対応が通常のパッチ適用と異なるのは、修正版の適用が「これ以上読み取られないようにする」措置にとどまる点です。すでに読み取られていた場合、その事実は更新によって取り消されません。

参考: KindaRails2Shell: CVE-2026-66066, Critical Arbitrary File Read and Possible Remote Code Execution in Ruby on Rails（Rapid7）
“remediating affected applications on an urgent basis, outside of normal patch cycles”
（影響を受けるアプリケーションについて、通常のパッチ適用サイクルの外で緊急に対処すること）
https://www.rapid7.com/blog/post/etr-kindarails2shell-cve-2026-66066-critical-arbitrary-file-read-and-possible-remote-code-execution-in-ruby-on-rails/

ローテーションの対象

Advisory では、影響を受けたアプリケーションについて、アプリケーションプロセスが読み取れるすべての秘密情報を漏えいした可能性があるものとして扱い、変更することが推奨されています。挙げられている対象は次のとおりです。

• secret_key_base
• マスターキー（config/master.key に保存されているもの、または RAILS_MASTER_KEY として与えられているもの）と、それによって復号される config/credentials.yml.enc の内容すべて
• Active Storage のサービス用資格情報（S3、GCS、Azure などのキー）
• データベースの資格情報
• アプリケーションが呼び出しているサードパーティサービスのトークンやキー

環境変数として与えている値は、プロセス環境ごと読み取られる前提で棚卸ししておくと漏れが出にくくなります。CI/CD のシークレット管理やシークレットストアと二重管理になっている値は、両方を更新しないと古い値が復活する場合があります。

ローテーションに伴う影響

secret_key_base を変更すると、有効なセッションが失効し、利用者は再ログインが必要になります。暗号化 Cookie、署名付き Cookie、署名付き Global ID、Active Storage の URL も同様に影響を受けます。

サービスへの影響を伴う作業となるため、告知とメンテナンス計画をセットで検討することをおすすめします。 特に Active Storage の URL が無効になる点は、画像の署名付き URL を外部にキャッシュさせている構成や、メール本文に埋め込んで配信している場合に影響が出ます。

なお Advisory は、ローテーションを段階的に進める場合でも、それは中間的な措置にとどめ、漏えいした可能性のある値をフォールバックとして残さないよう求めています。旧鍵を併用可能にしたまま運用を続けると、対処の意味が薄れます。

公式フォレンジックツールキットによる調査

Rails チームは、2 つの問いに答えるための資料とツールを rails/rails-forensics-CVE-2026-66066 として公開しています。1 つは「自分たちは脆弱だったのか、どれくらいの期間そうだったのか」、もう 1 つは「悪用されたのか、悪用されたとして何が持ち出されたのか」です。

調査が容易でない理由も明示されています。証拠はオブジェクトストレージと Active Storage の 3 つのテーブルに分散しており、アプリケーションログは露出期間より先に期限切れになります。さらに、添付されていない blob を定期的に削除する運用は、答えを出すために必要なレコードそのものを消してしまいます。

調査を行う可能性があるなら、証跡の保全を先に済ませておく判断が現実的です。 定期削除ジョブの一時停止や、オブジェクトストレージのスナップショット取得を、パッチ適用と並行して検討しておくと選択肢を残せます。

ツールキットは 2 つのスキルで構成され、順番に実行する想定です。1 つ目が露出期間を算出し、2 つ目がその期間を前提に Active Storage のデータを走査します。1 つ目の成果物は「はい / いいえ」ではなく期間である、と説明されています。すでにパッチを適用した組織にとって、現在形の答えは「いいえ」であり、有用なのは調査が対象とすべき範囲だからです。

対象範囲にも注意が必要です。カバーされるのは :vips を使用する Active Storage で、バリアントのレコードが記録されている場合に限られます。アプリケーションが利用者のファイルを libvips に渡している他の箇所、たとえば独自のアップロード処理やオブジェクトストレージへの直接クライアント、独自実装のアバター機能などは、それぞれ別に確認する必要があります。

また、このツールで痕跡が見つからなかった場合、それは有力な根拠ではあるものの証明ではない、とリポジトリ自身が繰り返し明示しています。調査結果を扱う際は、「脆弱な状態だった」「細工されたファイルの痕跡があった」「特定のファイルが読み取られた」「資格情報が実際に使用された」を別々の事実として整理し、ひとまとめに「侵害された」と結論づけない進め方が適切です。

まとめ

CVE-2026-66066 は、Active Storage が libvips に画像処理を委ねる際の初期設定に起因する任意ファイル読み取りの脆弱性です。認証を必要とせず、読み取られた秘密情報を起点にリモートコード実行や他システムへの横展開に発展する可能性があります。修正版の適用に加えて、秘密情報のローテーションと侵害有無の確認までを一連の対応として計画することが求められます。

• Active Storage の libvips 利用構成に影響する CVSS v4 9.5 の脆弱性
• 影響条件は vips 構成と信頼できない利用者からの画像アップロードの 2 点
• 修正版は activestorage 7.2.3.2、8.0.5.1、8.1.3.1 の 3 系列
• 修正版の適用には libvips 8.13 以降と ruby-vips 2.2.1 以降が前提
• 要件を満たさない環境ではアプリケーションが起動時に例外を送出
• 影響を受けた可能性がある環境では secret_key_base 等の再発行を推奨
• 公式のフォレンジックツールキットで露出期間と痕跡の確認が可能

以上、最後までお読みいただきありがとうございました。