Active Storageの既定設定でlibvipsのunfuzzedな操作が有効なままだったCVE-2026-66066(KindaRails2Shell)

Ruby on Railsでファイルの添付と配信を引き受けるActive Storageに、認証を経ないままサーバー上のファイルを読み取られる脆弱性CVE-2026-66066が公表されました。通称はKindaRails2Shellです。原因は画像処理ライブラリlibvipsの使い方にあります。libvipsは自前の読み書き処理のうち、信頼できない内容へ向けるべきではないものに印を付けていますが、Active Storageはその印の付いた処理を無効化しないまま、利用者がアップロードした画像を渡していました。読み取られる対象にはRailsプロセスの環境変数が含まれ、そこに入っているsecret_key_baseや外部サービスの資格情報を通じて、リモートコード実行や他システムへの侵入に発展しうると公式アドバイザリは説明しています。

記述はRails公式のセキュリティアナウンス、GitHub Security Advisory GHSA-xr9x-r78c-5hrm、JPCERT/CCの注意喚起、cve.orgのCVEレコード、libvipsとruby-vipsの公式資料にもとづき、事実は執筆時点(2026年8月2日)で確認できた範囲に限ります。攻撃の再現手順やペイロードは扱いません。挙動の確認は自組織が管理する環境に対してのみ行います。

CVE-2026-66066の基本情報#

Rails開発チームは2026年7月29日(現地時間)、Security Announcementsフォーラムと同じ内容のGitHub Security Advisory GHSA-xr9x-r78c-5hrmを公開しました。CVEレコードを採番したCNAはGitHubで、cve.org上の公開日時は2026年7月30日です。分類はCWE-1188(Initialization of a Resource with an Insecure Default)で、資源の初期化が安全でない既定値のまま行われる欠陥の類型に当たります。この名称は2023年10月26日公開のCWE 4.13で改められたもので、CVEレコードには旧名称のInsecure Default Initialization of Resourceが残っています。

深刻度はCNAの評価としてCVSS 4.0で9.5、区分はCriticalです。ベクトルはCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:Hで、ネットワーク経由で到達でき、事前の権限も利用者の操作も要らないという評価です。AT:P(Attack Requirements: Present)は成立に環境側の前提が要ることを示し、今回はlibvipsを使う構成とアップロードの受け付けがそれに当たります。NVDのAPIで確認した執筆時点の状態はReceivedで、NVD独自の再評価はまだ掲載されていません。

ベクトルの各要素の意味と環境条件の織り込み方は次の記事で整理しています。

国内では、JPCERT/CCが2026年7月30日にJPCERT-AT-2026-0021として注意喚起を公開しました。報告者はEthiackの0xacb、s3np41k1r1t0、castilhoの各氏と、GMO Flatt SecurityのRyotaK氏です。

unfuzzedと印の付いた処理が開いたままだった機構#

libvipsは、画像形式ごとの読み込みと書き出しをローダとセーバーという単位で扱い、その多くを第三者製のライブラリに委ねています。悪意ある入力を想定したファジングが十分に行われたものもあれば、そこまでの検証が済んでいないものもあります。libvipsは後者にunfuzzedという印を付け、信頼できない内容の処理に使うべきではないと表明しています。印の付いた形式には、Web向けの画像と関係のないものが多く含まれます。

libvipsは8.13で、印の付いた操作を実行時にまとめて止める仕組みを導入しました。環境変数VIPS_BLOCK_UNTRUSTEDが設定されていれば、untrustedと分類された操作の実行を拒否します。

Active Storageは、この止める仕組みを使っていませんでした。修正コミットの説明によれば、画像を解析するVipsアナライザーと、variantを生成するVipsトランスフォーマーの双方が、信頼できない添付ファイルをunfuzzedな操作へ渡しうる状態でした。Rails開発チームは、報告された攻撃連鎖が唯一のものだとは想定しないとも書いています。

Rails公式アドバイザリは、libvipsが一部の操作をunfuzzed(信頼できない入力に対する安全性が確認されていない)と印付けしており、Active Storageがそれらを無効化していなかったため、細工したファイルをアップロードしてvariantを生成させられる攻撃者がそうした操作を呼び出しうると記載しています。

修正版の実装は単純で、Active Storageが起動時にVips.block_untrusted(true)を呼び、initializerが動く前にunfuzzedな操作を止めます。なお攻撃の技術的な詳細はアドバイザリから意図的に省かれており、未更新のアプリケーションを守るため、遅くとも2026年8月28日までにSecurity Announcementsフォーラムで開示すると予告されています。

影響を受けるアプリケーションの条件#

公式アドバイザリは、次の2つをすべて満たすアプリケーションが影響を受けるとしています。1つはActive Storageの画像処理にlibvipsを使っていること、つまりconfig.active_storage.variant_processorが:vipsであることです。この値はload_defaults 7.0が設定し、それ以降の既定でも変更されていません。もう1つは、信頼できない利用者からの画像アップロードを受け付けていることです。アドバイザリは、variantを生成していること自体は別個の要件ではないと明記しています。JPCERT/CCの注意喚起は、これにlibvipsが配布パッケージなどの規定のビルドであることを加えた3条件で整理しています。

