「WordPressは最新にしているし、うちのブログは大丈夫」——そう思っていたら、少し注意が必要かもしれません。
2026年10月21日、Webサイトの裏側で動くプログラミング言語PHPに、深刻度「Critical」の脆弱性2件を修正する緊急アップデートが公開されました。条件がそろえば、ログインしていない第三者にサーバー上で不正なコードを実行される恐れがあります。
今回の問題は「PHP2Shell」とも呼ばれ、CVSS v4.0は両方とも9.2。WordPressだけでなく、PHPを利用するさまざまなWebサービスが関係します。
ただし、「PHPを使っているサイトは全部、今すぐ乗っ取られる」という意味ではありません。攻撃成立には条件があり、すでに修正版へ更新済みの環境もあります。何を恐れて、どこを確認すればいいのか。公式の発表をもとに、順番に整理します。
まず結論。今回のニュースで押さえておきたい4つのこと
- 問題はPHP本体にある：WordPressのテーマやプラグインだけの脆弱性ではありません。
- 認証不要でコード実行につながる可能性：攻撃が成功すると、Webサーバーの動作権限で不正な処理を実行される恐れがあります。
- 修正版はすでに公開：PHP 8.5.12／8.4.27／8.3.36／8.2.35が2026年10月21日に公開されました。
- 根本対策はPHPの更新：WAFや一時的な設定変更だけで完全に防げるものではありません。
今回の脆弱性は、CVE-2026-109618とCVE-2026-109619。PHP公式が、すべての利用者に速やかなアップデートを強く推奨しています。
いったい何が危ない？ 2つの脆弱性をかみ砕いて解説
PHPは、サイトへのアクセスを受け取って、データを処理し、画面を返す役割を担います。今回見つかったのは、そうした処理の途中で使うメモリの管理や、エラーが発生した後の後片付けに関する問題です。
① CVE-2026-109618：メモリ不足のとき、後片付けが壊れる
PHPがメモリ不足（OOM：Out Of Memory）に陥った際、リクエスト処理の内部データが中途半端に準備された状態で中断され、その後の終了処理が不正なデータを正しいものとして扱ってしまうことがあります。
イメージとしては、まだ組み立て途中の機械を、完成品として動かしてしまうようなもの。その結果、メモリが破損し、特定の条件下ではリモートからコードを実行される危険につながります。
② CVE-2026-109619：前のリクエストの「残り物」を使ってしまう
もう一つは、処理を終えたはずのリクエストが使っていたメモリへの参照が、PHP内部に残ってしまう問題です。同じワーカーが次のリクエストを処理するとき、そのすでに解放されたメモリを誤って使う恐れがあります。
専門的にはUse-After-Free（解放済みメモリの使用）と呼ばれる問題の一種です。攻撃が成立すると、メモリ内の情報が漏れたり、任意のコードを実行されたりする可能性があります。
どちらも、サイトの見た目の問題ではなく、アプリのさらに下にあるPHPの実行環境自体の問題という点が厄介です。
WordPressにも影響する？ PHP-FPMなら安全？
WordPressはPHPで作られています。このため、脆弱なPHP上で動くWordPressサイトは対策が必要です。ただし、「WordPressそのものに今回の欠陥がある」という話ではありません。
PHP公式は、PHP-FPM、Apacheのモジュールとして動くmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境全般を対象として挙げています。
特に注意が必要とされているのがApacheのmod_php構成。アプリケーション側の処理が実行される前に、認証なしのリクエストから問題を引き起こせることが実証されています。PHP-FPMについても攻撃の成立が確認されており、「mod_phpではないから大丈夫」とは言えません。
一方で、攻撃の難しさや成立条件は構成によって異なります。「対象に含まれる」ことと「どのサイトでも即座に攻撃できる」ことは、区別する必要があります。
修正済みのPHPバージョン一覧
2026年10月22日時点で、PHPプロジェクトが今回の問題を修正したと案内しているバージョンは以下の通りです。
| 利用中の系列 | 今回の修正版 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1以前 | PHPプロジェクトの通常のセキュリティサポート対象外。サポート中の系列への移行、またはOS・保守ベンダーの修正提供状況を確認 |
古いPHPを使うLinuxディストリビューションや商用保守環境では、同じバージョン番号のまま修正がバックポートされる場合もあります。自社運用のサーバーなら、PHPの表示バージョンだけでなく、導入元ベンダーのセキュリティ情報も確認しましょう。
また、PHP 8.2は2026年12月31日に公式サポート終了予定です。今回8.2.35へ更新できたとしても、継続して使うなら次のバージョンへの移行計画が必要になります。
WordPress運営者が今すぐ確認する方法
ここが一番大事なところ。専門的な知識がなくても、WordPressの管理画面から、まず状況を確認できます。
- 管理画面でPHPのバージョンを見る：「ツール」→「サイトヘルス」→「情報」→「サーバー」を開き、使用中のPHPのバージョンを確認します。
- レンタルサーバーのお知らせを確認：自動的に修正版が適用されるサービスもあります。提供事業者の緊急メンテナンス情報と、利用中のプランの対応状況を確認しましょう。
- 未対策ならPHPの更新を進める：必要に応じてバックアップを取得し、テーマ・プラグインの対応状況を見ながら切り替えます。PHPの系列を変更すると互換性に影響することもあります。
- 更新後は動作と適用状況を再確認：サイト表示だけでなく、ログイン、問い合わせフォーム、決済など重要な機能を確認。サーバーを直接管理する場合は、Webリクエストを処理する実際のPHP実行環境が更新されたか確認します。
「php -vで最新版が出たからOK」と判断するのは、少し早いかもしれません。このコマンドが示すのは通常、コマンドライン（CLI）側のPHPです。Webサーバーで使っているPHP-FPMなどとバージョンが違う構成もあるためです。
なお、WordPress.orgの公式案内でも、今回の問題はPHP側にあるため、この脆弱性への対応としてWordPress本体の更新を予定していないと説明しています。つまりWordPressの「更新済み」表示だけでは判断できません。
すぐに更新できない場合はどうする？
PHP公式は、いくつかの設定変更によって特定の攻撃経路への露出を減らせると説明しています。ただし、完全な回避策はなく、更新が唯一の確実な対策だと明記しています。
WAFのルール追加や監視の強化は補助策にはなりますが、それだけで対策完了にはできません。また、紹介されているPHPのメモリ制限変更には別の運用上のリスクもあります。意味を理解せず、ネット上の設定例をそのまま適用するのは避けたいところです。
どうしても即時更新できないインターネット公開サーバーでは、公開範囲の制限や一時停止も検討してください。これは欧州のCERT-EUやWordPress.orgも示している考え方です。レンタルサーバー利用者なら、まず提供事業者に対策状況を問い合わせるのが現実的です。
実は2024年から兆候があった。AIが発見を後押しした経緯も興味深い
今回、個人的に驚いたのは、脆弱性の深刻さに加えて「どのように見つかり、修正に至ったのか」という背景です。
PHP Foundationの10月21日付説明によると、メモリ不足処理に関する問題の兆候は2024年の時点で把握されていました。しかし当時は、実際にリモートコード実行へつながる具体的な経路が見つかっていなかったといいます。
その後、2026年8月11日にセキュリティ企業Califの研究者とOpenAIが同じ根本原因について独立に報告。Wizなどからも別の攻撃経路に関する報告が寄せられ、問題の全容がはっきりしてきました。調査にはAIを活用したセキュリティ研究も関わっています。
ただし、これを「AIが単独で脆弱性を見つけ、勝手に修正した」と受け取るのは正確ではありません。複数の研究者・組織の調査と、PHP開発チームによる検証・修正作業があってこその成果です。
PHP Foundationは、修正が長引いた背景について、技術的な難しさだけでなく、意思決定の仕組みや人員不足という構造的な問題も認めています。AIで脆弱性を見つける力が伸びても、安全な修正を設計し、世界中の環境に届ける仕事には、人間の専門知識と継続的な体制が欠かせない。この点も考えさせられます。
まとめ：WordPressではなく、その下で動くPHPを見る
今回の「PHP2Shell」は、サイトのプログラムの書き方以前に、Webを支える共通基盤に重大な問題が見つかったというニュースです。
Webサイトの運営者なら、最初に確認すべきことはシンプルです。「自分のサイトで動くPHPは何バージョンで、今回の修正が適用されているか」。その答えが分からなければ、サーバー会社の案内を確認しましょう。
WordPressの管理画面に警告が出ていないから安全、と決めつけないこと。逆に、修正版が適用済みなら必要以上に慌てる必要もありません。
今回の件は、WebサイトのセキュリティがWordPress本体、プラグイン、PHP、Webサーバー、OSという何層もの土台の上に成り立っていることを、改めて思い出させてくれます。
参考情報・一次資料
- PHP公式：2026年10月21日のセキュリティアドバイザリ（修正版・対象環境・緩和策）
- PHP GitHub Security Advisory：CVE-2026-109618
- PHP GitHub Security Advisory：CVE-2026-109619
- WordPress.org日本語：PHPの重大なセキュリティリリース
- PHP Foundation：発見の経緯とセキュリティ体制に関する声明
- IPA：PHPセキュリティリリースに関する注意喚起（事前告知）
情報確認日：2026年10月22日。脆弱性の悪用状況やホスティング事業者ごとの更新状況は変化します。運用上の判断は、必ずPHPプロジェクトおよび利用中のホスティング事業者の最新情報も確認してください。
コメント