本文へスキップ
PENTESTLAB

セキュリティ解説

PHPの脆弱性(2026年10月)とは?WordPressサイトの確認方法と対処手順

2026年10月公表のPHP緊急脆弱性について、非エンジニアの方向けに影響・確認方法・無料でできる対処手順をまとめました。

公開日:確認日:2026年10月22日セキュリティ解説の一覧

この記事の結論(確認日:2026年10月22日)

2026年10月21日、PHPに緊急の脆弱性が2件公表されました(CVE-2026-109618/CVE-2026-109619、深刻度はCVSS v4.0で9.2=「緊急」)。ログイン不要で、外部からサイトを乗っ取られるおそれがあります。

対策は「PHPを修正済みのバージョンに更新すること」です。設定変更などによる完全な回避策はありません。この記事の手順はすべて無料で、お申し込みや登録は不要です。

今回のポイント3つ。深刻度はCVSS 9.2『緊急』、手口は認証不要の乗っ取り、対策はPHPを修正版に更新すること。

結論:まず確認すること

まず、次の3点を確認してください。

  1. 1レンタルサーバー(ホスティング会社)でサイトを動かしている場合は、まずそのサーバー会社の「お知らせ」を確認します。多くの会社は会社側で更新するため、利用者の操作が不要なこともあります。
  2. 2WordPressなどを使っていても、土台のPHPは別物です。プラグインやWordPress本体の更新とは別に、PHPの更新が必要です。
  3. 3自分でサーバーを管理している場合は、修正版に更新したうえで、Webサーバーや常駐するPHPを再起動します(再起動しないと反映されません)。

今回の脆弱性とは(やさしく解説)

PHPの役割の図解。利用者がブラウザでアクセスすると、サーバーの中でPHPがページの中身をその場で組み立て、できあがったページが表示される。WordPressや多くのサイトはこのPHPの上で動いている。

今回見つかった2件は、どちらも「認証不要のリモートコード実行(RCE)」——ログインしていない第三者が、通信を送るだけでサーバー上を乗っ取れる、もっとも重い部類の問題です。乗っ取り・改ざん・情報流出につながるおそれがあります。

公表された2件の脆弱性(いずれもCVSS v4.0 9.2・認証不要)
CVE-2026-109618メモリが不足したときの処理に不備があり、受け取ったリクエストのデータが中途半端な状態のまま残ってしまう問題。悪用されると、外部から任意のプログラムを実行される(乗っ取られる)おそれがあります。
CVE-2026-109619リクエストごとに使う内部データが、本来は破棄された後も使い回されてしまう不具合。悪用されると、同じく外部から任意のプログラムを実行されるおそれがあります。

原因はPHPの session.upload_progress という初期設定で有効な機能ですが、利用者が触る必要はありません。要点は「修正版に更新すれば直る」ことです。

経緯のタイムライン。2026年10月20日ごろに攻撃の詳細が流出し、10月21日にPHP開発元が公表して修正版(8.5.12/8.4.27/8.3.36/8.2.35)をリリース、いますぐ更新を、という流れ。
すでに悪用コード(通称「php2shell」)が出回り、悪用の試みも観測されています(調査中)。米国CISAも早急な更新を呼びかけています。設定変更による部分的な緩和策は副作用があり推奨しません。確実な対策は、修正版への更新です。

影響するサイト・環境

PHPで動くサイトが対象です。WordPress・多くのEC・会社/店舗サイトの多くが該当します(不明なら制作会社かサーバー会社に確認を)。

レンタルサーバーも、WordPressも関係します。更新は多くの場合サーバー会社が行いますが、利用者がPHPバージョンを選ぶ方式もあります。そして、WordPress本体・テーマ・プラグインの更新と、土台のPHPの更新は別物です。

WordPress本体・テーマ・プラグイン(アプリ側、ふだん更新している部分)と、その土台で動くPHP(今回更新が必要な部分)、さらに下のサーバーOSを、層として表した図。アプリ側を最新にしても、土台のPHPは別に更新が必要であることを示している。
更新の種類と、今回の脆弱性への効果の違い
更新の種類何を更新する?今回の件に効く?
WordPress本体・テーマ・プラグインの更新WordPressというアプリ側直接は効きません(別途、土台のPHPの更新が必要)
PHP本体の更新(今回必要なもの)サイトを動かす土台のソフト効きます。これが今回の対策です
セキュリティプラグイン・WAFの導入攻撃を検知・遮断する補助の仕組みそれだけでは不十分です(更新が必要)

