nexsight cyber intelligence / signal online wire desk · issue 380
NEXSIGHT CYBER WIRE Cybersecurity News & Intelligence
MONITOR / DECODE / DEFEND 脅威を、意思決定につなげる
注目

脆弱性 / VULNERABILITIES / RAILS / RCE

Railsの重大なRCE脆弱性「KindaRails2Shell」 — Active Storageのvips処理で任意ファイル読み取りから認証情報窃取・RCEへ

Ruby on Railsは2026年8月、Active Storageが画像変換にlibvipsを用いるデフォルト構成で、細工した画像のアップロードを起点にサーバ上の任意ファイルを読み取られ、環境変数や認証情報の窃取からRCEに至る脆弱性CVE-2026-66066（KindaRails2Shell）を公表した。Rails 7.0以降と8.xのデフォルト構成が影響し、修正版は7.2.3.2／8.0.5.1／8.1.3.1。libvips 8.13未満では別途更新が必要だ。

脆弱性 NEXSIGHT CYBER WIRE 編集部 6–7 min read
攻撃手法
ソフトウェア

Ruby on Railsプロジェクトは2026年8月、画像処理に libvipsを用いるActive Storageのデフォルト構成で、未認証の攻撃者がサーバ上の任意のファイルを読み取り、環境変数や認証情報を窃取してリモートコード実行（RCE）に至る脆弱性 **CVE-2026-66066（通称 KindaRails2Shell）**を公表した。修正版は activestorage 7.2.3.2、8.0.5.1、8.1.3.1で、libvips自体も 8.13以上への更新が必要だ。Railsと報告者のEthiack、GMO Flatt Securityは、パッチ適用後も窃取済みの認証情報が悪用され得るとして、全てのシークレットの変更を呼びかけている。

何が起きたか — デフォルト構成のActive Storageが標的

脆弱性は、Railsのファイル添付・画像変換フレームワーク Active Storage が、画像のバリアント（サムネイル等の派生画像）生成に libvips を用いる場合に生じる。libvipsは画像フォーマットごとに「ローダー／セーバー（operation）」を備えるが、その一部は信頼できない入力には安全でない「unfuzzed」な操作として区分されている。Active Storageは従来、これらのunfuzzedな操作を無効化していなかったため、攻撃者が細工した画像をアップロードし、バリアント生成を誘発することで、本来はウェブ画像とは無関係なフォーマットの処理を呼び出せた。

Railsのアドバイザリ（GHSA-xr9x-r78c-5hrm）によると、デフォルト構成で画像のバリアントを表示するアプリケーションは、未認証の攻撃者による任意ファイル読み取りを許す可能性がある。読み取られる対象には、アプリケーションプロセスの環境変数が含まれ、そこにはクラウドストレージや外部サービスの認証情報が格納されていることが多い。これらの窃取は、**RCEや外部システムへの横展開（lateral movement）**につながり得る。

報告はEthiackのAndré Baptista氏、Rafael Castilho氏、s3np41k1r1t0氏と、GMO Flatt SecurityのRyotaK氏がそれぞれ独立に発見し、Railsプロジェクトと連携して修正と開示が調整された。CVSSは 9.5（Critical）、攻撃ベクトルはネットワーク、特権不要、ユーザ操作不要と評価されている。

影響を受ける条件 — 7.0以降はデフォルトで影響

影響を受けるのは、次の全てを満たすアプリケーションだ。

  • Active Storageの画像処理にvipsを利用している（config.active_storage.variant_processor = :vips）。load_defaults 7.0 以降ではこれがデフォルトで設定される
  • 信頼できないユーザーからの画像アップロードを許可している（アバター、サムネイル、プロフィール画像など、アップロード後に処理結果を返す機能全般が該当し得る）
  • libvipsが特定のサードパーティライブラリとリンクされたビルドである

バージョン面では、Railsプロジェクトは影響範囲を次のように示している。

  • activestorage < 7.2.3.2
  • activestorage >= 8.0, < 8.0.5.1
  • activestorage >= 8.1, < 8.1.3.1

