PHP2Shell (CVE-2026-109618 / 109619) とは - 影響範囲・確認方法・今すぐやるべき対処
2026年10月21日、PHPに認証なしでコードを実行される重大な脆弱性が2件公表されました。通称 PHP2Shell、識別番号は CVE-2026-109618 と CVE-2026-109619 です。CVSS v4.0 でいずれも 9.2、最上位の「緊急」に分類されています。
影響範囲は PHP 5.4 から 8.5.11 まで。つまり、ほぼすべての現役サーバが対象です。この記事では、何が起きたのか、自分のサイトが該当するか、何をすればよいのかを、実務の手順に落として解説します。
- サーバのPHPを 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 のいずれか以上へ更新する
- php.ini に
session.upload_progress.enabled = 0を追加する - WordPressのプラグイン更新では直りません。PHP本体の問題です
- PHP 8.1 以前は修正が提供されません。系列の移行が必要です
- 完全な緩和策は存在しません。更新が唯一の確実な対処です
何が起きたのか - 時系列で整理
今回の件は、情報の出方が通常と異なりました。順を追って整理します。
| 日付 | 出来事 |
|---|---|
| 10月20日 | PHPセキュリティチームが「翌日に緊急リリースを行う。重大な脆弱性が2件、いずれもCVSS 9.2」とだけ予告。影響バージョンも関数名もCVE番号も非公開 |
| 10月20日 | 詳細が非公式に流出。セキュリティ企業 watchTowr が CVE-2026-109618 の攻撃の再現に成功したと公表 |
| 10月21日 | PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開。アドバイザリで2件のCVEと内容を確定 |
| 10月21日 | JPCERT/CC と IPA が注意喚起を公表 |
| 10月23日 | 特定のセッション設定下で成立しうる別の脆弱性 CVE-2026-115560 を追加告知。暫定の緩和策のみ案内 |
修正の公開前に詳細が漏れたため、攻撃側が先に動ける状態が一定期間発生しました。実際の悪用も観測されています。「予告だけして詳細を伏せる」という進め方は、本来は防御側に準備時間を与えるためのものですが、今回は流出によってその前提が崩れました。
2つの脆弱性の中身
技術的な中身を、攻撃手順には踏み込まない範囲で説明します。どちらも「PHPが内部で持っているデータの状態が、想定外のタイミングで壊れる」という性質のものです。
CVE-2026-109618 - メモリ不足時の内部状態の破壊
PHPがリクエストを処理している途中でメモリが足りなくなると、処理が中断されます。このとき、リクエストの内部データが初期化し終わっていない状態で止まることがあります。
問題は、その後の後片付け処理です。後片付けは「データは正常に作られている」という前提で動くため、中途半端な状態のデータを正常なものとして扱ってしまいます。この食い違いを突くと、攻撃者が任意のコードを実行できます。
メモリ不足は、攻撃者が大きなデータを送りつければ意図的に起こせます。つまり、特別な権限は必要ありません。
CVE-2026-109619 - 解放済みの状態が次のリクエストに残る
PHPはリクエストごとに内部の作業領域を確保し、終わったら解放します。ところが、リクエストが持っていた内部状態の一部が、その領域が解放された後も参照可能なまま残ってしまうケースがありました。
サーバは効率のため、同じワーカープロセスで次々とリクエストを処理します。そのため、次のリクエストが、初期化される前に前のリクエストの残骸を参照してしまいます。ここを突くと、やはり任意のコードの実行につながります。
PHP公式は、この脆弱性がファイルアップロードの進捗記録の機能と関係していることを確認しています。後述する緩和策は、この経路を塞ぐものです。
CVE-2026-115560 - まだ修正版がない3件目
10月23日に追加で告知されたものです。セッションのシリアライズ方式を実行時に変更し、かつアップロード進捗の記録が有効な場合に限り、リモートコード実行につながる可能性があります。
既定の設定では成立しません。また、PHP2Shellの修正を適用済みのバージョンでも条件を満たせば該当します。本記事執筆時点で修正版は提供されておらず、暫定の緩和策のみが案内されています。
影響を受けるバージョンと修正版
| 系列 | 状態 | 影響を受けるバージョン | 修正版 |
|---|---|---|---|
| PHP 8.5 | サポート中 | 8.5.12 より前 | 8.5.12 |
| PHP 8.4 | サポート中 | 8.4.27 より前 | 8.4.27 |
| PHP 8.3 | サポート中 | 8.3.36 より前 | 8.3.36 |
| PHP 8.2 | セキュリティ修正のみ | 8.2.35 より前 | 8.2.35 |
| PHP 8.1 以前 | サポート終了 | すべて | 提供されません |
公式の修正は提供されません。今後新しい脆弱性が見つかっても、永久に直らない状態が続きます。8.3 系以上への移行が必要です。移行前に、使用中のテーマとプラグインの対応状況を確認し、必ずバックアップを取ってください。
なお PHP 8.2 も 2026年12月31日にセキュリティ修正が終了します。8.2 で止めている場合も、年内に移行の計画を立ててください。
自分のサイトが該当するか確認する
確認方法は3通りあります。確実な順に挙げます。
方法1: サーバの管理パネルで確認する (最も確実)
レンタルサーバをお使いなら、管理パネルに「PHPバージョン切替」の項目があります。そこに現在のバージョンが表示されます。これが最も確実です。契約しているサーバ会社によって名称は異なりますが、PHP設定やPHPバージョン管理といった項目にあります。
方法2: コマンドで確認する
SSHが使える環境なら、次のコマンドで一発です。
php -v出力の1行目にバージョンが出ます。ただし、SSHで使われるPHPと、Webサーバが使うPHPが別物である環境もあります。両方を確認したい場合は、公開ディレクトリに次の内容のファイルを一時的に置いて、ブラウザから開いてください。確認が終わったら必ず削除してください。
<?php echo PHP_VERSION;方法3: 外部から判定する
当サイトの PHPバージョン脆弱性チェック にURLを入れると、応答ヘッダから版数を読み取って判定します。バージョンを直接入力しての判定にも対応しています。
ただし、多くの本番サーバは版数を応答ヘッダから消しています。これは情報秘匿として正しい設定であり、その場合は外部から判定できません。「確認できず」と表示されたら、方法1か2で確認してください。
応答ヘッダから版数を消しても、脆弱性そのものは何も変わりません。攻撃者は版数が分からなければ、片端から試すだけです。隠すのは「攻撃の下調べを省いてあげない」ための措置であり、更新の代わりにはなりません。両方やってください。
対処の手順
手順1: PHPを更新する
レンタルサーバの場合は、管理パネルのPHPバージョン切替から変更します。VPSや専用サーバの場合は、OSのパッケージ管理から更新します。
切り替える前に、次の2点を済ませてください。
- サイト全体のバックアップを取る (ファイルとデータベースの両方)
- 使用中のテーマとプラグインが、切り替え先のPHPバージョンに対応しているか確認する
切り替えた後は、トップページだけでなく、問い合わせフォームの送信、画像のアップロード、会員機能など、動的な処理を一通り動かして確認してください。PHPのバージョンアップで壊れるのは、たいてい表示ではなく、こうした裏側の処理です。
手順2: アップロード進捗の記録を無効にする
CVE-2026-109619 の確認されている攻撃経路の1つを塞ぎます。あわせて CVE-2026-115560 の成立条件も満たさなくなるため、そのまま無効にしておいてください。
; php.ini または PHP-FPM のプール設定に追記
session.upload_progress.enabled = 0追記後、PHP-FPM または Apache を再起動してください。共有レンタルサーバの場合は、管理パネルのPHP設定画面から同じ項目を変更します。
この機能は、巨大なファイルをアップロードする際に進捗バーを表示するためのものです。無効にして困るサイトはほとんどありません。実際に使っている場合のみ、更新後に有効へ戻すか検討してください。
手順3: 更新後に再確認する
切り替えが反映されているかを、必ずもう一度確認してください。管理パネルで切り替えたつもりでも、ドメインごとに設定が分かれていて片方だけ古いまま、という事故はよくあります。
よくある誤解
誤解1: WordPressのプラグインを更新すれば直る
直りません。この脆弱性はPHP本体、つまりWordPress・テーマ・プラグインより下の層にあります。WordPress側では何をしても塞げません。対処はサーバのPHP更新のみです。
逆に言えば、プラグインの脆弱性とは別問題として、両方を並行して管理する必要があります。プラグインとテーマの既知脆弱性は WordPress脆弱性診断 で確認できます。
誤解2: セキュリティプラグインを入れているから大丈夫
WordPressのセキュリティプラグインは、WordPressが処理を始めた後の世界で動きます。今回の脆弱性はPHPがリクエストを受け取る段階の問題であり、プラグインの監視より手前で成立します。
WAF (Web Application Firewall) を導入していれば、攻撃パターンによっては防げる可能性があります。ただし、これも「塞いだ」のではなく「特定の形の攻撃を弾いている」状態に過ぎません。
誤解3: 小さいサイトだから狙われない
攻撃は、価値のあるサイトを選んで行われるのではありません。既知の脆弱性が残っているサーバを、機械的に探して行われます。規模も業種も条件になりません。
むしろ、小規模サイトは更新が放置されやすく、発見も遅れるため、踏み台として好まれます。被害に気づくのは、検索結果に警告が表示されたときや、サーバ会社から連絡が来たときです。
誤解4: 緩和策を入れたから更新しなくてよい
PHP公式は「完全な緩和策は存在せず、更新が唯一の安全な選択」と明言しています。session.upload_progress.enabled = 0 は、確認されている攻撃経路の1つを塞ぐだけで、脆弱性そのものを消すものではありません。
この機会にあわせて確認したいこと
PHPの更新で管理パネルを開いたついでに、点検しておくと効率が良い項目です。どれも5分以内で確認できます。
応答ヘッダに版数が出ていないか
Server ヘッダや X-Powered-By ヘッダに、サーバソフトやPHPの版数が含まれていると、攻撃対象を絞り込む材料になります。HTTPヘッダ取得ツール で確認できます。
# Apache の場合 (サーバ全体の設定)
ServerTokens Prod
ServerSignature Off
; php.ini の場合
expose_php = Offセキュリティヘッダが設定されているか
HSTS、CSP、X-Frame-Options といったヘッダは、攻撃の成立条件を狭めます。設定状況は サイトのセキュリティ設定チェック で一覧できます。
すでに改ざんされていないか
更新前に侵入されていた可能性を否定できない場合は、改ざんの有無も確認してください。改ざんされたサイトは、持ち主には通常のページを見せ、検索エンジンや検索から来た人にだけ別の内容を見せることがよくあります。自分で見ている限り気づけません。
サイト改ざんチェッカー は、トップページを通常のブラウザ、Googlebot、検索からの流入の3通りで読み込み、中身を比較します。
debug.log や設定ファイルの控えが露出していないか
WordPressの wp-content/debug.log や、wp-config.php.bak のような控えが公開ディレクトリに残っていると、内部構造や接続情報が丸ごと読まれます。これはPHPの脆弱性とは無関係に、単独で致命的です。
運用として定着させる
今回のような緊急対応は、起きてから動くと必ず後手に回ります。日常の運用に組み込んでおくべきことを挙げます。
- PHPのサポート期限を把握する。使っている系列の終了日をカレンダーに入れ、終了の半年前から移行を始めます
- 緊急時の連絡経路を決めておく。JPCERT/CC の注意喚起や、契約サーバ会社のお知らせを受け取る手段を確保します
- 管理サイトの一覧を持つ。どのサイトがどのサーバの、どのPHPバージョンで動いているかを一覧化しておくと、今回のような場面で確認が数分で終わります
- 定期的に外部から点検する。内部からは正常に見えていても、外から見ると問題が見えることがあります
よくある質問
更新したら表示が崩れました
PHPのバージョンアップで非推奨の書き方が動かなくなった可能性があります。まず元のバージョンへ戻して表示を回復させ、そのうえでテーマやプラグインの更新、または修正を行ってから再度切り替えてください。戻せるように、切り替え前のバックアップが重要です。
共有レンタルサーバで、サーバ会社が既に対応していると聞きました
サーバ会社がPHPの修正版を用意していても、各契約者がどのバージョンを選択しているかは別です。管理パネルで、自分の契約が修正版を使っているかを必ず確認してください。古い系列を選んだままなら、修正は適用されていません。
すでに侵入されているか、どうすれば分かりますか
外部からの点検で分かるのは「侵入されやすい状態か」と「改ざんの痕跡があるか」までです。実際に侵入されたかどうかは、サーバのアクセスログ、ファイルの更新日時、見覚えのないファイルの有無などを内部から調べる必要があります。心当たりがある場合は、専門の調査を検討してください。
PHP 8.2 を使っています。すぐ 8.3 に上げるべきですか
今回の対処としては、8.2.35 への更新で十分です。ただし PHP 8.2 は2026年12月31日にセキュリティ修正が終了します。年内に 8.3 系以上への移行を計画してください。期限直前に慌てて上げると、今回のような緊急対応と重なったときに身動きが取れなくなります。
まとめ
- PHP2Shell は PHP 本体の脆弱性で、5.4 から 8.5.11 までのすべてが対象です
- 修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。更新が唯一の確実な対処です
- あわせて
session.upload_progress.enabled = 0を設定してください - WordPressのプラグイン更新やセキュリティプラグインでは防げません
- PHP 8.1 以前は修正が提供されません。系列の移行が必要です
- 版数を隠すことは有効ですが、更新の代わりにはなりません
現在のPHPバージョンが影響を受けるかは、PHPバージョン脆弱性チェック で判定できます。バージョンを直接入力しての確認にも対応しているため、外部から版数が見えない環境でもお使いいただけます。
WordPressをお使いであれば、プラグインとテーマに残っている既知の脆弱性も、WordPress脆弱性診断 でCVE番号まで名指しで確認できます。公開されている脆弱性情報そのものは 脆弱性情報の一覧 で毎日更新しています。