Rails界隈で「KindaRails2Shell」と呼ばれているCVE-2026-66066は、Active Storageの画像バリアント処理にある脆弱性だ。7月29日にRailsのセキュリティアドバイザリが出た時点でCVSS 4.0スコア9.5、未認証の任意ファイル読み取りからRCEに至りうるという評価で、8月末から実際の攻撃が急増している。
どこで壊れるのか
影響を受けるのは「Active Storageの画像処理にlibvipsを使っていて」「信頼できないユーザーからの画像アップロードを受け付けている」アプリだ。攻撃の起点は、Active Storageとlibvipsが入力ファイルを読む方法の食い違いにある。Active Storage側が安全だと判断したファイル参照を、libvips側が別物として解釈することで、本来アクセスできないパスのファイルを読み出せてしまう。
読めるのはRailsプロセスの権限で到達できるファイル全般。ここに config/master.key や環境変数経由の secret_key_base、データベースのパスワード、S3/GCSの認証情報、各種APIトークンが含まれると、話は「情報漏えい」で終わらない。secret_key_base を握られると、Railsが署名・暗号化しているクッキーやメッセージverifierを攻撃者が自由に偽造できるようになり、そこからデシリアライズを経由したコード実行に繋がる。CWEの分類は「安全でないデフォルトによるリソースの初期化」(CWE-1188)で、開発者が特別に危険な設定をしていなくても踏みうるのが厄介な点だ。
パッチを当てただけでは終わらない
このCVEで実務上いちばん重要なのは、修正の適用範囲だ。
- gemだけ上げても不十分: 修正版のActive Storage(7.2.3.2 / 8.0.5.1 / 8.1.3.1)に加えて、システム側のlibvipsを8.13以降にする必要がある。古いlibvipsが残っていると、Rails側の修正だけでは読み取り経路が塞がらない。コンテナイメージやCIのベースイメージにlibvipsがどのバージョンで入っているかを確認すること。
- パッチ済みサーバーにも残る経路: 検証を行った研究者は、8.1.3.1を適用したサーバーでも「libvipsのファイル読み取りはブロックされるが、variation-key のMarshalデシリアライズは無害化されていない。有効な署名があれば、パッチ済みサーバー上でもRCEガジェットが動く」と報告している。つまり、先に
secret_key_baseが漏れていた場合、アップグレード後も署名付きリクエストを作られてコード実行される余地が残る。
この2点目が意味するのは、7月末〜8月にこの脆弱性で環境変数やキーを抜かれた可能性があるなら、パッチと同時にシークレットのローテーションが必須ということだ。secret_key_base、master.key、DB認証情報、クラウドのアクセスキーを回し、既存の署名付きクッキー・トークンを失効させる。これを飛ばすと「直したのに入られ続ける」という、CitrixBleedやその他のセッション残存系インシデントと同じ轍を踏む。
攻撃はすでに動いている
VulnCheckの観測では、8月上旬時点で7,100件超の脆弱なRailsインスタンスがインターネットに露出していた。8月30日には数時間で50件超の悪用検知があり、その後360件規模まで増加。シンガポール・イスラエル・英国に置かれたおとりシステムが標的にされ、C2は特定のホストに向かっていたと報告されている。7月末の disclosure から実悪用の本格化まで約1か月、というタイムラインだ。
RailsのようなフルスタックフレームワークでActive Storageの画像処理は「アバターアップロード」程度の何気ない機能として広く使われているだけに、対象は多い。まず Gemfile.lock のActive Storageバージョンとデプロイ環境のlibvipsバージョンを突き合わせ、該当すればパッチとシークレットローテーションをセットで実施するのが先決だ。技術的な内訳はRapid7の解析(https://www.rapid7.com/blog/post/etr-kindarails2shell-cve-2026-66066-critical-arbitrary-file-read-and-possible-remote-code-execution-in-ruby-on-rails/)と、7月29日のRailsアドバイザリにまとまっている。