専門家でなくてもAIに相談しながら自分たちで実行できる対策
公開日：2026年10月22日｜カテゴリ：セキュリティ・PHP・AI活用
2026年10月21日深夜、PHPに緊急のセキュリティリリースが出ました。通称「PHP2Shell」。認証なしで外部からサーバー上の任意のコードを実行される恐れがある、深刻度9.2（CVSS v4.0）の脆弱性が2件です。WordPressをはじめ、PHPで動く多くのWebサイトが影響を受けます。
この件で注目すべきなのは、発見の経緯です。報告によれば、研究者が一般公開されているAIモデルとの対話を重ねて攻撃経路にたどり着いたとされています。AIは、脆弱性を見つける側の道具にもなったということです。そして同じ道具は、守る側も使えます。
本記事では、PHP2Shellの事実関係を整理したうえで、PHPサイトに潜む代表的な脆弱性と、専門家でなくてもAIに相談しながら自分たちで実行できる対策を、行動経済学・認知科学の視点から具体的に解説します。
今すぐ確認してください（2026年10月22日時点）
修正版は PHP 8.5.12／8.4.27／8.3.36／8.2.35 です。これより古いバージョンは更新が必要です。PHP 8.1以前はすでにサポートが終了しており、公式の修正版は出ません。
公式発表では「完全な回避策はなく、更新が唯一の安全な選択肢」とされています。レンタルサーバーを使っている場合は、事業者のお知らせとPHPバージョンの切り替え画面を確認してください。
第1章 PHP2Shellで何が起きたのか
2件の脆弱性は、どちらもPHPがリクエストを処理する際のメモリ管理の不備に起因します。1件目（CVE-2026-109618）は、メモリ不足で処理が中断したときに、中途半端な状態のデータを正しいものとして扱ってしまう問題です。2件目（CVE-2026-109619）は、前のリクエストで使い終わったはずの内部データが残り、次のリクエストで誤って使われる問題です。
影響を受ける実行方式は、PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedです。特にアプリケーションのコードが動く前に攻撃が成立し得る点が深刻で、WordPressのプラグインやアプリ側の対策では防げません。
【図1】PHP2Shell 発見から修正版公開までの流れ
| 2026年8月1日 | 研究者がAIとの対話を重ね、最初の攻撃経路を発見 |
| 8月11日 | PHP開発チームへ報告（別の組織も同日に独立して報告） |
| 10月20日 | PHPが緊急リリースを予告。直後にCVE番号がネットに流出し、公開を1日前倒し |
| 10月21日 夜 | 修正版（8.5.12／8.4.27／8.3.36／8.2.35）を公開 |
なお、SNSでは「公開から15分でAIが攻撃コードを作り、サイトが乗っ取られる」といった情報も拡散されました。これは、海外のセキュリティ企業が出した「公開後すぐに大規模な攻撃が始まる恐れがある」という警告が、具体的な数字として独り歩きしたものと分析されています。危機が起きたときほど、一次情報（php.net、IPAなど）を確認する習慣が大切です。
第2章 なぜ対策は後回しにされるのか——3つの脳のクセ
PHPの更新が必要なことは、多くの担当者が知っています。それでも古いバージョンのまま動き続けるサイトが後を絶ちません。原因は知識不足ではなく、人間の判断のクセにあります。
| 脳のクセ | 現場でよく聞く言葉 | 実際には |
| 楽観性バイアス | 「うちみたいな小さな会社は狙われない」 | 攻撃は自動化されており、規模に関係なくネット上の全サイトが機械的に試される |
| 現在バイアス | 「表示が崩れたら困るから、落ち着いたら更新しよう」 | 更新の手間は今すぐ発生し、被害は将来の話なので、人は今の手間を過大に感じる |
| 関心の減衰 | ニュースの直後だけ大騒ぎし、1か月後には忘れる | 脆弱性は毎月のように見つかる。必要なのは一度の対応ではなく、仕組み化 |
これらのクセに意志の力で対抗するのは困難です。成功している組織は、判断に頼らなくても対策が回る仕組みを作っています。その具体的な方法を、ここから順に紹介します。
第3章 まずは「バージョン」を知る——サポート切れが最大のリスク
PHPの各バージョンには、セキュリティ修正が提供される期限があります。期限を過ぎたバージョンは、今回のような深刻な脆弱性が見つかっても公式の修正版が出ません。
【図2】PHPバージョン別のサポート状況（2026年10月時点）
| 8.1以前 |
サポート終了。公式の修正版なし。至急移行
|
| 8.2 |
2026年12月31日でサポート終了。年内に移行計画を
|
| 8.3 |
セキュリティ修正のみ提供中（2027年末まで）
|
| 8.4／8.5 |
サポート中。新規構築・移行先の推奨
|
自社サーバーなら、次のコマンドでバージョンと関連設定を確認できます。ただし、コマンドライン用とWeb用（PHP-FPMなど）で設定ファイルが別のことがあるため、Web側の値はサーバー管理画面やホスティング事業者の情報でも確認してください。
php -v
php -i | grep -E "session.upload_progress.enabled|memory_limit|post_max_size"第4章 PHPアプリに潜む代表的な脆弱性
PHP2ShellはPHP本体の問題でしたが、日常的な被害の多くは自社で書いたコードやプラグインの書き方に原因があります。代表的なものを、危ない書き方と安全な書き方で比較します。
【図3】PHPでよくある脆弱性と安全な書き方
| 脆弱性 | 危ない書き方 | 安全な書き方 |
| SQLインジェクション | 入力値を文字列連結してSQLを組み立てる | PDOのプリペアドステートメントで値を渡す |
| XSS | 入力値をそのまま echo で画面に出す | 出力時に htmlspecialchars でエスケープ |
| ファイルアップロード | 拡張子だけ確認し、公開フォルダに保存 | 中身の形式も確認し、公開フォルダ外に別名で保存 |
| ファイル読み込み | URLのパラメータで include するファイルを指定 | 許可したファイル名の一覧からのみ選ぶ |
| オブジェクト注入 | 外部からのデータを unserialize する | json_decode を使う |
| パスワード保存 | md5 や sha1 でハッシュ化 | password_hash と password_verify を使う |
| 型の比較ミス | 認証トークンを == で比較 | hash_equals や === で厳密に比較 |
SQLインジェクション対策の例を示します。「値を後から別に渡す」のがポイントです。
// 危ない：入力値がSQL文の一部になる
$sql = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";
// 安全：SQL文と値を分けて渡す
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$_POST['email']]);第5章 AIをセキュリティ相談役にする具体的な方法
専門のセキュリティ担当者がいない会社でも、AIを相談役にすれば、できることは大きく広がります。ただし、AIに丸投げするのではなく、「点検の観点」と「手順」を出してもらい、実行と判断は人が行うのが原則です。
使い方1：自社環境に合わせた対応手順を作ってもらう
一般的なニュース記事は、すべての環境向けに書かれています。AIに自社の構成を伝えれば、やるべきことを絞り込めます。
「当社のWebサイトは、レンタルサーバー上のWordPressで、PHPは8.2.29です。PHP2Shell（CVE-2026-109618／109619）について、php.netの公式発表をもとに、①影響を受けるか、②今日やるべきこと、③作業の順番と所要時間の目安を、専門用語を避けて教えてください。わからない点は推測せず『確認が必要』と書いてください。」
使い方2：自社コードの危険箇所を洗い出してもらう
Claude CodeのようなAIコーディングツールを使えば、ソースコード一式を読み込ませて、図3のような脆弱性の候補を一覧にしてもらえます。最初は「修正はしないで」と指示し、報告だけを出させるのがコツです。
claude "このリポジトリのPHPコードから、SQLインジェクション、XSS、
ファイルアップロード、include、unserialize、パスワード保存に関する
危険な箇所を探して、ファイル名・行番号・危険な理由・修正案を
表にまとめて。修正はまだしないで。確信がないものは『要確認』として。"使い方3：ツールの結果を読み解いてもらう
Composerを使っているなら composer audit で、利用しているライブラリの既知の脆弱性を確認できます。WordPressならWPScanのような専用ツールがあります。こうしたツールの英語の出力結果をAIに貼り付け、「影響の大きい順に並べて、それぞれの対応方法を教えて」と頼むと、優先順位が明確になります。
AIに相談するときの3つの注意
① 秘密情報は渡さない：.envファイル、データベースのパスワード、APIキーなどはAIに貼り付けないでください。
② AIは見落とす：AIの「問題なし」は安全の証明ではありません。人間の点検とツールによる自動チェックを組み合わせます。
③ 情報の鮮度に注意：AIの知識には期限があります。バージョン番号や期限は、必ず公式サイトで確認してください。
第6章 「穴の重なり」を防ぐ多層防御
心理学者ジェームズ・リーズンは、事故は1つのミスではなく、複数の防護壁の穴がたまたま一直線に並んだときに起きると説明しました（スイスチーズモデル）。どの対策にも穴はあります。だからこそ、層を重ねることが重要です。
【図4】自分たちでできる多層防御
| 層1 PHP本体 | サポート中のバージョンを使い、修正版を速やかに適用する |
| 層2 設定 | エラー表示を本番でオフにする。不要な機能を無効にする |
| 層3 アプリ・プラグイン | 図3の安全な書き方。使っていないプラグインは削除する |
| 層4 入口の防御 | WAFの有効化（ただしWAFだけに頼らない）、管理画面へのアクセス制限 |
| 層5 事後の備え | バックアップを別の場所に保管し、ログを保存する。復元手順を一度試しておく |
第7章 成功している組織の習慣——「もし〜なら、〜する」
外科医アトゥール・ガワンデは、手術の安全チェックリストを導入することで重大な合併症が大きく減ったことを報告しました。熟練者ほど「自分は忘れない」と考えがちですが、確実な組織はチェックリストに頼るのです。
さらに効果的なのが、心理学者ゴルヴィツァーが提唱した実行意図（if-thenプランニング）です。「気をつける」ではなく、「もし○○が起きたら、△△をする」と事前に決めておくと、実行率が高まることがわかっています。セキュリティに当てはめると次のようになります。
● もしPHPやWordPressの緊急リリースが出たら、その日のうちに担当者がバージョンを確認し、責任者に報告する
● もし毎月第1月曜日になったら、プラグインとライブラリの更新状況を確認し、composer audit を実行する
● もし更新でサイトに不具合が出たら、バックアップから戻し、AIにエラーメッセージを見せて原因を相談する
● もしサポート期限の6か月前になったら、新バージョンへの移行テストを始める
まとめ 今日・今週・今月やること
【図5】実行チェックリスト
| 今日 | □ 全サイトのPHPバージョンを確認し、修正版に更新する □ 8.1以前のサイトは、移行するまで公開停止やアクセス制限を検討する |
| 今週 | □ 管理しているサイト・サーバーの一覧表を作る（担当者・PHPバージョン・更新日） □ AIに自社コードの危険箇所を洗い出してもらう □ 不審なファイルの追加やログの異常がないか確認する |
| 今月 | □ PHP 8.2のサイトは、年末のサポート終了までに8.4以降へ移行する計画を立てる □ 第7章の「もし〜なら」ルールを社内で決めて共有する □ バックアップからの復元を一度試す |
AIが脆弱性を見つける時代には、攻撃の準備にかかる時間も短くなっていきます。だからこそ、守る側もAIを使い、「知っている」を「仕組みで回っている」に変えることが、これからのWebサイト運営に欠かせません。
【参考・出典】PHP公式サイト（php.net）2026年10月21日セキュリティリリース／IPA「PHPのセキュリティリリース公開予定について」（2026年10月21日）／GMO Flatt Security Blog「php2shell」／yamory Blog／innovatopia／ITmedia オルタナティブ・ブログ
※本記事は2026年10月22日時点の公開情報に基づきます。脆弱性の詳細や攻撃状況は今後更新される可能性があるため、最新情報は公式発表をご確認ください。被害が疑われる場合は、サーバーを隔離してログを保全し、専門家に相談してください。
タグ：PHP, 脆弱性, PHP2Shell, セキュリティ対策, WordPress, AI活用, Claude Code, 行動経済学, 認知科学