確認チェックリスト(まず手元で確認)

  • サイトはWordPress・EC・一般的なCMSなど、PHPで動いているか(不明ならサイト制作会社かサーバー会社に確認)
  • 利用しているサーバー会社名と契約プランを把握しているか
  • サーバーの管理画面にログインできるか
  • サーバー会社の「お知らせ/障害情報」ページの場所を知っているか
  • 更新の前にバックアップを取る準備ができているか

PHPのバージョンの確認方法

まずは、いま使っているPHPのバージョンを確認します。次のいずれかの方法で確認できます。

  1. 01

    レンタルサーバーの管理画面で確認する

    契約しているサーバーの管理画面に、「PHP設定」「PHPバージョン」などの項目があります(項目名は会社により異なります)。そこで現在のバージョンを確認できます。

  2. 02

    WordPressの管理画面で確認する

    WordPressをお使いなら、管理画面の「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の中に、現在のPHPバージョンが表示されます。

  3. 03

    サーバー会社のヘルプ・マニュアルを見る

    多くのサーバー会社は、PHPバージョンの確認・変更方法を公式ヘルプで案内しています。「(会社名) PHP バージョン 確認」で検索してみてください。

WordPress管理画面の「ツール › サイトヘルス › 情報」タブで「サーバー」を開いた表示例。PHP のバージョンとして 8.2.10 が表示されている様子。
※ 画面は表示イメージです。実際の表示は、WordPressのバージョンやテーマにより多少異なります。

番号だけで「安全/危険」を決めつけないでください

サーバー会社やOSのディストリビューションは、古い番号の製品に修正だけを取り込む「バックポート」を行うことがあります。たとえば番号が古いままでも修正が入っていることがあり、逆に新しそうでも未対応のことがあります。確実なのは、次のセクションのとおり、サーバー会社の「この件に対応済み」という案内を確認することです。

サーバー会社の対応情報の確認方法

共用のレンタルサーバーでは、多くの場合、会社側がまとめて更新します。ただし「PHPのバージョンは利用者が選ぶ」方式のところでは、利用者が修正版に切り替える必要があります。次の順で確認しましょう。

  1. 1サーバー会社の「お知らせ」「障害・メンテナンス情報」「セキュリティ情報」のページを開く。
  2. 2ページ内を「PHP」「セキュリティ更新」「CVE-2026-109618」などで探す。
  3. 3すでに対応済みか、利用者側で何か操作(PHPバージョンの切り替えなど)が必要かを確認する。
  4. 4案内が見当たらなければ、サポート窓口に対応状況を問い合わせる(下に文例があります)。

サポートへの問い合わせ文例(コピーして使えます)

お世話になっております。2026年10月21日に公表されたPHPの脆弱性(CVE-2026-109618 / CVE-2026-109619)について、貴社サーバーでの対応状況を教えてください。すでに対応済みでしょうか。また、当方(利用者)側で必要な操作(PHPバージョンの切り替えなど)があれば、あわせてご教示ください。

対処の手順(バックアップ→更新→動作確認)

大きな流れは、次の3ステップです。制作・保守を外部に依頼している場合は、この手順をそのまま依頼してください。

対処の3ステップ。STEP1 バックアップ、STEP2 修正版に更新(会社側が更新する場合と自分で切り替える場合がある)、STEP3 動作確認。更新後に不具合が出たらバックアップから元に戻す。

