「PHPに重大な脆弱性が見つかった」というニュースを見て、「うちのサイト、大丈夫なのかな?」とドキッとした方は多いと思います。特にWordPressを使っている運営者さんにとっては、プラグインやテーマの話ならまだしも、PHPそのものの話となると、どこから手をつければいいのか分かりにくいですよね。
この記事では、「php 脆弱性 影響」と検索したあなたが知りたいであろうこと、つまりPHPの脆弱性が自分のサイトやサーバーに具体的にどんな影響を与えるのかを、専門用語をできるだけかみ砕いてお話しします。2026年10月21日に公表されたPHPの緊急セキュリティリリースの内容も、PHP公式やIPA、WordPress.orgなどの一次情報をもとに整理しました。煽るつもりはありませんが、今回は様子見で済ませにくい内容なので、順番に見ていきましょう。
PHPは、WordPressをはじめ多くのWebサイトの裏側で動いているプログラミング言語です。ブラウザからアクセスがあると、サーバー上のPHPが記事を取り出したり、お問い合わせフォームの内容を処理したりして、ページを組み立てて返してくれます。いわばサイトを動かすエンジンのような存在です。
だからこそ、エンジン部分に欠陥が見つかると、その上で動いているWordPressやプラグインがどれだけ丁寧に作られていても、影響を受ける可能性があります。家の鍵(パスワード)を頑丈にしていても、家の土台に問題があれば安心しきれない、というイメージです。
脆弱性の影響は、ざっくり次のように分けて考えると分かりやすいです。
どの種類になるかは、脆弱性ごとに違います。そして、今回のように「認証なしで、外から」「サーバー上でコードを実行される」タイプは、最も重く見られる部類です。
PHP公式サイトのニュースによると、2026年10月21日、PHPの開発チームはPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、認証なしでリモートコード実行(RCE)につながりうる2件の重大な脆弱性を修正しました。公式は「アップデートが唯一の完全な対策」としています。
どちらも、深刻度の目安であるCVSS v4.0のスコアは9.2(Critical)とされています。運営者として押さえたいのは、PHP本体の問題なので、WordPressやプラグインを最新にしても解決しない点です。
公式アドバイザリでは、8.2系は8.2.35より前、8.3系は8.3.36より前、8.4系は8.4.27より前、8.5系は8.5.12より前が対象と記載されています。PHPをWebサーバーとつなぐ方式(Apacheのmod_php、PHP-FPM、LiteSpeedなど)によって危険度に差があるとされ、アドバイザリではmod_phpがもっとも直接的に影響を受けると説明されています。ただ、「FPMなら安全」という意味ではなく、FPMなども影響を受けうるとされています。
一方、IPAの注意喚起では、調査元のWiz社の見解として「PHP 5.4以降のバージョンが少なくとも一つの脆弱性の影響を受ける」とも紹介されています。つまり、すでにサポートが終わった古い版は、修正版が出ないまま残されている可能性があります。
実際に攻撃が行われているかどうかについては、情報源によって書き方が違います。カナダのサイバーセキュリティセンターはアラート(AL26-026)で、概念実証(PoC)コードが公開されていること、実際の悪用は確認していないが状況はすぐ変わりうることを述べています。一方、BleepingComputerの報道では、Cloudflareが修正版の公開前に攻撃の兆候を観測したと伝えられています。
情報が揺れているときは、「まだ大丈夫そう」ではなく「備えておくに越したことはない」と考えるのが安全です。
PHPは今回のような緊急リリース以外にも、定期的にセキュリティ修正を含むリリースを出しています。PHP公式のChangeLogを見ると、たとえば2026年9月24日公開の8.5.11には、次のような修正が含まれています。HTTPストリームのリダイレクト時に別のサイトへ認証情報が漏れる問題(CVE-2026-91766)、TLS通信のホスト名検証でSAN(証明書に記載された名前)が合わない場合にCN(共通名)へ切り替わってしまう問題(CVE-2026-91769)、OpenSSL関連のヒープバッファオーバーフロー(CVE-2026-91767)などです。
影響の種類は「情報漏えい」「通信の安全性の低下」「メモリ破壊」とさまざまです。PHPの修正版には毎回、それなりの数の安全上の修正が入っているわけです。
こうした修正の多くは、特定の機能を使っているときに問題になりますが、レンタルサーバーでどの機能が有効かを利用者が細かく把握するのは大変です。実務上は、サポート中のバージョンの最新版を使うほうが確実で、手間も少なく済みます。
PHP公式のサポートバージョン一覧(2026年10月時点)では、次のようになっています。
この一覧に載っていないPHP 8.1は、公式のEOL(サポート終了)ページによると2025年12月31日にサポートが終了しています。PHP 8.0は2023年11月26日、PHP 7.4は2022年11月28日に終了済みです。
サポートが終わったバージョンでは、新しく見つかった脆弱性が見つかっても、PHPプロジェクトから公式の修正版は出ません。公式サイトも、古いバージョンの利用者に対して、すでに修正済みの脆弱性やバグにさらされるおそれがあるとして、現行バージョンへの更新を強く促しています。
今回のphp2shellについても、PHP 8.1以前は公式の定期的な更新の対象外です。PHPのセキュリティチームは、7.4、8.0、8.1向けに最小限のバックポート(ソースコードからビルドする人向けの修正)を公開していますが、レンタルサーバーを使っている一般の運営者が自分で適用するのは現実的ではありません。ディストリビューションや長期サポートを提供する事業者が独自に修正版を出している場合もあるため、契約先に確認するのが近道です。
なお、WordPressの動作要件のページでは、PHP 8.3以上が推奨されています。PHP 7.4以降でも動作するとしつつ、7.4などはすでにサポート終了で安全でない可能性があると警告しています。
WordPressの運営者が日常的に目にするのは、WordPress本体、テーマ、プラグインの脆弱性です。これらは管理画面から更新すれば直ります。一方、PHPの脆弱性は、サーバー側のPHPを更新しない限り直りません。
今回のケースで、WordPress.orgは「Critical PHP Security Release」という告知を出しました。その中で「WordPressの更新は必要でも予定されてもいない」とし、問題はWordPress固有のものではなく、PHPが動くサーバー全般に関わると説明しています。つまり、WordPressを最新にしていても、PHPが古ければ対策にはなりません。
もう一つの大きな違いは、対応する人です。プラグインの更新は運営者自身が行いますが、PHPの更新は、レンタルサーバーなら多くの場合は事業者が基盤側で行い、運営者は「使うバージョンを選ぶ」立場になります。自分でVPSなどを借りている場合は、運営者自身がOSやPHPを更新する必要があります。
まずは「自分のサイトがいま何のバージョンで動いているか」を知ることが出発点です。
国内の動きについては、セキュリティ関連メディアの整理記事によると、さくらインターネットが10月22日にレンタルサーバー等のPHP更新メンテナンスの完了を発表したほか、緊急メンテナンスを告知した事業者も複数あります。利用中のサービスの公式のお知らせを、必ず自分の目で確認してください。
WordPressをお使いなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHPのバージョンを確認できます。WordPress.orgの告知でも、この手順が案内されています。画面の見え方などはサイトヘルス画面の公式ドキュメントで確認できます。多くのレンタルサーバーでは、管理画面にもPHPのバージョンが表示されています。
古いPHPを使っていた場合、新しいバージョンに上げると、古いテーマやプラグインが動かなくなることがあります。切り替える前に、次のことを済ませておくと安心です。
目安として、WordPress公式が推奨するのは8.3以上、サーバー会社によっては8.5を推奨している場合もあります。エックスサーバーのマニュアルでは、WordPress向けに8.5系が推奨されており、8.2系以前は旧バージョン扱いとされています。
エックスサーバーのマニュアルでは、サーバーパネルの「PHP Ver.切替」から、対象ドメインを選んで変更後のバージョンを指定する流れになっています。さくらのレンタルサーバでは、公式の手順ページに、サーバーコントロールパネルの「言語バージョン設定」でPHPのバージョンを選んで保存する方法が載っています。同ページには、バージョン変更で古いアプリケーションが動かなくなる可能性があること、問題があれば元のバージョンを選び直せることも書かれています。画面の名前は契約先によって違うので、必ずご自身のサービスの最新のマニュアルを見てください。
PHP公式は、更新できない場合に備えた暫定策も示しています。たとえばCVE-2026-109619については、session.upload_progress.enabled=0 という設定にしてワーカーを再起動する方法などです。ただし、公式アドバイザリ自身が「設定による完全な対策は存在せず、更新が唯一の確実な方法」としています。しかもこれらはphp.iniやサーバー設定で行うもので、共有型のレンタルサーバーでは利用者が触れないことも多いでしょう。
WAF(Webアプリケーションファイアウォール)は、怪しい通信を手前で止める仕組みです。Cloudflareが暫定のルールを用意していたとの報道もあります。ただ、これもあくまで「時間を稼ぐ手段」であり、PHPを更新する代わりにはなりません。自分で管理するサーバーで、すぐに更新できない場合は、WordPress.orgの告知が引用しているイギリスNCSCの助言のとおり、「完全な緩和ができるまでシステムをオフラインにすることも検討する」という判断もありえます。
使っていないプラグインやテーマは削除しておくと、更新の対象が減ってラクになります。また、更新が済んだあとも、サーバーのログに見覚えのないアクセスがないか、身に覚えのないファイルやアカウントが増えていないかを見ておくと安心です(カナダのサイバーセキュリティセンターのアラートも、ログの確認や不審なプロセス・ファイル・アカウントの調査を勧めています)。
いいえ、それだけでは大丈夫とは言えません。PHPの脆弱性はサーバー側のPHP本体の問題なので、プラグインやWordPress本体を更新しても解消されません。WordPress.orgも、今回の件ではWordPress本体の更新は不要で、PHPを更新する必要があると説明しています。
事業者がサーバー側のPHPを更新してくれている場合もありますが、まずは契約先の公式のお知らせを確認し、管理画面で自分のサイトが使っているPHPのバージョンを見てください。選んでいるバージョンが8.1以前などサポート終了のものであれば、サポート中のバージョンへの切り替えを検討する必要があります。WordPress.orgの告知でも、まずホスティング会社に確認するよう案内されています(ホスト側がすでにPHPの更新やWAFルールの追加を進めている場合があるため)。
ページの表示が見覚えのないものに変わっていないか、管理者アカウントが増えていないか、見覚えのないファイルがないか、といった点が手がかりになります。不安なときは、サーバー会社のサポートや、サイト制作を依頼した会社に相談しましょう。
慌てず、まず切り替え前のバージョンに戻してみてください(多くのレンタルサーバーでは、管理画面から選び直せます)。そのうえで、バックアップから復元できる状態であることを確認し、原因になっていそうなテーマやプラグインの対応状況を調べます。
ここまで、PHPの脆弱性がサイトやサーバーに与える影響を見てきました。ポイントを振り返ると、PHPの脆弱性はPHPを更新しない限り直らないこと、サポートが切れたバージョンは修正の対象外になりがちなこと、そしてWordPressやプラグインの更新とは別の話であることの3つです。
今週やっておきたいのは、次の3つです。まず、いまのPHPのバージョンを確認する。次に、契約先の公式のお知らせを読み、対応状況を確かめる。最後に、バックアップを取ったうえで、必要ならサポート中のバージョンに切り替える。この流れさえ押さえておけば、大きく慌てる必要はありません。
なお、この記事は2026年10月23日時点で確認できた情報をもとにしています。悪用の状況や各社の対応は日々更新されますので、最終的な判断は、PHP公式やIPAの注意喚起、契約先の最新の告知で確認してくださいね。
