2026年7月29日、Ruby on RailsのActive Storageバリアント処理に認証不要でリモートからの任意コード実行(RCE)につながり得る脆弱性「CVE-2026-66066」が公表されました。通称「KindaRails2Shell」と呼ばれるこの脆弱性は、GMO Flatt SecurityのRyotaK氏とEthiackのチームによって独立に発見され、同日修正バージョンのRails 7.2.3.2、8.0.5.1、8.1.3.1が公開されています。特に深刻なのは、Rails 7.0以降を一般的な構成で使用している環境が対象となる点です。発見チームは「概念実証コード(PoC)は現時点で非公開だが、AIを利用することで数時間以内に作成される可能性が高い」と警告しており、影響を受ける環境では直ちにアップデートを実施することが強く求められています。
KindaRails2Shell(CVE-2026-66066)Rails RCE脆弱性のサマリー
- 脆弱性名:KindaRails2Shell(CVE-2026-66066)
- 深刻度:緊急(Critical)
- 影響コンポーネント:Ruby on Rails の Active Storage バリアント処理
- 認証不要でリモートから任意ファイルの読み取りが可能。さらにRCEへの発展が確認されている
- Rails 7.0〜7.2.3.1・8.0.0〜8.0.5・8.1.0〜8.1.3は一般的な構成で影響を受ける
- 修正バージョン:Rails 7.2.3.2、8.0.5.1、8.1.3.1(2026年7月29日公開)
- PoCは現時点で非公開。ただし「AIを利用することで数時間以内に作成される可能性が高い」と発見者が明記
- WAFによる緩和は限定的。アップデートの代替にはならない
- 発見者:GMO Flatt Security・RyotaK氏、Ethiack(André Baptista氏・Bruno Mendes氏・Castilho氏)が独立に発見・報告
整理表
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-66066 |
| 通称 | KindaRails2Shell |
| 深刻度 | 緊急(Critical) |
| 影響コンポーネント | Active Storage(バリアント処理) |
| 脆弱性の種別 | 任意ファイル読み取り→リモートコード実行(RCE) |
| 認証の要否 | 不要(認証なしで攻撃可能) |
| 修正バージョン | Rails 7.2.3.2 / 8.0.5.1 / 8.1.3.1 |
| 公開日 | 2026年7月29日 |
| PoC公開状況 | 現時点で非公開(数時間以内に作成可能と発見者が警告) |
| GitHub Advisory | GHSA-xr9x-r78c-5hrm |
| 発見者 | GMO Flatt Security・RyotaK氏 / Ethiack(3名)が独立に発見 |
Active StorageのバリアントAPI処理に潜んでいた脆弱性
Ruby on Railsは国内外のウェブサービスで広く採用されているWebアプリケーションフレームワークです。Active StorageはRailsが提供するファイルアップロード・管理機能で、画像のリサイズや変換(バリアント処理)を担っています。
CVE-2026-66066は、このActive Storageのバリアント処理において、攻撃者が細工したファイルまたはパラメータを送り込むことで、サーバー上の任意のファイルを読み取れる脆弱性です。GMO Flatt Securityによると、Railsの特性上、任意のファイルを読み取れる状態になると複数の手法によって任意コード実行(RCE)に発展することが確認されています。
ネットワークエンジニア・サーバーサイドエンジニアとしての経験から言えば、「任意ファイルの読み取り」と「RCE」の間には一見大きな差があるように見えますが、Railsアプリケーションにおいてはsecret_key_baseなどのシークレット情報や認証情報がファイルとして存在することが多く、それらが読み取られると認証の偽造や追加の攻撃への足がかりになりやすい構造があります。今回の脆弱性はその点を考慮してRCEへの到達が確認されており、単なる情報漏洩にとどまらない深刻度として評価されています。
影響を受ける構成——Rails 7.x・8.xのデフォルト設定が対象
今回の脆弱性が特に警戒が必要な理由は、Rails 7.0以降を標準的な方法でセットアップした環境がほぼすべて対象となる点です。GMO Flatt Securityの解説によれば、影響を受けるためには以下の3つの条件が重なる必要があります。
一つ目はActive Storageを使用しており、ファイルのアップロードを許可していることです。Active Storageを有効にした場合、明示的に無効化しない限りデフォルトでアップロードが許可されます。二つ目はActive Storageが画像処理にlibvipsを使用するように構成されていることです。これはRails 7.0以降のデフォルト設定であり、多くのRails 7・8アプリケーションが該当します。三つ目は環境内のlibvipsが特定のファイル形式を処理できる状態にあることです。DebianやUbuntuを使用した環境、およびrails newコマンドで生成されるDockerfileを使用した環境はデフォルトでこの条件を満たします。
つまり、「rails newして本番運用を開始した」だけの環境が対象になりえます。影響を受けるバージョンと推奨修正バージョンは次のとおりです。
| Railsのバージョン | 影響 | 主な構成条件 | 推奨修正バージョン |
|---|---|---|---|
| 6.0.0未満 | 対象外 | — | — |
| 6.0.0〜6.1.7.10 | 影響あり(条件付き) | Active Storageで非標準の設定が必要 | 7.2.3.2 |
| 7.0.0〜7.2.3.1 | 影響あり | Active Storageが有効であること | 7.2.3.2 |
| 8.0.0〜8.0.5 | 影響あり | Active Storageが有効であること | 8.0.5.1 |
| 8.1.0〜8.1.3 | 影響あり | Active Storageが有効であること | 8.1.3.1 |
PoCは非公開でも「AIで数時間以内に作成可能」——緊急対応が求められる理由
GMO Flatt Securityは今回の記事公開時点でPoCコードを公開していません。攻撃への悪用を少しでも遅らせるための判断です。しかし同時に「事前検証では、AIなどを利用することで数時間以内にPoCが作成される可能性が高いと判断している」と明記しています。
この警告が示すのは、PoCが非公開であることが防御に与える猶予期間は限定的だという事実です。技術情報と公開されたアドバイザリ(GHSA-xr9x-r78c-5hrm)を読み込めば、AIアシスタントを使って攻撃手順を再構築する可能性は高くなっています。
同月に公開されたWordPressの緊急脆弱性「wp2shell」(CVE-2026-52540)でも同様の状況が発生しており、PoCが公開前から野生での悪用が報告されたケースがあります。「PoCが公開されていないから安全」という判断は、この種の緊急脆弱性においては成り立ちません。
根本的対策——修正バージョンへの即時アップデート
GMO Flatt Securityは「構成にかかわらず、影響を受けるバージョンを利用している場合は原則として修正版へ速やかにアップデートすることを強く推奨する」と述べています。これは珍しく明確な表現であり、対応の緊急性を反映しています。
修正バージョンはRails 7.2.3.2、8.0.5.1、8.1.3.1で、いずれも2026年7月29日にリリースされています。Gemfileを更新してbundle update railsを実行し、アプリケーションのテストを経て本番環境に適用することが推奨手順となります。
なお、Rails 6.x系については修正バージョンとして7.2.3.2が案内されており、メジャーバージョンアップが必要になる場合があります。Rails 6はすでにメンテナンスフェーズを過ぎており、セキュリティパッチの提供が終了しているバージョンが含まれることから、今回の事案をきっかけにアップグレード計画を前倒しにすることを検討すべきです。
パッチ適用前の暫定緩和策
即時アップデートが困難な環境向けに、2つの暫定緩和策が示されています。
libvipsがバージョン8.13以降である場合、VIPS_BLOCK_UNTRUSTED環境変数を設定することで脆弱性の影響を回避できます。また、ruby-vipsがバージョン2.2.1以降であれば、RailsのinitializerにVips.block_untrusted(true)を追加することでも回避できます。
ただし、GMO Flatt SecurityはWAFによる緩和について「Active Storageの保存先やファイルのアップロード方式など、アプリケーションの構成に大きく依存する」として、「WAFによる緩和策を修正版へのアップデートの代替として使用しないでください」と明記しています。WAFの設定だけで対応済みとみなすことは、リスクの過小評価につながります。
情報システム部門が取るべき対応
自社または管轄する環境にRailsアプリケーションが存在する場合、以下の順序で対応してください。
まず、Rails 7.0〜7.2.3.1、8.0.0〜8.0.5、8.1.0〜8.1.3のいずれかのバージョンを使用しているアプリケーションを洗い出してください。特にActive Storageを使用し、かつファイルアップロード機能を提供しているアプリケーションは最優先の対応対象です。
次に、修正バージョン(7.2.3.2 / 8.0.5.1 / 8.1.3.1)への更新をステージング環境でテストしたうえで本番環境へ適用してください。PoCが公開されていない現在の短い猶予期間の間に対応を完了させることが重要です。
即時のアップデートが困難な場合は、libvipsおよびruby-vipsのバージョンを確認し、それぞれに応じた暫定緩和策(VIPS_BLOCK_UNTRUSTED環境変数またはVips.block_untrusted(true))を適用してください。
また、外部委託しているシステムやSaaSとして利用しているRailsベースのアプリケーションについては、ベンダーから対応状況の確認を取ることも推奨します。