見落としやすいのが入り口の広さです。JPCERT/CCは、Active Storageのdirect upload機能には既定で認証が存在しないため、利用者向けのアップロード機能を持たないアプリケーションでも、Active Storageを有効にしていれば対象になりうると注記しています。画面にアップロードのUIを出していないことは、安全側の根拠になりません。アップロード機能そのものが持つリスクと、受け入れ側で何を検証すべきかは次の記事で整理しています。

影響を受ける版と修正版#

影響範囲と修正版の対応は次の表のとおりです。gem名で言えばactivestorage、Rails本体の同じ版番号に対応します。

注意したいのは、7.2.3.2より前という表現に7.1系や7.0系、6.x系も含まれる一方で、それらの系列には修正版が出ていない点です。RubyGems上で2026年7月29日に公開された修正版は3つだけで、7.1系は2025年10月28日の7.1.6が最新のままです。Railsのメンテナンスポリシーは各マイナー系列の最初のリリースから2年間セキュリティ修正を提供すると定めており、7.1.0は2023年10月5日の公開なのでその期間を過ぎています。7.1系以前で塞ぐ道は、修正版のある系列へアップグレードするか、後述の緩和策でlibvips側を止めるかのどちらかです。

6.x系については、JPCERT/CCが発見者の指摘として、Rails 6.0.0から6.1.7.10までは、Active Storageが既定とは異なる設定でセットアップされている場合に影響を受ける可能性があると注記しています。6.x系の既定のvariantプロセッサはlibvipsではないため、手作業で:vipsに切り替えている構成が該当します。

どの版のactivestorageやruby-vipsが入っているかを継続的に把握する仕組みが、対応の速さを決めます。依存パッケージの棚卸しとSCAの考え方は次の記事にまとめています。

アップグレードの前提になるlibvipsとruby-vipsの版#

修正版を入れる作業には順序があります。Active Storageの最低要件が引き上げられ、libvipsは8.13以上、ruby-vipsは2.2.1以上が必要になりました。unfuzzedな操作を止められるのがこれらの版以降だからです。

要件を満たさない環境でruby-vipsがインストールされていると、Active Storageは安全にできない環境で動き続けるかわりに、起動時にRuntimeErrorを発生させます。JPCERT/CCも、この点を先に手当てしないとアプリケーションが起動しないと述べています。gemを上げる前にOS側のlibvipsパッケージの版を確認する段取りにしておくと、更新作業中の停止を避けられます。

Rails公式ガイドのActive Storage Overviewは、unfuzzedと印の付いたローダとセーバーをActive Storageが起動時にすべて無効化すること、そのためにlibvips 8.13以上とruby-vips 2.2.1以上が最低要件になること、要件を満たさない場合は起動時にRuntimeErrorを発生させることを記載しています。

修正版で変わる画像処理の挙動#

この修正は互換性を壊す変更を含みます。公式ガイドによれば、多くのプラットフォームでlibvipsはBMPやICO、PSDの読み込みをImageMagickに委ねており、そのImageMagickローダ自体が無効化の対象です。これらの形式はvariantを生成しようとするとVips::Errorを発生させます。SVGやJPEG XL、JPEG 2000、Netpbmでは解析でwidthとheightが記録されなくなり、出力側もFITSやJXLなどを指定するとエラーになります。添付と保存とダウンロードの挙動は変わりません。

エラーが表に出て困る場合の逃がし方として、公式はinitializerでconfig.active_storage.variable_content_typesからimage/bmpやimage/vnd.microsoft.icon、image/vnd.adobe.photoshopを外す方法を案内しています。Vips.blockでImageMagickローダを開け直す方法もありますが、libvipsがImageMagickへ委譲する形式はこの3つにとどまらないため、公式ガイドは攻撃面が広がる危険な操作として警告しています。

variantプロセッサの設定と修正版の起動時要件は、切り分けて理解する必要があります。

脆弱性の成立条件の側では、variant_processorが:vipsであることが前提です。Active StorageのImageAnalyzer::Vipsはaccept?でActiveStorage.variant_processorが:vipsであることを条件にしており、:mini_magickへ切り替えた構成ではVipsのアナライザーは入力を受理せず、ImageMagickのアナライザーが担当します。ただし公式が示す対応はあくまで修正版への更新であり、プロセッサの変更を恒久的な対策として据えるのは避けます。攻撃の技術的詳細が未開示である以上、設定値の変更だけで塞げる範囲を見積もる根拠がそろっていません。libvipsを処理経路から完全に外すのであれば、Gemfileからruby-vipsを取り除くところまで行います。