各ステップの詳しい進め方

  1. 1

    バックアップを取る

    更新の前に、サイトのデータ(ファイルとデータベース)のバックアップを取得します。サーバー会社のバックアップ機能、またはWordPressならバックアップ系のプラグインを使うのが簡単です。何かあっても元に戻せる状態にしてから進めます。

  2. 2

    サーバー会社の対応状況を確認する

    前の項目のとおり、会社側がすでに更新しているのか、利用者が自分でバージョンを切り替える方式なのかを確認します。これで、自分が何をすべきかが決まります。

  3. 3

    PHPを修正版に更新(または切り替え)する

    会社側が自動で対応する場合は、利用者の操作は基本的に不要です(念のため現在のバージョンを確認しておきましょう)。利用者がバージョンを選ぶ方式の場合は、管理画面で、利用中の系統の修正版(8.5.12/8.4.27/8.3.36/8.2.35 以降)に切り替えます。

  4. 4

    更新後に再起動する

    自分でサーバーを管理している場合は、更新後にWebサーバー(ApacheやNginxなど)・PHP-FPM・常駐しているPHPのプロセスを再起動します。再起動しないと、古いプログラムが動き続けて修正が反映されません。共用のレンタルサーバーでは、この再起動は会社側が行います。

  5. 5

    動作確認をする

    サイトが正常に表示・動作するかを確認します。トップページだけでなく、お問い合わせフォーム・ログイン・会員機能・決済など、主要な機能が動くかも確かめてください。PHPのバージョンが意図したものに切り替わっているかも、あわせて再確認します。

レンタルサーバーの管理画面でPHPバージョンを切り替える表示例。現在のバージョン 8.2.10 に対し、変更後のバージョンとして修正版の 8.2.35 を選び、「変更を保存」する様子。
※ 画面は表示イメージです。項目名やレイアウトは、ご契約のサーバー会社により異なります。会社側がまとめて更新する方式では、この操作が不要なこともあります。
可能であれば、本番のサイトに適用する前に、テスト環境(ステージング)で試すとより安全です。テスト環境の用意が難しい場合は、バックアップを確実に取ってから進め、作業後すぐに動作確認を行ってください。

今回のPHPの件は、ここまでの無料手順でご対応ください(費用・お申し込みは不要です)。あわせて、サイトの公開設定(HTTPSや各種セキュリティヘッダーなど)も見直したい場合は、無料チェックをお試しいただけます。※ 無料チェックは、今回のPHPの修正状況は判定しません。

無料チェックを試す

自分でサーバーを管理している場合

VPS・専用サーバー・クラウドなどで、自分でPHPをインストールして運用している場合は、サーバー会社が代わりに更新してくれません。自分で修正版へ更新する必要があります。利用中の系統に応じて、次の修正版(またはそれ以降)へ更新してください。

PHPのバージョン別の更新先の早見表。8.5系は8.5.12以降、8.4系は8.4.27以降、8.3系は8.3.36以降、8.2系は8.2.35以降に更新(8.2系は2026年12月31日にサポート終了)。8.1系・以前は公式の修正がなく、サポートされる系統への移行が必要。

OSのパッケージ(apt・yum・dnf など)でPHPを入れている場合は、OSのディストリビューションが配布する更新を適用します。ここでもバックポートがあるため、バージョン番号ではなく、ディストリビューションの案内で「この件に対応済み」であることを確認してください。

更新後は必ず再起動してください。PHP-FPM・Webサーバー(ApacheやNginx)・常駐しているワーカーやキュー処理を再起動しないと、古いプログラムが動き続けて修正が反映されません。

具体的なコマンドは環境ごとに異なり、誤ると停止の原因になるため、本記事では個別のコマンドは指定しません。各ディストリビューション・ホスティングの公式手順に従ってください。

更新できない・不具合が出た場合

古いバージョン(8.1以前など)を使い続けるリスク

PHP 8.1 やそれ以前には、今回の公式修正が提供されません。脆弱性が残り続けるため、できるだけ早く、サポートされている系統(8.2以降、できれば8.3〜8.5)への移行を検討してください。

PHP 8.2 は 2026年12月31日にサポート終了(EOL)

PHP 8.2 系は 2026年12月31日でサポートが終わります。その後は8.2系にも公式の修正が出なくなるため、更新のついでに、より新しい系統への移行もあわせて検討すると安心です。

すぐに更新できない事情があるとき

古いプラグインやテーマ、独自のプログラムが新しいPHPで動かない、といった事情ですぐに更新できない場合は、まずサーバー会社に相談してください。会社側の対応で守られているケースもあります。

更新後に不具合が出たとき

あわてず、取得しておいたバックアップから元に戻します(切り戻し)。そのうえで、サイトを制作・保守している会社に相談してください。新しいPHPに合わせて、プラグイン・テーマ・プログラムの更新が必要なこともあります。

