RailsのKindaRails2Shellが悪用開始、更新だけでは鍵が残る

Ruby on RailsのActive Storageにある脆弱性「KindaRails2Shell」（CVE-2026-66066）について、攻撃者による悪用が始まったとの報告が2026年8月31日に出た。SecurityWeekの報道 は、VulnCheckが前週から攻撃を観測し、7月29日の修正版公開から約1カ月で標的化が進んだと伝えている。

ただし同日に確認されたのは、カナリアやハニーポットに届いた探索・攻撃トラフィックであり、大規模な侵害キャンペーンや被害件数ではない。Cyberpressoの観測整理 でも、VulnCheckによる初期のプロービング報告で、同日時点ではCISAのKnown Exploited Vulnerabilities（KEV）カタログに未掲載だと区別している。自社環境では、該当するActive Storage、libvipsの利用、信頼できない利用者からの画像受付という条件を確認し、対象なら更新、侵害調査、秘密情報の失効を一体で進める必要がある。

「悪用開始」が示すのは初期の攻撃活動

今回の変化は、公開済みの攻撃手法がインターネット上のRails環境に向けられ始めたことにある。ただし、カナリアやハニーポットでの検知は、実在する組織からファイルや鍵が盗まれたことを直接示すものではない。「悪用開始」は警戒水準を引き上げる根拠だが、侵害規模まで確定したという意味ではない。

一方で、修正版は観測より約1カ月前から提供され、技術情報や実証コードもすでに公開されている。攻撃者が対象を探索できる段階に入った以上、外部公開されたアップロード機能を持つ運用者は、単にRailsを使用しているかではなく、実際の画像処理構成と稼働バージョンで影響を判定する必要がある。

対象は三つの条件の組み合わせで決まる

Rails公式アドバイザリ は、影響する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としている。これらの版に加え、Active Storageの画像処理にlibvipsを使い、信頼できない利用者から画像を受け付けることが攻撃成立の条件になる。

VipsはRails 7.0のデフォルト設定を読み込むアプリでActive Storageのvariant processorに設定されるため、開発者が明示的に選択した記憶がなくても確認が要る。反対に、ImageMagick系のprocessorを使う環境や、信頼できない画像を一切受け取らない構成は、今回報告された経路の条件から外れる。

画像バリアントをアプリのコードから明示的に生成していないことだけでは除外できない。確認時はGemfile.lockだけで判断せず、稼働中のWebプロセス、ジョブワーカー、コンテナに読み込まれているactivestorage、ruby-vips、libvipsの実バージョンと、実際のvariant processorを照合する。会員限定の投稿機能でも、利用者を完全には信頼できないサービスなら「信頼できない画像の受付」に含めて評価すべきである。

入口はファイル読み取り、RCEには後段の条件がある

この問題を「画像を送るだけで直ちにシェルを奪われる」と説明するのは正確ではない。入口となるのは、細工したファイルをActive Storageとlibvipsに処理させ、Railsプロセスがアクセスできる任意のファイルやプロセス環境を読み取る攻撃である。Active Storageが危険なlibvips操作を無効化していなかったため、信頼できない入力から通常のWeb画像以外を扱うloaderへ到達できた。

読み取り対象にsecret_key_base、RAILS_MASTER_KEY、データベース認証情報、S3・GCS・Azureなどのストレージ資格情報、外部APIトークンが含まれていれば、影響はRailsサーバー内にとどまらない。盗まれた署名材料によるデータの偽造、セッションへの影響、接続先への横展開が可能になり、追加条件がそろえばRailsプロセスの権限でのリモートコード実行へ進み得る。

したがって、RCEは任意ファイル読み取りの自動的な同義語ではなく、秘密情報を取得した後のエスカレーションである。この区別は優先度を下げるためではない。入口を閉じる更新と、入口が開いていた間に持ち出された可能性のある鍵を無効化する作業が別であることを示している。

更新、調査、鍵交換を一つの対応にする

対象環境では、activestorageを修正版へ移行し、libvipsを8.13以上にする。libvips 8.13未満は安全でない操作を遮断できないため、Active Storageだけを更新して依存ライブラリを据え置く対応は不十分である。直ちにRailsを更新できずlibvips 8.13以上を使用している場合は、VIPS_BLOCK_UNTRUSTEDの設定が一時的な緩和策になる。ruby-vips 2.2.1以上なら、initializerからVips.block_untrusted(true)を呼ぶ方法もある。

脆弱な構成で信頼できない画像を受け付けた期間がある場合は、次の作業をインシデント対応としてまとめて行う。

1. Webプロセス、ジョブワーカー、管理系サービス、古いコンテナを含め、Active Storageとlibvipsの構成および実バージョンを確定する。
2. 修正版Active Storageとlibvips 8.13以上を展開し、ロールバック先や停止中のイメージにも脆弱な構成を残さない。
3. アップロード記録、blobとattachmentのデータ、画像変換要求、アプリケーションログ、オブジェクトストレージやCDNのアクセス履歴を保全する。
4. secret_key_base、Railsのmaster key、復号されるcredentials内の値を更新し、古い秘密情報をfallbackとして残さない。
5. データベース、クラウドストレージ、外部API、メッセージキューなど、Railsプロセスから参照できた資格情報を棚卸しして失効・再発行する。
6. 新しい資格情報をWeb、ワーカー、CI/CD、バッチ、監視、バックアップへ展開し、旧鍵によるアクセスが拒否されることを確認する。

secret_key_baseを交換すると、既存セッションの失効により再ログインが必要になり、暗号化Cookie、署名Cookie、signed global ID、Active Storage URLにも影響する。それでも旧値を互換性維持のため残せば、すでに取得した攻撃者にも有効な鍵を残すことになる。タイトルの「更新だけでは鍵が残る」とは、このパッチ後も持ち出された秘密情報の効力が自動では消えない点を指す。

被害の有無はパッチ適用日だけでは分からない

更新日時が示すのは、新たなファイル読み取りの入口を閉じた時点であって、それ以前に読み取りが成功したかどうかではない。調査では、通常と異なるファイル形式やcontent type、直接アップロードの作成、短時間に繰り返されたrepresentation要求、画像変換エラー、不審な送信元を時系列で照合する。アプリケーションログが失われていても、ロードバランサー、WAF、CDN、オブジェクトストレージ、Active Storageのデータベース記録が補助資料になり得る。

8月31日付の公表情報から確認できるのは、探索・初期悪用活動の報告と、任意ファイル読み取りから秘密情報の窃取、横展開、RCEへ進み得る技術的経路までである。被害組織数、侵害の成功件数、攻撃者の全体像は明らかになっていない。対象条件を満たしていた環境では、修正版が稼働していることに加え、露出し得た秘密情報が失効し、過去の痕跡を調査できていることが安全確認の基準になる。