PHP2Shell: 設定変更による対策が失敗する理由と、パッチ適用前のリスク軽減策

PHPプロジェクトは、2026年10月21日UTC 14:00に、PHP2Shellとして総称される2件の重大なリモートコード実行脆弱性に対応する緊急セキュリティパッチをリリースする予定です。これらの脆弱性の深刻度評価は10段階で9.2とされ、セキュリティ企業やコア開発者から、現在の非公式な回避策の不備について緊急の警告が出ています。公式の修正版が利用可能になるまで、専門家らは設定変更への依存ではなく、公開ネットワークから露出したPHPインスタンスを隔離することを助言しています。

何が起きたか

セキュリティ研究者は、攻撃者が影響を受けるサーバー上で任意のコードを実行できる、PHPにおける2件の重大な脆弱性を特定しました。PHP財団はまだ、具体的にどのバージョンが影響を受けるのか、またどの内部コンポーネントにバグが含まれているかを公表しておらず、詳細情報はリリースと同時に提供されると述べています。Cloudflareは、これらの脆弱性を狙った初期の悪用試行を観察したと報告しており、ユーザー向けの暫定的な応急処置として緊急ファイアウォールルールを展開しました。こうした観察にもかかわらず、成功した侵害事例は確認されておらず、現時点ではCISAの既知の悪用済み脆弱性カタログにも記載されていません。

session.upload_progress.enabledという設定項目を用いた潜在的な緩和策に関して、大きな混乱が生じました。東京に拠点を置くGMO Flatt Securityは当初、この機能を無効化することでリスクを低減できる可能性があると示唆していました。しかし同社は後にこの助言を撤回し、この設定だけでは完全な保護を提供できず、攻撃者はこれをバイパスできる可能性が高いと明確にしました。この方針転換はPHPコア開発者によって支持されており、適切なソフトウェアパッチの代わりとなるような設定変更は存在しないことが強調されました。

仕組み

緩和策をめぐる議論は、ファイルアップロードのステータスを追跡するPHPのデフォルト機能である「Session Upload Progress」を中心に展開されています。一部の研究者が提唱した理論では、脆弱性はメカニズム内に存在するというものでした。session.upload_progress.enabled=0を通じてこれを無効化すれば、攻撃面を除去できると考えられていました。しかし、独立した監査やPHPメンテナーからの声明によれば、欠陥はこの特定の機能には存在しない可能性があり、実際の脆弱性のベクトルに対して設定変更は無効であることが示唆されています。

PHPコア開発者のGina Peter Banyard氏は、「ini設定では救われない」と明確に述べました。専門家間の合意では、脆弱性はおそらくPHPがマルチパートフォームデータを処理する方法に関与していると考えられますが、パッチ適用後にソースコードを確認するまでは、正確なエントリーポイントは未確認のままです。根本原因がセッションアップロードに確定的に関連付けられていないため、関連設定の切り替えは誤った安心感を与えるだけで、基盤となる実行経路は悪用の余地を残すことになります。

主要な詳細

• パッチリリース時刻: 公式修正版は2026年10月21日UTC 14:00に到着します。
• 深刻度評価: リモートコード実行の可能性により、両方の脆弱性は10段階で9.2と評価されています。
• 効果のないワークアラウンド: session.upload_progress.enabled=0の設定は信頼できる緩和策ではなく、修正として扱われるべきではありません。
• サポート対象ブランチ: PHPバージョン8.2から8.5向けにパッチが発行されます。7.xや8.1などの古いバージョンはサポート終了（EOL）です。
• 悪用状況: 初期の悪用試行は確認されていますが、公開された概念実証（PoC）コードがリリース済みのPHPバージョンで動作することが検証されているわけではありません。
• Cloudflareの対応: 緊急WAFルールが暫定措置として展開されましたが、これらは同社のネットワークを通過するトラフィックのみを保護します。

なぜ重要なのか

PHPインフラストラクチャを管理するエンジニアリングチームにとって、この事件はゼロデイ事象の際に未検証のコミュニティアドバイスに依存することの危険性を浮き彫りにしています。多くの管理者は、セッションアップロードの設定変更が即時の安全性を提供すると信じ、慌てて適用しました。この反応は、迅速な修正よりも隔離と検証を優先する、規律あるインシデント対応プロトコルの必要性を強調しています。仮定した攻撃ベクトルが誤っている場合、誤った緩和策の適用は貴重な時間を無駄にし、システムを脆弱なまま放置することになりかねません。

さらに、この状況はサポート終了（EOL）ソフトウェアバージョンに関連するリスクを露呈しています。PHPはブランチ8.2から8.5のみをサポートしているため、8.1や7.xなどの古いバージョンを実行している組織には公式パッチが届きません。これらのチームはLinuxディストリビューションのバックポートやサードパーティプロバイダーに頼らざるを得ず、遅延と不確実性が生じます。サポート外のバージョンを即座にパッチできないことは、サービスをオフラインにするか、露出を防ぐための複雑なネットワーク隔離措置を実施するかという難しい決断を強いることになります。

あなたができること

• パッチ適用の準備: 10月21日UTC 14:00以降に修正を即座に展開できるよう、更新手順を今すぐ確認してください。
• 公開アクセスの隔離: 即時のパッチ適用が不可能な場合、PHPアプリケーションをVPNの背後に配置するか、許可リストに登録されたIPアドレスからのみアクセスを制限してください。
• 設定コンテキストの検証: セッションアップロード進捗を無効にした場合は、その変更がWebサービングプロセス（FPMまたはmod_php）に適用されていることを確認してください。コマンドラインインターフェースだけでなく、こちらが重要です。
• パッケージ変更ログの確認: 修正をバックポートするLinuxディストリビューションの場合、バージョン番号だけに頼るのではなく、具体的なCVEに対するパッケージ変更ログを確認してください。
• サーバー権限の制限: サーバーに保存されるデータを削減し、不要な認証情報を削除し、ログが安全な別箇所に送信されるようにしてください。
• トラフィックの監視: 異常なマルチパートフォームデータのリクエストに注意してください。ただし、それらをブロックすると正当なファイルアップロード機能が破綻する可能性があることを認識してください。