修正版の起動時要件はこれとは別の話です。修正コミットは、ruby-vipsがインストールされている限り、:mini_magickを使っていてlibvipsを実際には呼ばない構成でも、libvips 8.13以上とruby-vips 2.2.1以上の確認と、Vips.block_untrusted(true)によるプロセス全体での無効化が適用されると述べています。libvipsを使っていないつもりの環境でも、gemが残っていれば版の要件が課される点に注意します。

すぐに更新できない場合の緩和策#

選択肢はlibvipsの版によって変わります。libvipsが8.13以上であれば、Railsを上げなくても環境変数VIPS_BLOCK_UNTRUSTEDを設定することで、unfuzzedな操作を無効化できます。libvipsは初期化時にこの環境変数を読みます。ruby-vipsが2.2.1以上であれば、initializerからVips.block_untrusted(true)を呼ぶ方法も使えます。

libvipsが8.13未満の場合、公式アドバイザリは、アプリケーションからlibvipsへの依存そのものを取り除く以外に回避策はないとしています。ruby-vipsを画像の解析目的だけで入れているのであれば、Gemfileから外すことでlibvipsを処理経路から切り離せます。

WAFで止めるという発想には注意が必要です。JPCERT/CCは、発見者がWAFによる対策の有効性は極めて限定的であり、修正版へのアップデートの代替にはならないと指摘していると記載しています。

JPCERT/CCの注意喚起JPCERT-AT-2026-0021は、影響条件をActive Storageの有効化、variantプロセッサがlibvips(:vips)であること、libvipsが規定のビルドであることの3点と整理し、エクスプロイトコードが公開されていることを確認したうえで、読み取り可能なすべての認証情報を漏えい済みとして扱い変更することを推奨しています。

シークレットの入れ替えが必要になる理由#

アップグレードは穴を塞ぎますが、すでに持ち出された秘密情報を無効化はしません。公式アドバイザリは、影響を受けたアプリケーションについて、プロセスが読めるすべての秘密情報を露出済みとして扱い変更するよう求めています。挙げられているのは、secret_key_base、config/master.keyまたはRAILS_MASTER_KEYとして与えられるマスターキーとそれが復号するconfig/credentials.yml.encの中身、S3やGCSといったActive Storageのサービス資格情報、データベースの資格情報、第三者サービスのトークンやキーです。

secret_key_baseを入れ替えると副作用が出ます。稼働中のセッションは失効し、暗号化Cookieや署名付きCookie、署名付きグローバルID、Active StorageのURLも影響を受けます。アドバイザリは、ローテーション機構を使う場合でもそれは中間段階にとどめ、露出した値をフォールバックとして残さないよう明記しています。

この値が重く扱われるのは、Railsが署名や暗号化の土台に使っているためです。公式アドバイザリは、プロセスの環境変数に含まれるsecret_key_baseや外部システムの資格情報が読み取られた場合、リモートコード実行への昇格や、それらのシステムへの横展開につながりうると述べています。昇格や横展開が具体的にどう起きるかは、前述のとおり技術的詳細の開示を待つ段階です。信頼できないデータの復元がコード実行に結びつく一般的な仕組みは次の記事で整理しています。

秘密情報をどこに置き、どう配り、どの頻度で入れ替えるかという設計が、事故のたびの作業量を左右します。集中管理とローテーションの実務は次の記事で扱っています。

悪用状況の確認#

悪用の状況は情報源によって書きぶりが分かれます。発見者であるEthiackは、防御側が更新する時間を確保するため技術的詳細とPoCを当面伏せるとしたうえで、パッチが出た後はAIを使う攻撃者が短時間で再構成しうると想定すべきだと述べています。一方でJPCERT/CCは、注意喚起を公開した2026年7月30日の時点で、本脆弱性に関するエクスプロイトコードが公開されていることを確認したと記載しています。

CISAのKnown Exploited Vulnerabilities(KEV)カタログは、執筆時点で参照できた版(カタログ版2026.07.29)にCVE-2026-66066を収録していません。未収録は安全を意味せず、更新前に侵入されていた可能性を前提とした点検まで計画に含めるのが妥当です。

対応の手順#

順序を誤ると更新作業でアプリケーションが起動しなくなります。次の流れで進めます。

確認チェックリスト#

対応の抜けを防ぐための項目を整理します。

まとめ#

CVE-2026-66066は、Active Storageがlibvipsのunfuzzedな操作を止めないまま、信頼できないアップロード画像を処理経路へ通していた既定設定の欠陥です。認証を経ない相手がRailsプロセスの読めるファイルと環境変数を読み出せるため、secret_key_baseの露出を通じてリモートコード実行や外部サービスへの侵入まで届きうる点が重く見られています。対応は、libvipsとruby-vipsを先に要件まで上げてからactivestorageを7.2.3.2、8.0.5.1、8.1.3.1のいずれかへ更新し、互換性の変化を検証したうえで、秘密情報を入れ替えるところまでが一続きの作業です。7.1系以前には修正版がなく、libvipsが8.13未満の環境には回避策もないため、依存の版を把握することが対応の起点になります。技術的詳細は遅くとも2026年8月28日までに開示される予定です。