Rails重大脆弱性 CVE-2026-66066：認証不要でRCEにつながるActive Storage欠陥と即時対応手順

はじめに：なぜ今すぐ対応が必要なのか

2026年7月29日、Ruby on Railsに対して過去最高水準の危険度を持つ脆弱性が公開されました。CVE-2026-66066、通称「KindaRails2Shell」と呼ばれるこの脆弱性は、認証不要・リモートから任意コードを実行できるという、攻撃者にとって理想的な条件が揃っています。

CVSSv4スコアは 9.5（Critical） であり、ファイルアップロード機能を持つRailsアプリケーションであれば、インターネット上から誰でも攻撃を仕掛けられる可能性があります。

本脆弱性はGMO Flatt SecurityのRyotaK氏とEthiackの研究者が独立して発見・報告したもので、影響を受けるすべての開発者・運用担当者は本記事をもとに即時対応を行ってください。

CVE-2026-66066の概要

脆弱性の基本情報

非技術者向けのわかりやすい説明

この脆弱性を一言で説明するならば、「ファイルアップロード機能を悪用してサーバーを乗っ取ることができる欠陥」です。

攻撃者は特別なログイン情報やアカウントを必要とせず、アプリのファイルアップロード画面にアクセスできれば、以下のことが可能になります。

1. サーバー内の機密ファイル（パスワードやAPIキーなど）を盗み読む
2. 盗んだ情報を踏み台として、サーバー上で任意のプログラムを実行する

つまり、攻撃者はサーバーを完全に制御下に置けるということです。「ファイルアップロード機能があるRailsアプリ」は、このリスクにさらされていると考えてください。

影響を受けるRailsバージョン

バージョン別の影響範囲

Rails 7.0以降では Active Storage がデフォルトで有効化されているため、「意識して使っていない」アプリでも対象になる可能性があります。まずは自分のアプリのRailsバージョンを確認することが最初のステップです。

自分のアプリが対象かを確認する方法

Railsバージョンの確認：

# Gemfile.lockから確認
grep -E "^    rails \(" Gemfile.lock

# または
bundle exec rails --version

Active Storageの有効・無効の確認：

# config/application.rb または config/environments/*.rb に以下の記述があるか確認
# require "active_storage/engine"  → 有効（デフォルト）
# config.active_storage.service = ... → 有効

libvipsのバージョン確認：

vips --version
# 8.13以上であること

漏洩する可能性がある情報

攻撃が成功した場合、以下のような機密情報が外部に流出する恐れがあります。

• secret_key_base：セッションの偽造・改ざんに悪用される
• Railsマスターキー（config/master.key）：credentials.yml.enc の復号に使用される
• データベース接続情報（ホスト名、ユーザー名、パスワード）
• クラウドストレージ認証情報（AWS S3、GCP Storage、Azure Blob など）
• APIトークン・Webhookシークレット
• .env や credentials.yml.enc に含まれるあらゆるシークレット情報

RCE脆弱性の仕組み（技術的詳細）

攻撃チェーンのステップバイステップ解説

本脆弱性の根本原因は、Railsが画像処理に利用するlibvipsライブラリの「信頼されていない操作（Untrusted Operations）」がデフォルトで制限されていない点にあります。

攻撃チェーンは以下の5ステップで構成されます。

Step 1：細工した画像ファイルのアップロード 攻撃者はRailsのDirect Uploadエンドポイント（/rails/active_storage/direct_uploads）に対して、悪意を持って細工したファイルをアップロードします。このエンドポイントは多くのアプリケーションで認証なしに到達可能です。

Step 2：ファイル形式の偽装 アップロードされるファイルは外見上はMATLAB形式（.mat）を装っていますが、実態はHDF5コンテナ形式のデータです。libvipsはこのファイルをHDF5として処理を開始します。

Step 3：任意ファイルの読み取り HDF5形式には「External File List」という機能があり、外部ファイルを参照してそのバイト列をデータとして読み込めます。攻撃者はこの機能を悪用し、サーバー上の任意のパス（例：/app/config/master.key や /proc/1/environ）を指定します。

Step 4：情報漏洩 libvipsが読み取ったファイルの内容は、そのまま画像のピクセルデータとしてHTTPレスポンスに含まれます。攻撃者は返ってきた画像データからバイト列を逆算し、サーバー上の機密ファイルの内容を復元できます。

Step 5：RCEへの発展 secret_key_base を入手した攻撃者は、Railsのセッションクッキーを任意の内容に偽造できます。偽造されたクッキーには悪意あるRubyオブジェクトが埋め込まれており、Railsがデシリアライズした瞬間にサーバー上でコードが実行されます。

なぜデフォルト設定が危険なのか

libvipsは本来、信頼できるソースからの画像のみを処理する用途で設計されています。「信頼されていない操作」の制限はオプション機能として存在していましたが、デフォルトでは無効になっています。Railsはlibvipsを統合する際、この制限を有効化する処理を実装していませんでした。これが今回の脆弱性の本質的な原因です。

パッチ適用手順（推奨対応）

修正済みバージョンへのアップデート

修正済みバージョンは以下の通りです。

• Rails 7.2.3.2
• Rails 8.0.5.1
• Rails 8.1.3.1

アップデート手順：

# Gemfile のRailsバージョンを修正済みバージョンに更新
gem "rails", "~> 8.1.3", ">= 8.1.3.1"  # バージョンに合わせて変更

# バンドルの更新
bundle update rails

