RailsのActive Storageの脆弱性CVE-2026-66066
Railsの2026年7月29日のアドバイザリによると、Ruby on RailsのActive Storageはlibvipsの一部の操作を無効にしておらず、既定の構成で画像のvariantを表示するアプリでは、認証の無い攻撃者がサーバー上の任意のファイルを読み取れる可能性がある［1］。The Hacker Newsは9月1日、VulnCheckがこの脆弱性の悪用を検知したと報じた［16］。
脆弱性の内容
Railsはアドバイザリで、libvipsが一部の操作に「unfuzzed」（未信頼の内容には安全でない）の印を付けていると説明した［1］。Active Storageはこの操作を無効にしておらず、細工したファイルをアップロードしてvariantを生成させた攻撃者が、その操作を呼び出せる可能性がある［1］。読み取られるプロセスの環境は通常secret_key_baseを含み、外部システムの認証情報を含むことも多いため、リモートコード実行や外部システムへの横展開に至りうる［1］。報告された攻撃の連鎖は1つだが、Railsはそれが唯一とは考えていないとした［1］。
| 項目 | 値 | 資料 |
|---|---|---|
| CVE | CVE-2026-66066 | ［1］ |
| 通称 | KindaRails2Shell（Ethiackの命名） | ［9］ |
| CVSS | 9.5（CVSS v4.0、CRITICAL。NVDのレコードで、CNAはGitHub） | ［8］ |
| CWE | CWE-1188 | ［8］ |
Active Storageは、2018年4月9日に公開されたRails 5.2.0で導入された［19］。Ethiackの説明では、同社の研究チームが最初に独立して発見・報告し、数日後にGMO Flatt Securityの研究チームの研究者も報告した［9］。
攻撃の仕組み
37signalsのHot Cell v1.0の記事は、攻撃に連なった要素として7つを挙げた［5］。
- 既定で有効だったdirect uploadの経路［5］
- direct uploadがバイト列を調べず、申告のcontent typeを信じること［5］
- 署名付きのvariation keyにblobのIDが含まれないこと［5］
- RailsがVips.block_untrustedを呼んでいなかったこと［5］
- libvipsが偽のMATLABの見出しにだまされたこと［5］
- libmatioが渡されたファイルを信頼すること［5］
- secret_key_baseからリモートコード実行に至る既知のガジェット［5］
Ethiackの技術分析では、攻撃の要はHDF5のexternal storageである［10］。MAT v7.3の形式はHDF5で、データセットの中身を任意のパス・オフセットの別のファイルに置けるが、libmatioはそれを確かめずに読み込む［10］。libvipsは見出しが「MATLAB 5.0」で始まるファイルだけをMATとしてlibmatioに渡し、libmatioはオフセット124の版の語でHDF5として読む［10］。この判定の食い違いで任意のファイルを読ませられる［10］。
Ethiackは、variation keyが変換だけを署名するため、公開されたキーを別のblobに使い回すと、生成された画像の画素として対象のファイルの中身が返ると説明した［10］。読み取ったsecret_key_baseで変換を署名すれば、CVE-2025-24293の修正漏れ（vipsの変換器が許可リストを強制していない）を使って任意のコードを実行できる［10］。Ethiackはlibvipsの読み込み処理の調査にClaude Opus 4.8を使い、24時間以上誘導して連鎖を組み立てたと書いた［10］。Claudeは外部の資料に触れず、ソースコードの分析で手法を見つけたとも追記した［10］。
別の研究者が7月18日に公開した「Leaky Avatar」は、HDF5のexternal datasetを使い、縮小したアバターから/proc/1/environを読む手法に独立に到達していた［10］。Ethiackはこのことを後から知ったと書いた［10］。
詳細の公開の時期
Railsは当初、攻撃の連鎖の技術的な詳細をアドバイザリから意図して省き、遅くとも8月28日までにRails Security Announcementsのフォーラムで公開するとしていた［1］。その後、複数の研究者がすぐに攻撃を解析して概念実証を公開したため、詳細とツールを前倒しで公開したと説明した［3］。37signalsの記事は、複数の研究者が告知から数時間で攻撃を導き出し、詳細を伏せた意味が無くなったと書いた［5］。GMO Flatt Securityは、記事を公開した際にはPoCを公開していないが、事前の検証ではAIなどを使えば数時間以内にPoCが作られる可能性が高いと判断したと書いた［11］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2026年 | Ethiack | 最初の動くPoCを完成させた | ［15］ |
| 2026年 | Ethiack | Railsに脆弱性を報告した | ［15］ |
| 2026年 | Rails | 報告を受領した | ［15］ |
| 2026年 | Rails | 修正版とセキュリティアドバイザリを公開した | ［1、2］ |
| 2026年 | Ethiack | KindaRails2Shellの概要の記事を公開した | ［9］ |
| 2026年 | GMO Flatt Security | 概要と対応指針の記事を公開した | ［11］ |
| 2026年 | JPCERT/CC | 注意喚起を出した | ［7］ |
| 2026年 | NVD | CVEのレコードを公開した | ［8］ |
| 2026年 | Rails | 攻撃の詳細とフォレンジック調査用のツールを公開した | ［3］ |
| 2026年 | Ethiack | 技術分析を公開した | ［10］ |
| 2026年 | Rapid7 | 根本原因の技術分析とMetasploitのモジュールを公開した | ［12］ |
| 2026年 | JPCERT/CC | 注意喚起を更新し、侵害の検出方法を加えた | ［7］ |
| 2026年 | 37signals | Active Storageの処理を分離するHot Cell v1.0を公開した | ［5］ |
対象の製品と版
Railsのアドバイザリによると、影響を受けるのは、Active Storageの画像処理にlibvipsを使い、未信頼の利用者からの画像のアップロードを許すアプリである［1］。libvipsを使う設定はconfig.active_storage.variant_processorにvipsを指定するもので、load_defaults 7.0が設定し、以後の既定も変えていない［1］。variantの生成は別の要件ではないとした［1］。
| 製品 | 影響を受ける版 | 修正版 | 資料 |
|---|---|---|---|
| activestorage（7.2系まで） | 7.2.3.2未満〔注1〕 | 7.2.3.2 | ［1］ |
| activestorage（8.0系） | 8.0以上8.0.5.1未満 | 8.0.5.1 | ［1］ |
| activestorage（8.1系） | 8.1以上8.1.3.1未満 | 8.1.3.1 | ［1］ |
Ethiackは、影響はVipsの処理系だけで、Magickを使うアプリはこの経路では影響を受けないと説明した［9］。GMO Flatt Securityは、DebianやUbuntu、rails newなどで生成されるDockerfileを用いた環境は既定で影響を受けると書いた［11］。JPCERT/CCは注意喚起で、direct uploadは既定で有効で、標準ではアプリ固有の認証・認可が無いため、利用者向けのアップロード機能を持たないアプリでも対象となる可能性があるとした［7］。
Rapid7の試験では、通常のサーバー側の添付ではこの連鎖が成り立たなかった（Railsが細工したファイルをMATLABのデータとして判定し直す）［12］。Rapid7は、direct uploadの経路は、Active Storageのルートを載せていればアプリが使っていなくても既定で存在すると説明した［12］。
| 配布元 | 状態 | 修正版・アドバイザリ | 資料 |
|---|---|---|---|
| Debian（bookworm） | 修正版あり | 2:6.1.7.10+dfsg-1~deb12u3（DLA-4829-1） | ［6］ |
| Debian（trixie） | 修正版あり | 2:7.2.2.2+dfsg-2~deb13u2（DSA-6546-1） | ［6］ |
| Debian（unstable） | 修正版あり | 2:7.2.3.2+dfsg-1（Debian Bug 1143080） | ［6］ |
| libvips（MATLABの見出しの判定） | 修正済み、CVEは公開されていない | libvips 8.18.5 | ［5］ |
| libmatio | 修正しない（Won't fix） | - | ［5］ |
37signalsの記事は、libvipsが偽のMATLABの見出しにだまされたことを実際の欠陥とし、libmatioの保守者はlibvips側の問題と指摘したと書いた［5］。
悪用の状況
Rapid7は、7月30日現在、実環境での悪用を把握していないと書いた［12］。The Hacker Newsの記事によると、Rails Security Teamは同誌に、公表の前後で悪用も悪用の試みも把握していないと述べた［15］。同じ記事は、7月29日17時30分（UTC）の確認ではこのCVEはCISAのKnown Exploited Vulnerabilitiesカタログの版2026.07.27に無く、その後に公開された第三者のGitHubリポジトリが、ファイル読み取りからリモートコード実行までの連鎖を再現すると主張したと報じた［15］。The Hacker Newsはこのリポジトリを検証していない［15］。
VulnCheckは8月1日〜7日の報告で、この脆弱性のエクスプロイトを作成し、露出した脆弱なRailsのインスタンスを7,100以上〔注2〕数えたと書いた［14］。その報告の範囲では、悪用の報告は無かった［14］。
SecurityWeekは、VulnCheckによると、攻撃者は修正版の公開から約1か月後に当たる前週にこの脆弱性の悪用を始めたと報じた［17］。
The Hacker Newsは、VulnCheckが悪用を検知したのはシンガポール・イスラエル・英国に置いたcanaryだと報じた［16］。VulnCheckの研究者はLinkedInで、活動はフランスの単一のIPアドレスから来てイスラエルのホストへC2を張ると述べた［16］。NVDのレコード（9月10日更新）にも、KEVへの登録の項目は無い［8］。
修正と回避策
Railsはアドバイザリで、対策として次の手順を示した［1］。
- activestorageの修正版に更新する［1］。
- libvipsを8.13以上に更新する（8.13未満はunfuzzedの操作を無効にできず、その環境ではActive Storageが起動時に例外を出す）［1］。
- secret_key_baseと、アプリの環境から読める秘密情報を変更する［1］。
Railsのアドバイザリによると、更新は脆弱性を塞ぐが、すでに持ち出された秘密情報は元に戻らない［1］。影響を受けたアプリは、プロセスから読めるすべての秘密情報を漏えいしたものとして扱い、変更するよう求めた［1］。対象にはsecret_key_base、マスターキーとcredentials.yml.encの中身、S3・GCS・Azureなどのストレージの鍵、データベースの認証情報、外部サービスのトークンと鍵を挙げた［1］。
Railsは、secret_key_baseを変えるとセッションが失効し、利用者は再ログインが要ると説明した［1］。暗号化・署名付きのCookie、署名付きのglobal ID、Active StorageのURLにも影響する［1］。鍵の切り替え（rotation）は必要なときの中間段階に限り、漏えいした秘密情報を予備として残さないよう求めた［1］。
Railsのアドバイザリによると、libvips 8.13未満では、libvipsへの依存を外す以外の回避策は無い［1］。画像の解析のためだけにruby-vipsを入れているアプリは、Gemfileから外せる場合がある［1］。libvips 8.13以上なら、Railsを更新せずに環境変数VIPS_BLOCK_UNTRUSTEDでunfuzzedの操作を無効にでき、ruby-vips 2.2.1以上ならinitializerでVips.block_untrusted(true)を呼ぶこともできる［1］。
Railsは修正版の告知で、できるだけ早い更新を強く勧め、古い版はサポート外なので少なくとも7.2系に更新するよう勧めた［2］。Rails Security TeamはThe Hacker Newsに、Rails 7.1以前はサポート終了でバックポートしないため、7.2.3.2以降への更新が要ると説明した［15］。Ethiackの技術分析では、Railsの修正はvipsの使用時に信頼できない読み込みを止めるもので、BMP・ICO・PSDの変換は「Vips::Error」になり、SVG・JPEG XL・JPEG 2000・Netpbmの画像の解析では幅と高さを記録しなくなる［10］。
JPCERT/CCの注意喚起によると、同センターはエクスプロイトコードの公開を確認しており、今後この脆弱性を悪用する攻撃が広く行われる可能性がある［7］。影響を受ける可能性がある環境では侵害を前提に、読み取り可能なすべての認証情報を漏えい済みとして扱い、変更することを推奨した［7］。
EthiackはWAFについて、一部の構成で時間を稼げるかもしれないが修正ではないと書いた［9］。GMO Flatt Securityも、WAFによる緩和策の有効性は「極めて限定的」で、修正版への更新の代わりにしないよう求めた［11］。Help Net Securityは、AkamaiがEthiackと公開前に調整し、KindaRails2Shell向けのWAFのルールを配備したと説明したと報じた［18］。
修正後に残る経路
VulnCheckは修正版8.1.3.1のサーバーで試し、修正はlibvipsのファイル読み取りを止めるが、variation keyのMarshalの逆シリアル化は止めず、有効な署名があればリモートコード実行のガジェットは修正済みのサーバーでも動くとした［14］。Rapid7は、同社が示したリモートコード実行の経路はMarshalのオブジェクトのガジェットに依存しないと書いた［13］。
侵害の調査とその後の対策
Railsが公開したリポジトリrails/rails-forensics-CVE-2026-66066には、次のものが入っている［3］。
- 攻撃の手順の説明（reference/the-attack.md）［3］
- データベースとオブジェクトストアに残る痕跡の説明（reference/the-investigation.md）［3］
- 脆弱だったか、その期間を調べるagent skill（kr2s-was-i-vulnerable）［3］
- 細工したファイルを探し、何が読まれたかを調べるagent skill（kr2s-was-i-exploited）［3］
投稿者は、これらのツールを37signalsで自社のアプリをフォレンジック分析した作業から取り出したと書いた［3］。JPCERT/CCは更新した注意喚起で、開発者が公開したフォレンジック調査用のツールとガイドで影響の有無を調べるよう加えた［7］。Rapid7は、未使用のblobを消す定期処理が証拠を消しうるため、フォレンジックの調査を早く始めるよう勧めた［12］。
37signalsは、Active Storageの画像・動画・PDFの処理を権限の無いサイドカーのコンテナに移すHot Cell v1.0を、Basecamp・HEY・Fizzyの本番で動かしていると書いた［5］。Railsは同じ内容のセキュリティアドバイザリを、GitHubのrails/railsのリポジトリにも掲載した［4］。
未公表の事項
- 悪用を受けた組織・アプリの数と名前
- 影響を受けるアプリの数（Rails Security TeamはThe Hacker Newsに、Vipsで使うアプリの数のテレメトリも妥当な推計も無いと述べた［15］）
- 悪用した攻撃者の帰属
- 持ち出された秘密情報による二次被害
注
出典
当事者
- ［1］Ruby on Rails『[CVE-2026-66066] Possible arbitrary file read and remote code execution in Active Storage variant processing』（2026年7月29日公開）
- ［2］Ruby on Rails『Rails Versions 7.2.3.2, 8.0.5.1, and 8.1.3.1 have been released!』（2026年7月29日公開）
- ［3］Ruby on Rails『[CVE-2026-66066] Attack details, and tools to perform a forensic investigation』（2026年7月31日公開）
- ［4］Ruby on Rails『Possible arbitrary file read and remote code execution in Active Storage variant processing（GHSA-xr9x-r78c-5hrm）』（2026年7月29日公開、保存記録のみ） 保存記録
関係組織
- ［5］37signals LLC『Hot Cell v1.0: Securing Active Storage in the age of AI』（2026年10月5日公開）
- ［6］Debian Project『CVE-2026-66066』（公開日不明、2026年11月7日閲覧）
公的機関
- ［7］一般社団法人JPCERTコーディネーションセンター『Ruby on RailsのActive Storageにおけるリモートコード実行につながる脆弱性（CVE-2026-66066）に関する注意喚起（JPCERT-AT-2026-0021）』（2026年7月30日公開、2026年8月3日更新）
- ［8］National Institute of Standards and Technology『CVE-2026-66066』（2026年7月30日公開、2026年9月10日更新）
調査・観測
- ［9］Ethiack『KindaRails2Shell - Critical RCE in Rails via Active Storage (CVE-2026-66066)』（2026年7月29日公開）
- ［10］Ethiack『KindaRails2Shell: How a MATLAB file reads your secrets and pops a shell on Rails』（2026年7月31日公開）
- ［11］GMO Flatt Security株式会社『深刻度「緊急」のRails脆弱性「KindaRails2Shell」（CVE-2026-66066）の概要と対応指針』（2026年7月30日公開）
- ［12］Rapid7, Inc.『KindaRails2Shell: CVE-2026-66066, Critical Arbitrary File Read and Possible Remote Code Execution in Ruby on Rails』（2026年7月30日公開、2026年8月3日更新）
- ［13］Rapid7, Inc.『Rapid7 Analysis: KindaRails2Shell (CVE-2026-66066)』（2026年8月3日公開）
- ［14］VulnCheck Inc.『New exploits and detections for backdoored Zbtlink routers, Ruby on Rails, vCenter Server x2, Microsoft Windows x2, and more.』（2026年8月7日公開）
報道機関
- ［15］The Hacker News『Critical Rails Flaw Could Let Unauthenticated Attackers Read Server Files via Image Uploads』（2026年7月29日公開）
- ［16］The Hacker News『Attackers Exploit Critical Langflow and Rails Flaws in Credential-Probing and C2 Activity』（2026年9月1日公開）
- ［17］SecurityWeek『Critical Ruby on Rails Vulnerability in Attackers' Crosshairs』（2026年8月31日公開）
- ［18］Help Net Security『KindaRails2Shell threatens Ruby on Rails apps (CVE-2026-66066)』（2026年8月3日公開）
背景資料
- ［19］Ruby on Rails『Rails 5.2.0 FINAL: Active Storage, Redis Cache Store, HTTP/2 Early Hints, CSP, Credentials』（2018年4月9日公開）
更新記録
- 2026年8月13日：公開した。
- 2026年8月31日：SecurityWeekの8月31日の記事（出典17）が伝えたVulnCheckによる悪用の開始を「悪用の状況」に、インスタンス数の差を「注」に加えた。
- 2026年9月1日：The Hacker Newsの9月1日の記事（出典16）が伝えたVulnCheckのcanaryでの悪用の検知と発信元を、リードと「悪用の状況」に加えた。
- 2026年9月10日：NVDのレコードの9月10日の更新（出典8）にKEVへの登録の項目が無いことを「悪用の状況」に加えた。
- 2026年10月5日：37signalsの10月5日の記事（出典5）を加え、攻撃を構成する要素を「脆弱性の内容」に、libvipsとlibmatioの対応を「対象の製品と版」に、Hot Cell v1.0を「修正と回避策」に加えた。