最終更新：10 月 24 日 02:09（日本時間）
続報が出たら追記します。
すぐ見る：よくある疑問 ／ サービスを持つ会社がやること ／ 影響を受ける版と条件 ／ すぐ更新できないとき ／ 更新のあとにやること ／ 経緯
ひとことで言うと
Rails で作ったサービスの画像アップロードの機能に、外から乗っ取られるおそれのある弱点。修正版が出ている（7 月 29 日公表）
- Web サービスを作る仕組み「Ruby on Rails」の、画像などのアップロードを扱う機能に、弱点（脆弱性）が見つかった。細工した画像を上げられると、サーバーの中の鍵などを読まれ、外から操られるおそれがある
- 攻撃に使うコードは、すでに出回っている。弱点をふさいだ版（修正版）は 7.2.3.2・8.0.5.1・8.1.3.1
- 更新しても、すでに盗まれた鍵やパスワードは元に戻らない。対象だったなら、鍵やパスワードを変え、入り込まれていないかを調べる
どうすればいい？
よくある疑問と答え
-
自社のサービスは対象？
Rails で作られていて、画像の処理に libvips を使い、外の人からの画像のアップロードを受け付けているものが対象です。この弱点は Rails の部品 activestorage のものです。
→ 影響を受ける版と条件 -
Rails を使っているか分からない
サービスを作った会社や、保守をしている会社に聞くのが早道です（この記事での整理）。聞くことの例を下に載せています。
→ サービスを持つ会社がやること - アップロードの画面が無ければ大丈夫？ そうとは限りません。Active Storage の direct upload という機能は標準で有効で、画面が無いアプリでも対象になるおそれがあると、JPCERT/CC は注意しています。
-
すぐに更新できないときは？
libvips が 8.13 以上なら、設定で弱点の入り口を止める方法があります。WAF だけでは代わりにならないと指摘されています。
→ すぐ更新できないとき -
更新すれば終わり？
終わりではありません。対象だった期間があるなら、アプリから読める鍵やパスワードをすべて漏れたものとして変え、入り込まれていないかを調べます。
→ 更新のあとにやること
詳しくは：影響を受ける版と条件 ／ すぐ更新できないとき ／ 更新のあとにやること
この記事では、Ruby on Rails の Active Storage の脆弱性（通称 KindaRails2Shell）について、国内のセキュリティ事故への対応を調整する JPCERT コーディネーションセンター（JPCERT/CC）の注意喚起と、Rails の公式のセキュリティアドバイザリ・お知らせの発表だけをもとに、何を確かめ、どう対処すればよいかを整理します。攻撃の手順の細かい情報は載せていません。
何が見つかったか
まず、Ruby on Rails と Active Storage がどんなものかです。Ruby on Rails（Rails）は、データベースを使う Web アプリを作るための、Ruby という言語の開発の枠組み（フレームワーク）です。会員サイトや予約の仕組み、社内ツールなどに使われています。
Active Storage はその中の機能の 1 つです。利用者が上げた画像などのファイルを、Amazon S3 のようなクラウドの保存先に置いて、アプリのデータとひもづけます。
今回の弱点は、この Active Storage が画像を加工するところにありました。細工したファイルを上げられると、サーバーの中のファイルを読まれるおそれがあります。読まれるものには、アプリの大事な鍵や、ほかのシステムに入るためのパスワードも含まれます。そこから、外からサーバーを操られたり、ほかのシステムに入り込まれたりするおそれがあります。
Rails で作ったサービスを持つ会社がやること
自社では開発をせず、制作会社や開発会社にサービスを作ってもらった会社に向けた整理です。作った会社に、次のことを順に頼みます。
- 自社の Web サービスや社内ツールが Ruby on Rails で作られているか、Active Storage と libvips を使っているかを確かめてもらう
- 対象なら、activestorage を修正版（7.2.3.2・8.0.5.1・8.1.3.1）に更新してもらう。libvips が 8.13 未満、ruby-vips が 2.2.1 未満だと、更新後にアプリが起動しないので、先にこちらを上げる
- 対象だった期間があるなら、secret_key_base・データベースのパスワード・外部サービスの鍵など、アプリから読める鍵やパスワードをすべて変えてもらう
- Rails が公開した調査用のツールと手引きで、攻撃を受けていないかを調べてもらう
鍵を変えると、お客さまはいったんログアウトされ、もう一度ログインが必要になります。お客さまが使うサービスなら、変える前に案内を出しておくと混乱を減らせます（この記事での整理）。
経緯
| 日付 | できごと |
|---|---|
| 2026 年 9 月 24 日 | Rails 7.2.4 を公開。7.2 系の最後のリリースで、今後のセキュリティの修正は 8.0 系と 8.1 系だけと案内 |
| 8 月 3 日 | JPCERT/CC が注意喚起を更新。調査用のツールと手引きを紹介し、対象の説明を直した |
| 7 月 31 日 | Rails が、攻撃の詳細と調査用のツール・手引きを公開（攻撃を試すコードが出回ったため、予定より早めた） |
| 7 月 30 日 | JPCERT/CC が注意喚起を公開 |
| 7 月 29 日（現地時間） | Rails がセキュリティアドバイザリと修正版（7.2.3.2・8.0.5.1・8.1.3.1）を公開し、できるだけ早い更新を強く勧めた |
技術的な詳細（開発・運用の担当者向け）
ここからは、Rails のアプリを開発・運用しているエンジニア向けです。最初に、脆弱性の中身を、JPCERT/CC と Rails の発表の言葉に沿って並べます。
| 観点 | 発表の内容 |
|---|---|
| 識別子 | CVE-2026-66066（通称 KindaRails2Shell）。Rails のアドバイザリ GHSA-xr9x-r78c-5hrm、JPCERT/CC の注意喚起 JPCERT-AT-2026-0021 |
| 深刻度 | Critical（CVSS v4 の基本値 9.5） |
| 影響 | 認証されていない攻撃者が、サーバー上の任意のファイル（プロセスの環境変数を含む）を読み取れる。環境変数には secret_key_base や外部システムの認証情報が入っていることが多く、リモートコード実行や他システムへの侵入につながる |
| 原因 | Active Storage の variant の処理で使う libvips には、未信頼のコンテンツには安全でない（unfuzzed）と分類されたファイルローダーがある。Active Storage がこれを無効にしていなかった |
| 悪用の状況 | JPCERT/CC はエクスプロイトコードの公開を確認し、今後、悪用する攻撃が広く行われる可能性があるとしている。複数の研究者が攻撃を解析して PoC を公開した |
影響を受ける版と、対象になる条件
JPCERT/CC と Rails の発表です。Rails の部品の 1 つ activestorage の、次の版が影響を受けます。
| 系列 | 影響を受ける版 → 修正版 |
|---|---|
| 8.1 系 | 8.1 から 8.1.3.1 より前 → 8.1.3.1 |
| 8.0 系 | 8.0 から 8.0.5.1 より前 → 8.0.5.1 |
| 7.2 系とそれより前 | 7.2.3.2 より前 → 7.2.3.2 |
JPCERT/CC によると、次の 3 つの条件をすべて満たす環境が影響を受けます。
- Active Storage の画像の処理に libvips を使っている（variant プロセッサが :vips）。Rails によると、Rails 7.0 以降の標準の設定（load_defaults 7.0）でこの設定になり、その後の標準の設定でも変わっていない
- 未信頼の利用者からの画像のアップロードを受け付けている（アプリの機能か、Active Storage の direct upload 経由）
- libvips で、特定のサードパーティのライブラリを使い、未信頼のコンテンツには安全でない（unfuzzed）と分類されたファイルローダーが有効になっている
注意が要るのは 2 つ目です。JPCERT/CC は、Active Storage の direct upload は標準で有効で、アプリごとの認証や認可の確認が標準では付いていないため、管理画面や API などに利用者向けのアップロードの機能がないアプリでも、対象になる可能性があるとしています。また、Rails 6.0.0〜6.1.7.10 も、標準と違う設定にしている場合は影響を受ける可能性があると、発見者の指摘を紹介しています。
古い版を使っている場合の注意もあります。Rails は、7.2 系より古い版はサポートが終わっているとして、少なくとも 7.2 系への更新を勧めています。さらに、2026 年 9 月 24 日の 7.2.4 が 7.2 系の最後のリリースで、今後のセキュリティの修正は 8.0 系と 8.1 系だけになると案内しています。
すぐ更新できないとき
Rails が示している回避策です。libvips が 8.13 以上なら、Rails を更新しなくても、環境変数 VIPS_BLOCK_UNTRUSTED を設定して、安全でないローダーを止められます。ruby-vips が 2.2.1 以上なら、イニシャライザ（アプリの初期設定）で Vips.block_untrusted(true) を呼ぶ方法もあります。
libvips が 8.13 未満の場合は、アプリから libvips を外す以外に回避策はありません。画像の解析のためだけに ruby-vips を入れているアプリは、外せる場合があります。JPCERT/CC は、発見者が、WAF（Web アプリを守る防御の仕組み）による対策の効果はとても限られていて、修正版への更新の代わりにはならないと指摘していることも紹介しています。
更新のあとにやること
更新で弱点はふさがりますが、すでに盗まれた鍵は元に戻りません。Rails は、影響を受けるアプリでは、アプリのプロセスから読めるすべての秘密の情報を漏れた可能性があるものとして扱い、変えるよう求めています。JPCERT/CC も、攻撃のコードが公開されているため、侵害を受けたことを前提にした対応が必要だとしています。
- secret_key_base を変える
- マスターキー（config/master.key か RAILS_MASTER_KEY）と、それで暗号化している config/credentials.yml.enc の中身を変える
- Active Storage の保存先（S3・GCS・Azure など）の鍵を変える
- データベースの認証情報を変える
- アプリが呼び出している外部のサービスのトークンや鍵を変える
secret_key_base を変えると、有効なセッションが切れ、利用者はもう一度ログインが必要になります。暗号化や署名をした Cookie、Active Storage のファイルの URL なども影響を受けます。
侵害がないかを調べる
Rails は 2026 年 7 月 31 日に、攻撃の詳細と、調査のための手引き・ツールをまとめたリポジトリ（rails/rails-forensics-CVE-2026-66066）を公開しました。中の kr2s-was-i-vulnerable は、アプリが影響を受ける状態だったか、それがいつからいつまでかを調べます。kr2s-was-i-exploited は、Active Storage のデータに細工したファイルがないかを探し、あれば何を読まれたかを調べます。
社内に Rails のエンジニアがいない場合、調査はアプリを作った会社や、セキュリティの調査を頼める会社に任せるのが現実的です（この記事での整理）。
次に読む：ホームページのセキュリティ対策の基本
自社で見直すこと
制作会社や開発会社に作ってもらった Web サービスは、公開したあと、どの部品のどの版で動いているかが社内で分からなくなりがちです。今回のように、標準の設定のままで対象になる脆弱性もあります（この記事での整理）。
- 使っている仕組みと版を控えておく サービスごとに、使っているフレームワーク（Rails など）と版、作った会社、更新を頼める相手を一覧にしておく。
- 更新の取り決めを契約で確かめる 脆弱性が見つかったときに、誰が、いつまでに更新するのか、費用はどうなるのかを、保守の契約で確かめておく。サポートが終わる版の移行の時期も話しておく。
- 鍵やパスワードを変える手順を用意しておく サービスが使っている鍵やパスワードの置き場所と、変えるときの手順・影響（再ログインなど）を、作った会社と一緒に書き出しておく。
ほかの最近の出来事は 「最近のサイバー攻撃と対策」、続けて備える体制の考え方は 「ホームページの保守」 にまとめています。
作り方は 3 つ｜完成済み・自作・オーダーメイド
作り方はどれでも選べます。優劣ではなく、向いているケースが違います。
- オーダーメイドで作る（制作会社に依頼） 要件を渡せば設計から任せられます。自社に合わせて一から作りたい場合や、撮影・原稿まで任せたい場合に向きます。SITE PICK でもオーダーメイド制作の相談を受け付けています。
- 自分で作る（自作） 費用は抑えられます。そのかわり、使っている仕組みの脆弱性の情報を追い、更新や安全対策を公開後もずっと自分で続けることになります。
- 完成済みのサイトから選ぶ（完成済み） 構成・更新の仕組み・入口が組まれた状態を実物で確かめ、社名・写真・文章を差し替えて公開します。完成形を先に確認してから決めたい場合に向きます。この記事の集計は、その実際のサイトのデータです。