# Gemfile.lockで適用されたバージョンを確認
grep -E "^    rails \(" Gemfile.lock

# libvipsのバージョンも確認（8.13以上であること）
vips --version

アップデート後に必須の追加対応

パッチを適用するだけでは不十分です。すでに攻撃を受けていた場合に備えて、すべての認証情報を即時ローテーションすることが強く推奨されます。

secret_key_base の再生成：

# config/credentials.yml.enc の再生成
bin/rails credentials:edit
# secret_key_base を新しい値に書き換えて保存
# ※ 既存のすべてのセッションが無効化されます

credentials.yml.enc の再暗号化：

# 既存のcredentialsを再生成（既存のシークレットは削除される点に注意）
bin/rails credentials:edit --environment production

クラウドサービスの認証情報ローテーション：

• AWS IAMアクセスキーの再発行とローテーション
• GCP/Azureサービスアカウントキーの再生成
• S3バケットポリシーの見直し
• 各種APIトークン・Webhookシークレットの再発行

セッションの強制無効化： secret_key_base を更新することで既存の全セッションは無効化されますが、セッションをデータベースで管理している場合は該当テーブルをクリアすることも検討してください。

暫定回避策（パッチ適用が困難な場合）

本番環境への即時パッチ適用が難しい場合は、以下の暫定回避策を適用してください。

方法1：環境変数による設定（libvips 8.13以上）

export VIPS_BLOCK_UNTRUSTED=true

この環境変数はアプリケーションの起動前に設定する必要があります。Dockerを利用している場合はDockerfileやdocker-compose.ymlの環境変数セクションに追記してください。

# docker-compose.yml の例
environment:
  - VIPS_BLOCK_UNTRUSTED=true

方法2：Railsイニシャライザによる設定（ruby-vips 2.2.1以上）

# config/initializers/vips.rb
Vips.block_untrusted(true)

この方法を使用するには、ruby-vips gem のバージョンが 2.2.1以上である必要があります。

# ruby-vipsのバージョン確認
bundle exec ruby -e "require 'vips'; puts Vips::VERSION"

WAF・ネットワーク制御による緩和の限界

WAF（Webアプリケーションファイアウォール）でこの攻撃を防ごうと考える方もいるかもしれませんが、WAFによる防御は効果が極めて限定的です。

理由は明確です。攻撃に利用されるリクエストは通常のファイルアップロードリクエストと外形的に区別がつかず、パケットの内容だけから攻撃を識別することは現実的ではありません。

ネットワーク制御（Direct Uploadエンドポイントへのアクセス制限）については、認証済みユーザーのみにアクセスを絞ることで攻撃の難度を上げる効果はありますが、根本的な解決策にはなりません。暫定回避策はあくまで一時措置であり、速やかにパッチを適用することを強く推奨します。

組織としての対応チェックリスト

開発チーム向けアクション

• Gemfile.lock でRailsバージョンを確認する
• Active Storageの有効・無効を確認する
• 修正済みバージョン（7.2.3.2 / 8.0.5.1 / 8.1.3.1）へアップデートする
• libvipsのバージョンが8.13以上であることを確認する
• secret_key_base を再生成する
• credentials.yml.enc を再暗号化する
• 各種APIトークン・クラウド認証情報をローテーションする
• Active Storage関連機能の回帰テストを実施する

運用・インフラチーム向けアクション

• 本番・ステージング・開発環境のRailsバージョンを棚卸しする
• パッチ展開までの間、暫定回避策（VIPS_BLOCK_UNTRUSTED=true）を環境変数に設定する
• 不審なファイルアップロードログ（Direct Uploadエンドポイントへのアクセス）を調査する
• 侵害の痕跡（IoC）を調査し、異常なプロセス起動や外部通信がないか確認する
• クラウドサービスのアクセスログに不審な操作がないか確認する

まとめ：対応優先度とタイムライン

CVE-2026-66066は、Railsの歴史においても最高レベルの危険度を持つ脆弱性です。認証不要・リモート実行可能という特性上、攻撃のハードルが非常に低く、放置するリスクは計り知れません。

優先度別の対応タイムライン

今日中に実施すること：

• Railsバージョンの確認
• VIPS_BLOCK_UNTRUSTED=true 暫定回避策の適用
• シークレットキーのローテーション着手

今週中に完了すること：

• 修正済みバージョン（7.2.3.2 / 8.0.5.1 / 8.1.3.1）へのアップデート
• 全シークレット・認証情報のローテーション完了
• 侵害調査（ログレビュー）の実施

来月（8月28日）以降：

• PoCコードが公開予定のため、攻撃の難易度が大幅に下がる可能性がある
• パッチ未適用のアプリは攻撃リスクが一段と高まるため、それまでに対応を完了させること
• 本番環境の侵害調査を再度実施し、証跡がないことを確認する

技術的に正確な表現を心がけると、今回の脆弱性は「既知の欠陥が既知の手順で組み合わさった結果」であり、パッチさえ適用すれば確実に防げるものです。実際の開発現場では、セキュリティアップデートの適用を後回しにしてしまいがちですが、本件はその例外です。ベストプラクティスとして、即日対応を原則にしていただくことを強くお勧めします。

参考リソース

• GMO Flatt Security: KindaRails2Shell 詳細解説
• Rails公式リリースノート（7.2.3.2 / 8.0.5.1 / 8.1.3.1）
• Rapid7: KindaRails2Shell 技術解説
• Ethiack: KindaRails2Shell 研究
• HeroDevs: CVE-2026-66066 解説