Rails 6.0.0〜6.1.7.10は、Active Storageをデフォルト以外にカスタマイズして利用している場合のみ影響し、通常の6.xインストールは本脆弱性の影響を受けない。一方、Rails 7.0.0〜7.2.3.1、8.0.0〜8.1.3はデフォルト構成で影響する。画像処理に **MiniMagick（ImageMagick）**を用いるアプリケーションは、本経路の影響を受けない。

Ethiackの解説（KindaRails2Shell）も「Active Storage＋デフォルトのvipsプロセッサは必要条件だが、それだけでは不十分で、信頼できない画像のアップロードを許可している場合に露呈する」と説明している。

修正内容 — Railsとlibvipsの両方の更新が必須

Railsプロジェクトが示した修正は、Railsとlibvipsの両方を更新することだ。

  • Rails（activestorage）を修正版へ更新する。修正版は 7.2.3.2、8.0.5.1、8.1.3.1以降だ。通常のGem更新の配布場所で入手できる。
  • libvipsを8.13以上へ更新する。8.13より前のlibvipsはunfuzzedな操作をそもそも無効化できず、その環境ではActive Storageが起動時に例外を送出する。Railsだけを更新しても、libvipsが古いままでは保護されない。

Ethiackも「Railsのパッチだけでは不十分で、libvipsが8.13未満なら別途更新が必要だ」と注意を促している。

直ちにできない場合の緩和策 — WAFは万能ではない

すぐに更新できない場合の暫定策として、Railsプロジェクトは次の方法を示している。ただし、いずれも恒久的な修正ではない。

  • libvips 8.13以上がシステムに存在する場合、環境変数 VIPS_BLOCK_UNTRUSTED を設定することで、unfuzzedな操作をブロックできる。Railsプロジェクトは「libvipsが初期化時にこの変数を読み取る」と説明している。
  • ruby-vips 2.2.1以上を利用しているアプリケーションは、代わりにイニシャライザで Vips.block_untrusted(true) を呼び出すことでも同等の保護が得られる。
  • libvips < 8.13 の環境では、有効な回避策は ruby-vipsへの依存自体を除去すること以外にない。画像解析のみにlibvipsを用いていた場合は ruby-vips をGemfileから除去することでlibvips自体を除外できる。Active Storage自体を使っていないアプリケーションも同様に除去で起動時チェックを回避できる。

Railsプロジェクトは、WAF（Web Application Firewall）について「特定の構成では時間を稼げるかもしれないが、Active Storageの保存先やアップロード経路によって有効性が大きく異なり、修正の代替にはならない」と明記している。Ethiackも「WAFは万能の修正ではない」と同様の見解を示している。

露呈した認証情報は全て変更を — セッションも無効化

最も重要なのは、更新だけでは既に窃取された認証情報を無効化できない点だ。Railsプロジェクトは、影響を受けたアプリケーションは「アプリケーションプロセスから読み取り可能な全てのシークレットが露呈した可能性があるとみなし、変更すべきだ」と呼びかけている。具体的には次のものが含まれる。

  • secret_key_base（config/credentials.yml.enc を復号するマスターキー config/master.key または RAILS_MASTER_KEY を含む）
  • Active Storageの保存先の認証情報（S3、GCS、Azureのキーなど）
  • データベースの認証情報
  • 外部サービス連携のトークンやキー

secret_key_base を変更すると、既存のセッションは全て期限切れとなりユーザーは再ログインが必要になる。暗号化されたCookie、署名付きCookie、署名付きGlobal ID、Active StorageのURLも影響を受ける。Railsプロジェクトは、旧シークレットをフォールバックとして保持し続けないよう求めている。

技術詳細の扱い — パッチ普及を優先

RailsプロジェクトとEthiackは、具体的な攻撃チェーンの技術詳細やPoCを現時点では公開していない。Railsプロジェクトは「管理者の更新判断に資さない一方で、未更新のアプリケーションへの攻撃を著しく容易にするため」と理由を説明し、詳細は遅くとも2026年8月28日までにRails Security Announcementsフォーラムで開示するとしている。Ethiackも「AIツールを持つ攻撃者がパッチの差分から再構成できるため、更新を待たずに適用すべきだ」と呼びかけている。

出典

この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。