9月4日、Riettaが「Government Rails Site Hit Hours After CVE Patch」と題した記事を公開した。Ruby on RailsのActiveStorageに発見されたリモートコード実行の脆弱性（CVE-2026-66066）に対し、パッチ適用からわずか8時間後に政府系サイトへの攻撃が実行された実例を詳述したものだ。

セキュリティ業界では長年、「パッチを当てれば一時的に安全が確保できる」という前提のもとで脆弱性開示プロセスが設計されてきた。しかし今回の事例はその前提を根本から崩すものだ。攻撃者がパッチのコードdiffから攻撃手法を逆算し、公式の技術解説が公開される24時間以上前に実際の攻撃を開始した。「情報公開猶予（エンバーゴ）」という仕組みが、構造的に機能しなかったことを示す具体的な記録である。

パッチ適用8時間後に攻撃が来た

2026年7月29日夜、セキュリティ企業Riettaは、Ruby on RailsのActiveStorage（ファイルアップロード機能を担うコンポーネント）に存在するリモートコード実行の脆弱性に対し、クライアント全体へ緊急ホットフィックスを適用した。

ActiveStorageはRails 5.2以降に標準搭載されており、ファイルのアップロード・管理・配信を担う中核コンポーネントだ。政府系・公共系サービスを含む多数のRailsアプリケーションで利用されており、そこに深刻な欠陥が見つかったことが、今回の影響範囲の広さにつながっている。

この脆弱性はCVE-2026-66066（KindaRails2Shell）と命名され、CVSSスコアは9.5/10という最高水準の深刻度だ。「KindaRails2Shell」という名称は、MATLABファイルを偽装したアップロードを経由してシェル権限を奪取する攻撃手法に由来する。発見したのはセキュリティリサーチ企業Ethiackの研究チームで、攻撃面はActiveStorageのファイル種別検証の不備にある。

Riettaがある州政府クライアントへパッチを完全展開したのは7月29日 午後11時09分（EST）。そして翌30日の午前7時10分25秒、そのクライアントのログに最初の攻撃試行が記録された。パッチ適用からわずか8時間1分後のことだ。

「エンバーゴ」はなぜ機能しなかったか

CVEの開示プロセスでは通常、攻撃手法の技術的詳細について一定期間のエンバーゴ（embargo）、すなわち情報公開猶予が設けられる。防御側がパッチを適用する時間を確保するためだ。今回のGitHubアドバイザリには「2026年8月28日以降に詳細開示」と明記されていた。

しかし実態は次のとおりだった。

エンバーゴが意味を持たなかった理由は構造的な問題だ。パッチそのものはコードdiffとして公開されており、最初からエンバーゴの対象外だった。「攻撃手法の説明」を伏せても、差分を読めば攻撃方法は推測できる。Rapid7の調査によれば、Railsプロジェクトは「複数の研究者がすでに独自に攻撃を再現しPoC公開に至った」ことを受け、予定より早くフォレンジックツールを公開している。

最初の攻撃試行は、Ethiackの技術解説より約24時間前、Railsの公式フォレンジックツール公開より13時間以上前に発生した。攻撃に使われたのは不正に細工されたBMPファイルで、GitHubに公開されたPoCと同じ手法だったことから、RiettaはそのコードをもとにしたPoCが攻撃者に転用された可能性が高いと分析している。

脆弱性の発見者の一人であるEthiackの研究者André Baptista（@0xacb）はこう述べている。

「防御側に時間を与えるため、複数のケースで技術的詳細を抑制してきた。だが、事態の進行が速すぎる。」

この発言は、パッチdiffからの攻撃手法逆算という問題が、今回に限らずセキュリティ業界全体の構造的な課題であることを示している。

8月を通じて攻撃は続いた

8月3日以降、攻撃はPNGファイルを偽装した手法に切り替わり、世界各地のIPアドレスから断続的に継続した。使用されたUser-Agentの中には Mozilla/5.0 (CVE-2026-66066 security verification) という、CVE番号をそのまま名乗る露骨なものまで含まれていた。

8月を通じて攻撃は毎日記録され、Riettaが追加のセキュリティ措置を講じると攻撃パターンが変化するなど、適応的な動作も確認された。すべての攻撃試行はパッチによって防御されたが、「攻撃が失敗し続けた」こと自体が、早期パッチ適用の効果を示す証拠だ。

この事例から得られる教訓

Riettaはこの事例から5つの実践的な対策を提示している。

CVSSスコアが付く前から動く。スコアのアサインは実際のリスクより数時間以上遅れる。ベンダーが単独のセキュリティリリースを出した時点で重大だと判断する運用ルールを設けるべきだ。

緊急パッチの承認権限を事前に確立する。誰かが起床して承認するまでパッチが待たされる体制では、今回のケースで言えば攻撃が来た午前7時時点でまだ無防備だったことになる。

ファイルアップロードのコードパスを独立した脅威モデルとして扱う。Content-Typeヘッダーではなく、マジックバイトによるファイル種別検証を徹底する。今回の攻撃面はまさにそこだった。

静的解析ツールをナイトリーで継続実行する。Railsアプリであればbundler-auditやBrakemanを毎日自動実行し、トリアージ体制を整えることが重要だ。

失敗したリクエストのログを必ず確認する。攻撃の試行は成功した通信よりも失敗ログに現れる。例外モニタリングを導入し、異常なパターンを見逃さない仕組みが必要だ。

今回の事例が示すのは、「パッチを当てれば安全」ではなく「パッチを当てるまでの数時間が勝負」という現実だ。ActiveStorageを使うすべてのRailsアプリケーションの管理者は、対応状況を改めて確認しておく必要がある。

詳細はGovernment Rails Site Hit Hours After CVE Patchを参照していただきたい。