PHP2Shell のこの2つの番号（CVE‑2026‑109618、CVE‑2026‑109619）は緊急事態として扱う必要があります。攻撃者はアカウントもパスワードも必要とせず、公開されているサービスにアクセスできさえすれば、あなたのサーバー上で直接コマンドを実行できる可能性があります。対応の順序としては、まず自分が影響範囲に入っているかを確認し、次にパッチを適用するか一時的な緩和策を先に講じるかを決め、最後に必ず検証とログの再確認を行うことを推奨します。以下、実行可能な順序で分解して説明します。
ステップ1：30分以内に自分が本当に影響を受けているか判断する
いきなり全サイトを停止するのではなく、まず3つのことを行って露出面を特定します。
1. バージョンを確認する。サーバーにログインして `php -v` を実行し、コンテナイメージの tag、`composer.lock`、パネルで切り替えている PHP バージョンを確認します。多くの企業サイトは古い 7.x で動作しており、運用担当者はアップグレード済みだと思っていても、実際には別の環境が動作していることがあります。
2. 露出面を確認する。外部からの視点でスキャンします。どのドメイン/IP の 80、443、8080 が直接インターネットに公開されているか、テスト環境、旧版の管理画面、一時的に公開したまま忘れているインターフェースがないかを確認します。内部ネットワークからアクセスできることは安全を意味しません。横展開はしばしばここから始まります。
3. トリガーパスを確認する。公式公告で示されている影響を受けるコンポーネントとエントリーポイントを照らし合わせ、あなたのルーティング、アップロードインターフェース、デシリアライズのエントリーポイント、テンプレートレンダリング箇所が該当するかを確認します。判断できない場合は「影響を受ける」として処理する方がコストが低くなります。
結果を表にまとめます：ドメイン、PHP バージョン、インターネット公開かどうか、影響を受けるコンポーネントを含むか、担当者。この表は後の検証と振り返りで使用します。
ステップ2：パッチを適用できるならパッチを適用し、「設定変更」でアップグレードを代替しない
パッチは唯一の根本的な解決手段であり、一時的な緩和は時間を稼ぐにすぎません。
- まずステージング環境で検証する。本番環境で直接アップグレードするのはリスクが高く、特に長年運用している企業サイトでは拡張機能とフレームワークのバージョンが互いに絡み合っています。ステージング環境でコアとなるフロー（ログイン、注文/フォーム送信、決済コールバック、ファイルアップロード）を一通り実行します。
- 依存関係の順序に従ってアップグレードする。まずランタイムをアップグレードし、次にフレームワークとサードパーティライブラリをアップグレードし、最後にビジネスコード内の非推奨となった呼び出しを処理します。アップグレード後に `composer update` を実行したら、ロックファイルを再生成してコミットする必要があります。
- ロールバック経路を確保する。アップグレード前にスナップショットを取得するか旧イメージ tag を残し、ロールバックコマンドを明記します。ロールバック計画のないアップグレードは、本質的に賭けです。
- 注意点：1台のマシンだけをアップグレードして完了と宣言しないでください。ロードバランサーの背後にはまだ手を付けていないマシンが数台あることが多く、攻撃者は漏れたその1台を狙います。
ビジネスが外注でソースコードが入手できない場合は、まず元の開発元にバージョン情報とパッチ計画を問い合わせてください。入手できない場合は、次のセクションの一時的な対策で先に持ちこたえます。
ステップ3：パッチを適用できない場合の一時的な緩和策、優先度順に実施
緩和策は「悪用される確率を下げる」ものであり、「修正完了」ではありません。必ずスケジュール表に記載し、期限を定めてアップグレードする必要があります。
1. 露出面を縮小する：管理画面、デバッグインターフェース、テスト環境をインターネットから外し、内部ネットワークアクセスまたは IP ホワイトリストに変更します。この項目は効果が最も大きく、コストが最も低くなります。
2. 前段での遮断：WAF または Nginx 層で公告に示された特徴に対するルール遮断を行い、同時にアップロードディレクトリの実行権限を制限します（`php_flag engine off` または同等の設定）。
3. 権限を下げて実行する：Web プロセスを root で実行しないようにし、ファイルディレクトリの書き込み権限のうち不要な部分を削除し、`disable_functions` で無効化できる危険な関数を無効化します。
4. 監視を追加する：異常な子プロセス、外部への接続、アップロードディレクトリ内に新たに出現した実行可能ファイルに対してアラートを設定します。
注意点：WAF ルールを追加するだけでコードを変更しないのは、運命をルールライブラリに委ねるのと同じです。攻撃者がエンコード方法を変えるだけでバイパスできる可能性があるため、緩和期間中は毎日1回遮断ログを確認する必要があります。
ステップ4：修正後は必ず検証する、そうでなければ修正していないのと同じ
多くのチームはパッチを適用したら終わりにしてしまい、その結果古いプロセスがまだ動作しています。
- PHP-FPM と Web サービスを再起動し、`php -v` がすべてのノードで新バージョンになっていることを確認します。
- 外部スキャンツールで元のトリガーパスを再テストし、戻り値がもはや悪用可能な状態でないことを確認します。
- ログを再確認します：脆弱性が公開されてから修正されるまでの時間枠内に、異常な POST、不審なアップロード、異常な外部接続がなかったかを確認します。あればインシデントとして処理する必要があり、単にパッチを適用するだけでは不十分です。
- 定期タスク、SSH 公開鍵、新規アカウントを確認し、バックドアが仕掛けられていないことを確認します。
具体的なシナリオの例：ある企業の公式サイトのリニューアル期間中に、デザイナー用にファイルアップロードインターフェースを一時的に開設し、閉じ忘れたまま、たまたま影響を受けるバージョンで動作していた。このような「一時的なインターフェース」は被害が集中する箇所であり、リニューアル完了時には「一時エントリのクリーンアップリスト」を用意すべきです。
MIC Studio に相談すべきケース
以下のような状況であれば、自力で対応するコストパフォーマンスは高くありません：
- ソースコードが外注先にあり、バージョン情報が明確でなく、パッチ計画を立てられない；
- サイトが多く環境が複雑で、どれがインターネット公開でどれが影響範囲内かを区別できない；
- パッチ適用後に追加のセキュリティテストとリバーステストを実施し、残留エントリやバックドアがないことを確認したい；
- ついでに古いシステムをリファクタリングし、Web サイト開発、ミニプログラム開発、App 開発の技術スタックを保守可能なバージョンに統一したい。
MIC Studio は企業サイト、ミニプログラム、App、スクリプト開発を行い、Web サイトのセキュリティテストとリバーステストも行っています。「まず止血、次に検証、最後にリファクタリング」の順序で連携できます。すべての問題を外注する必要はなく、自分でパッチを適用できる場合は、まずパッチを適用し終えることがより重要です。
まとめ：今日からできる3つのこと
1. 今日リストを作成する：インターネットからアクセス可能なすべての PHP 環境をリストアップし、バージョンと担当者を記載する。記憶に頼らないこと。
2. 48時間以内にアップグレードまたは緩和を完了する：アップグレードできるならアップグレードし、できないなら露出面を外して遮断を追加し、期限を明記する。
3. 証拠を残す：アップグレード前後にそれぞれログをバックアップし、修正後に時間枠内の異常リクエストを再確認し、侵害されていないことを確認する。
よくある質問
内部ネットワークでのみ使用している場合でも修正が必要ですか？
必要です。内部ネットワークは隔離帯ではありません。従業員の端末、テスト機、サードパーティの接続が踏み台になる可能性があります。インターネットに公開されているものを優先的に修正し、内部ネットワークのものは同じメンテナンスウィンドウ内で一緒に処理します。
WAF ルールを追加すれば、しばらくアップグレードしなくてもよいですか？
あくまで過渡的な措置です。ルールは特徴マッチングに依存しており、バイパスのコストは高くなく、ルールの保守自体に人的監視が必要です。WAF は止血帯、アップグレードは手術であり、両者は互いに代替できません。