設定変更による部分的な緩和策は公表されていますが、環境を理解せずに行うと別の不具合を招くおそれがあるため、本記事では推奨しません。確実な対策は修正版への更新です。判断に迷う場合は、サーバー会社やサイトの制作・保守会社にご相談ください。

今回の対処だけでは足りないこと

誤解しやすい点を正直にお伝えします。次の「よくある思い込み」と「実際」を取り違えないようにしてください。

  • 思い込み:WordPressやプラグインを最新にした=PHPも対策済み

    実際:WordPress本体・プラグインの更新と、土台のPHPの更新は別物です。両方が必要です。

  • 思い込み:PHPを使っている=もう侵入されている

    実際:PHPを使っていることと、侵入されたことはイコールではありません。まずは落ち着いて、確認と更新を進めてください。

  • 思い込み:更新した=過去に侵入されていないと分かる

    実際:更新は「これ以降の悪用を防ぐ」ものです。詳細が流出した10月20日ごろから更新までの間に悪用された可能性はゼロではありません。更新後も、見覚えのないファイル・管理ユーザー・改ざん・不審な通信がないかを確認しましょう。

  • 思い込み:今回の更新=サイト全体の脆弱性診断

    実際:今回の1件を直しても、ほかの脆弱性(設定不備やアプリ側の不備など)は別に残りえます。今回の対処は「サイト全体を調べたこと」にはなりません。

  • 思い込み:セキュリティプラグインやWAFを入れた=今回の問題も解決

    実際:検知・遮断の補助にはなりますが、それだけでは今回の問題は解決しません。確実な対策はPHPの更新です。

侵入の疑いがあるときは

改ざん・見覚えのないファイルや管理ユーザー・不審な通信などがあり、侵入の疑いがある場合は、「更新したから大丈夫」とは扱わないでください。被害範囲の確認や復旧が別途必要になるため、サイトの制作・保守会社や専門家にご相談ください。

よくあるご質問

WordPressを最新にしていれば大丈夫ですか?

いいえ。WordPress本体・テーマ・プラグインの更新と、それらを動かす土台であるPHPの更新は別です。今回の件は、PHPを修正版のバージョンに更新する必要があります。

セキュリティプラグインやWAFを入れていれば防げますか?

それだけでは今回の問題は解決しません。攻撃の検知・遮断を補助する仕組みとして役立つことはありますが、確実な対策はPHPを修正版に更新することです。

自分のPHPのバージョン番号が新しければ安全ですか?

番号だけでは判断できません。サーバー会社やOSのディストリビューションは、古い番号の製品に修正だけを取り込む「バックポート」を行うことがあります。古い番号でも対応済みのことがあり、逆に新しそうでも未対応のことがあります。確実なのは、サーバー会社の「この件に対応済み」という案内を確認することです。

レンタルサーバーなら、自分では何もしなくていいですか?

会社側がまとめて更新する場合もあれば、利用者が管理画面でPHPバージョンを選ぶ方式の場合もあります。まずはサーバー会社のお知らせを確認し、分からなければサポート窓口に問い合わせてください。

更新すれば、過去に侵入されていないと分かりますか?

いいえ。更新は今後の悪用を防ぐための対策です。過去に侵入されたかどうかは別の確認が必要で、改ざんや不審な動きなど侵入の疑いがある場合は、「更新したから大丈夫」と扱わず、サイト制作会社や専門家に相談してください。

出典

確認日:2026年10月22日。本記事は公表直後の情報にもとづきます。最新かつ正確な情報は、必ずPHP公式サイト(php.net)およびご利用のサーバー会社の案内をご確認ください。公式の新しい情報が本記事の内容に優先します。

サイト全体のセキュリティも見直したい方へ

今回のPHPの脆弱性は、この記事の無料手順でご対応ください(費用・お申し込みは不要です)。

無料Webセキュリティチェックは、今回のPHPの修正状況(対応済みかどうか)は判定しません。URLを入力すると、公開情報から確認できる別のセキュリティ設定(HTTPS・TLS・各種セキュリティヘッダー・Cookieの属性・バージョン表示など全14項目)を確認するものです。

ログイン後の機能やアプリ内部まで含めた、サイト全体のより詳しい検査をご希望の場合は、有料の脆弱性診断(100,000円・税込)・ソースコード診断(300,000円・税込)で承ります(提供中)。いずれも、管理権限の確認と診断範囲の合意のうえで実施します。