セキュリティ業界には長年培われてきた不文律がある。脆弱性が発見されると関係者は秘密保持契約を結び、防御側が水面下で修正コードを用意し、期日を定めて一斉に公表した上で、運用者が順次パッチを適用していく――この協調的なペースが長年にわたってエコシステムを支えてきた。
しかし2026年10月21日、その秩序は崩壊した。公式パッチが配信される予定時刻の数時間前から、Cloudflareの監視網には実際の攻撃トラフィックが次々と検知され始めた。攻撃者は防御側が鍵を取り替えるのを待ってはくれなかった。
それに先立つ21時間前、2件の脆弱性の詳細が技術フォーラムへ流出していた。「PHP2Shell」と名付けられたこの嵐は、世界中のWebサイト管理者を混乱に陥れた。最初のリーク投稿はまもなく削除されたものの、複数のセキュリティ機関が迅速に事実確認を実施。防御側が技術詳細を把握した時点では、すでに攻撃者のほうが一歩先を行っていた。
パッチ公開前に実攻撃が観測
2件の脆弱性にはCVE-2026-109618およびCVE-2026-109619の識別子が割り当てられている。PHP公式によるCVSS v4.0スコアは9.2、セキュリティ研究機関のwatchTowrに至っては最高値の10.0を付けた。この評価のもとでは、インターネットに接続された該当サーバは即座に乗っ取りの危機に晒される。
情報の漏洩が始まったのは協定世界時（UTC）10月20日15時20分。petecooperと名乗るユーザーがコミュニティ上でパッチ予告を公開し、続いてCalif Research名義の検証ツールがネットワーク上に出回った。技術者たちが検証した結果、実際の環境で攻撃コードが成立することが確認された。そして10月21日07時43分、Cloudflareは公式公開予定時刻より6時間以上も前に、パブリックネットワーク上で初期の攻撃トラフィックを捕捉したと公表した。公式パッチがスケジュール通りにリリースされたのは、日本時間10月21日23時（北京時間22時）のことであった。
つまり、脆弱性の詳細が流出してから最初の実戦攻撃が着弾するまでの16時間、防御側は何の対抗手段も持たない無防備な状態に置かれていたことになる。
単一ファイルのアップロードでサーバ制御権を奪取
この脆弱性は、Webにおけるもっとも基本的なインタラクションの深部に潜んでいた。ユーザーがアバターアイコンを変更したり、添付ファイルを送信したり、フォームからドキュメントを投稿する際、ブラウザはデータを multipart/form-data 形式で束ね、バックエンドの処理系へと渡す。
問題が発生したのは、PHPがこのリクエストデータを解析するコアルーチンである。攻撃者が細工した不正なパケットを送り込むと低レイヤのメモリ破壊が引き起こされ、ターゲットマシン上で任意のコマンドが実行可能になる。セキュリティ企業Sansecの解説は極めて直截的だ。攻撃者に必要なのは単一のPOSTリクエストだけであり、ログイン認証も前提条件も一切不要とされる。
決定的なのは脆弱性が発火するタイミングである。欠陥はアプリケーション層のビジネスロジックが実行される前に発生するため、WordPressやWooCommerce、Magentoといったフレームワークがどれほど堅牢なセキュリティ対策を講じていようと関係がない。世界のWebサイトの約4割を占めるWordPressをはじめ、バックエンドでPHPのファイルアップロード機能が有効化されているサーバはすべて射程圏内に入ってしまう。
図：2件の深刻なリモートコード実行脆弱性について解説したTenableの公式FAQ。出典：Tenable
メンテナンス画面への切り替えでは防げない
サイトに緊急事態が発生した際、管理者は一時的にメンテナンスモードへ移行し、訪問者向けに工事中案内を表示してアクセスを遮断するのが常套手段である。だが今回の事態において、メンテナンス表示は何の盾にもならない。メンテナンス画面自体がPHPアプリケーションによって生成されるため、悪意あるリクエストはWebアプリの制御に届くより前、インタープリタのパーサ段階で脆弱性を直撃するからだ。PHPの実行プロセスが動作している限り、攻撃は成立してしまう。
パッチを入手するまでのあいだ被害を免れるには、実務上の痛手を覚悟するしかない。選択肢は限られていた。NginxやApacheなどのフロントエンド層でファイルアップロードのリクエストを一律遮断する方法があるが、ユーザーのアバター変更やショップの商品登録などアップロードを伴う全機能が停止する。あるいはオリジンサーバのファイアウォールをCloudflareのエグレスIPのみに絞ってWAFの通過を強制する手段もあるが、もしオリジンの実IPが一度でも漏れていれば直接狙われて無力化される。究極の回避策はPHPサービス自体を停止し、静的HTMLページに切り替えて凌ぐことだ。
また、php.ini 設定で攻撃経路を狭める暫定手段として、session.upload_progress.enabled の無効化と session.use_strict_mode の有効化が挙げられた。ただしPHPリリースマネージャーは、これらはリスクを限定的に下げる緩和策に過ぎず、PHPインタープリタ自体のアップデートの代わりにはならないと念を押している。
パッチ公開の数時間前、オランダ議会や同国国家サイバーセキュリティセンター（NCSC-NL）、テック系メディアのTweakersは、Webサイトを完全にオフライン化するというもっとも厳しい対応を選択した。Cloudflareの最高技術責任者（CTO）Dane Knecht氏が語ったように、WAFルールは一時的な止血帯に過ぎない。
サポート終了した数百万台の旧環境にはパッチが届かない
もしバージョン更新だけで解決できる問題なら、これほどの混乱には至らなかっただろう。セキュリティ研究者のSilas Cutler氏の試算によると、公衆インターネットから直接到達可能なPHPインスタンスは約130万台に達し、これらは自動スキャンツールの格好の標的となっている。
最大の問題は、そのうちかなりの割合が公式の修正パッチを永遠に受け取れないという点にある。PHPプロジェクトの公式サポート対象は現行メンテナンス中のブランチに限られ、今回のパッチが提供されたのはバージョン8.2以降のみである。5.x系、7.x系、8.0、8.1といった過去のブランチはすでにサポート終了（EOL）を迎えているにもかかわらず、企業の基幹システムや長年放置されたコンテナイメージの中で今なお膨大な数が稼働し続けている。
上流のWebアプリケーション側は迅速に対応した。WordPressは7.1.3、Drupalは11.4.10、Laravelは13.36.0をリリースし、MediaWiki、phpBB、Magento、Symfonyも同日中に改修バージョンを投入した。しかし、土台となるPHPインタープリタそのものを入れ替えない限り、上位層での防御策は根本的な解決にならない。
エンタープライズLinux環境でも足並みの乱れが生じた。広く使われているサードパーティ製リポジトリ「Remi’s RPM repository」は当日中のビルド提供を見送ると発表。RHEL系ディストリビューションのユーザーは、OS公式のバックポートを待つか、本番環境で直接ソースコードをコンパイルするかの二者択一を迫られた。
図：誕生から30年にわたりWebサイトの4割を支えるPHP。そのリクエスト解析基盤に重大な脆弱性が露見した。出典：BleepingComputer
配信能力が新たなセキュリティ境界線となる
オープンソースエコシステムのセキュリティは、「各関係者が足並みを揃え、適時にパッチを配給し、運用者が整然と更新する」という理想的な信頼関係の上に成り立ってきた。PHP2Shellはその均衡を根底から打ち砕いた。
Sansecやオランダのセキュリティ機関はパッチ公開前から警告を発していた。修正ソースコードが公開されれば、攻撃者は15分以内にリバースエンジニアリングを完了して全網スキャンを開始するだろう、と。しかし現実はさらに過酷だった。詳細情報の流出により、最初の波は公式パッチの登場より6時間も早く押し寄せたのである。
一方で、ソフトウェア配給の現実はあまりに鈍重だ。開発元がコードを公開してから、OSディストリビューションがパッケージ化と検証を行い、各企業が深夜のメンテナンス時間を確保して適用するまでに数日から数週間かかるのは日常茶飯事である。さらにEOLを迎えた旧ブランチには、修正コードそのものが提供されない。
防御側と攻撃者の決定的な差は、もはや「パッチを書く能力」ではなく、「そのパッチを稼働中のすべてのマシンへ届ける物流能力」にある。バージョンの断絶と運用現場の更新停滞が解消されない限り、どれほど素早くパッチを開発しても、攻撃者の第一波の後追いを続けることしかできない。
参考リンク：
- PHP 公式セキュリティアップデート告知
- Sansec 技術解析レポート
- Tenable 脆弱性FAQ
- watchTowr 脆弱性調査報告
- Cloudflare 脅威動向速報
