PHPの脆弱性2026|WordPressへの影響と対策

PHPの脆弱性で、いま確認すること
- 2026年10月21日、PHPで重大な脆弱性2件への修正版が公開されました。WordPressの更新とは別に、サーバー側のPHPの対応確認が必要です。
- 修正版はPHP 8.2.35・8.3.36・8.4.27・8.5.12。サーバー会社が独自に修正を適用する場合もあるため、表示された番号だけで判断しません。
- 確認の順番は「利用サービスを把握 → サーバー会社の告知 → サイトごとのPHP → 更新と動作確認 → 対応記録」です。
- 脆弱性の存在、予防のための停止、実際の不正アクセスは別の状態です。世界中のサイトが侵入されたという発表ではありません。
PHPの重大な脆弱性「PHP2Shell」が公表され、レンタルサーバーやWebサイトの運営者に対応が求められています。「自分の会社のホームページも関係するのか」「WordPressを更新すれば終わりなのか」と迷っている方もいるはずです。
この記事では、PHP公式とWordPress公式の発表をもとに、対象バージョン、影響の考え方、確認方法、制作会社・サーバー会社への問い合わせ方を整理しました。情報の確認日は2026年10月22日です。サービスの再開状況や修正の提供状況は変わるため、作業直前に各社の続報も確認してください。
PHPの重大な脆弱性「PHP2Shell」とは?
PHP2Shellは、PHP自体で見つかった重大な脆弱性2件を指す呼び名です。攻撃条件がそろうと、ログインしていない第三者がサーバー上でコードを実行できるおそれがあります。修正版は2026年10月21日に公開されました。PHP公式のセキュリティ告知・共同発見に関わったWizの解説
環境や攻撃条件によっては、メモリー内の情報が読み取られるおそれもあります。これは、各サイトで実際に情報漏えいが確認されたという意味ではありません。PHP開発元の技術情報
PHPはWordPressを動かす土台
PHPとは、Webサーバーでプログラムを動かすための言語です。WordPressでは、ページを作る、入力を受け付ける、データベースから記事を取り出すといった処理に使われています。
ホームページの運営では、WordPress本体、テーマ、プラグイン、PHPを別々に管理します。見た目を整えるテーマが最新でも、PHPが修正されているとは限りません。今回確認する対象は、その土台に当たる部分です。
WordPressとPHPは、更新する場所が違います
対象となる2つのCVEと深刻度
| 識別番号 | 公式発表の内容 | 運営者が押さえる点 |
|---|---|---|
| CVE-2026-109618 | メモリー不足への対応中に、不完全な内部データを処理してしまう問題 | Webアプリの処理が始まる前に攻撃につながる構成もあります |
| CVE-2026-109619 | 解放済みのメモリーを参照する内部状態が残り、後のリクエストで使われる問題 | 構成や処理によって影響が変わり、単一の設定変更では全経路を防げません |
公式の深刻度評価は、いずれもCVSS v4.0で9.2です。この数値は脆弱性の深刻度であり、「侵入される確率が92%」という意味ではありません。技術的な条件はPHP開発元のCVE-2026-109618の詳細とCVE-2026-109619の詳細で確認できます。
なぜ世界規模の問題になったのか
多くのサービスが共通して利用するPHPに問題が見つかったため、国や業種をまたいだ対応が必要になりました。日本でもIPAが10月21日23時(日本時間)の公開予定を案内し、事前準備を呼びかけていました。IPAの事前注意喚起
「世界規模」は影響を受ける可能性のある環境が広いという意味です。使っているだけで全サイトが侵入された、ということではありません。また、発表日が分かっても、脆弱性が生まれた日や個々のサイトへの侵入日時まで分かったことにはなりません。
AIとの関係はどこまで分かっている?
発見に関わったWizは、脆弱性の調査や攻撃が成立するかの検証にAIを活用したと説明しています。研究者が欠陥を見つけ、修正につなげる作業でAIを使ったという発表です。Wizによる調査経緯の説明
この発表と、「国内企業への不正アクセスをAIが実行した」という主張は別です。個別事件でどの道具が使われたかは、調査結果がなければ断定できません。サイト運営者にとっては、AIという言葉に注目するだけでなく、使っているソフトウェアを把握し、修正情報が出たら対応できる体制を整えることが具体的な備えになります。
自社サイトやWordPressも影響を受ける?
PHPでWebリクエストを処理する環境は確認対象です。WordPressを使うサイトは、サーバー会社の修正状況と、そのサイトで実際に使われているPHPを確認してください。
WordPress本体の更新だけでは完了しない
WordPress公式は、今回の問題はWordPress固有ではなく、PHPの更新が必要だと案内しています。この脆弱性への対応としてWordPress本体の更新を予定しているわけではありません。ダッシュボードに「最新」と出ていても、PHPの修正状況は別に確認します。WordPress公式の注意喚起
プラグインを一つ追加したり、管理画面のパスワードだけを変えたりしても、PHP自体の修正にはなりません。もちろん、本体・テーマ・プラグインの更新は日常の保守として必要です。それぞれの作業を同じものとして扱わないことが大切です。
PHP-FPMなら対象外、と決めつけない
PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含め、Webリクエストを処理するPHP環境に注意を促しています。攻撃の成立条件や実証状況は構成ごとに異なります。「うちはApacheではないから関係ない」と自己判断するのは避けてください。PHP公式の影響範囲
担当者への確認では、「何という製品を使っているか」だけでなく、「今回の2件に対する修正が、稼働中の環境へ反映されているか」を聞きます。製品名だけでは、適用済みかどうかが分からないためです。
静的サイトや外部の予約サービスはどう確認する?
HTML・CSS・画像をそのまま配信するだけの部分では、PHPを実行しません。ただし、見た目が静的でも、問い合わせフォーム、予約、会員ページ、管理用の別サイトでPHPを使っている場合があります。
外部の予約サービスやネットショップを組み込んでいる場合、利用者側でそのPHPを更新することは通常できません。サービス提供元の障害情報や対応案内を確認します。自社ホームページの確認と、外部サービスの確認を一覧にすると、確認漏れを防ぎやすくなります。
修正版と対象バージョンの確認方法

PHP公式が今回の修正版として公開したのは、8.2.35、8.3.36、8.4.27、8.5.12です。利用中の系列と照合し、サーバー会社やOS提供元の修正案内も合わせて確認します。
PHPの系列ごとの修正版一覧
| 利用中の系列 | 公式修正版 | 確認すること |
|---|---|---|
| PHP 8.2 | 8.2.35 | 8.2.34以前は今回の修正適用を確認 |
| PHP 8.3 | 8.3.36 | 8.3.35以前は今回の修正適用を確認 |
| PHP 8.4 | 8.4.27 | 8.4.26以前は今回の修正適用を確認 |
| PHP 8.5 | 8.5.12 | 8.5.11以前は今回の修正適用を確認 |
| PHP 8.1以前 | 通常の公式リリースはサポート対象外 | 提供元の修正適用状況と、サポート対象版への移行を確認 |
表は今回の脆弱性に対応した初回修正版を示します。「これ以降、更新しなくてよい」という一覧ではありません。公開後に新しい修正版が出ている場合は、その案内を優先してください。PHP公式のリリース情報
PHP 8.1以前と独自パッチの注意点
PHP 8.1以前は通常の公式サポートを終了しています。一方、今回の重大性を受け、PHP公式は7.4・8.0・8.1向けに最小限の修正コードも提供しています。これは古い系列の通常サポートが再開したという意味ではありません。PHP公式の旧版向け案内
サーバー会社やOSの長期サポート提供元が、表示バージョンを大きく変えず修正だけを組み込む「バックポート」で対応する場合もあります。番号が古く見えることだけで未対応と断定せず、対象のCVE、適用日、対象サーバーを確認します。旧版のまま使い続ける判断と、今回の応急対応が済んだかどうかは分けて考えましょう。
WordPressの管理画面でPHPを確認する
- WordPress管理画面にログインします。
- 「ツール」から「サイトヘルス」を開きます。
- 「情報」タブの「サーバー」を開きます。
- 「PHPバージョン」を控え、サーバー会社の告知と照合します。
この確認場所はWordPress公式が案内しています。ログインできない場合や表示が異なる場合は、レンタルサーバーの管理画面、または保守担当者に確認してください。WordPress公式の確認手順
同じ契約の中でも、ドメインやサブドメインで設定が違う場合があります。本サイトが対応済みでも、古い採用サイト、使っていないテスト環境、別の問い合わせフォームが残っていないか確認します。複数のサイトを持つ会社では、URLごとの記録が役立ちます。
エックスサーバーなどの対応はどう見る?
サーバー会社のお知らせは、対象サービス、対象バージョン、発表時刻をセットで読みます。管理画面が再開したことと、すべてのPHP系列への対応が終わったことは同じ意味ではありません。
エックスサーバーの10月22日時点の発表
エックスサーバーは10月22日6時45分時点で、PHP 8.2〜8.5について対象となる全サーバーへの修正パッチ適用が完了したと案内しています。旧バージョンは準備・検証が終わったものから順次対応する説明でした。
同日の9時30分には一部を除く管理画面等の提供再開、13時15分にはシンクラウド各種サービスの管理画面等の再開が案内されました。一部機能は点検中です。この記述は10月22日13時41分に取得した告知に基づきます。現在の状態はエックスサーバー公式のお知らせを確認してください。
管理画面の停止は不正アクセスの証拠?
エックスサーバーは、今回の停止を予防的な安全対策と説明し、同社への不正アクセス発生に伴うものではないと明記しています。また、利用者のWebサイト表示やメールソフトでの送受信は通常どおり利用できると案内しています。エックスサーバーの停止理由と影響範囲
告知を読むときは、「管理画面が開かない」「サイトが止まっている」「情報が漏えいした」を分けます。外から見える停止だけでは原因は確定できません。取引先やお客様に説明するときも、公式に分かっている範囲を越えて被害を断定しないようにします。
別のサーバーやVPSは個別確認が必要
エックスサーバーの発表を、他社サーバーや自分で管理するVPSに当てはめることはできません。サービス名が似ていても、運用の責任範囲が異なる場合があります。
レンタルサーバーでは提供会社がPHPを管理することが多く、自主管理のVPSでは契約者側が更新を担当する場合があります。誰が更新する契約なのか、誰が完了を確認するのかを先に決めてください。複数の会社へ保守を依頼しているなら、担当が重なる部分より、誰も担当していない部分がないかを確認します。
サイト運営者が行う対応の順番
運営者の役割は、対象を洗い出し、担当者に修正を依頼し、動作と対応記録を確認することです。侵入の疑いが見つかった場合は、通常の更新作業から事故対応へ切り替えます。
PHP対応の流れ
1.公開中のサイトと保守担当を一覧にする
会社のホームページだけでなく、ECサイト、予約システム、キャンペーンページ、テスト用サブドメインを含めます。会計サービスや外部フォームなど、自社でサーバーを管理しないサービスも別欄で控えます。
| 記録項目 | 何のために残すか |
|---|---|
| サイト名・URL・契約サービス | 対応すべき範囲を取り違えないため |
| PHP系列・修正適用の根拠 | 表示番号と提供元の案内を照合するため |
| 作業担当・確認担当 | 誰かが対応したはず、を防ぐため |
| 確認日時・告知URL | その時点の判断を後から追えるようにするため |
| 更新後の動作・残課題 | 修正済みと正常動作を別々に確認するため |
2.バックアップと更新方法を担当者に確認する
更新の前には、ファイルとデータベースの控え、復元方法、確認担当をそろえます。ただし、バックアップの準備を理由に未修正の公開を長引かせるのではなく、担当者と公開制限などの暫定措置も検討します。
系列内の修正版への更新と、古い系列から新しい系列への移行では、動作への影響が異なります。古いテーマやプラグインがある場合は、可能なら隔離した検証環境で確認します。「何かあれば脆弱な版に戻して公開を続ける」という復旧手順にしないことも必要です。
3.更新後は問い合わせや注文まで確かめる

トップページが表示されただけでは、業務に必要な機能まで動いているとは限りません。普段お客様が使う順番に沿って確認すると、見落としが減ります。
- 記事・固定ページ・画像が表示されるか。
- 問い合わせフォームで入力、確認、送信、受信まで進むか。
- 予約・会員ログイン・ファイル添付が使えるか。
- ECサイトなら、承認されたテスト方法で購入の流れを確認できるか。
- 管理画面で編集・保存でき、エラーログに新たな異常がないか。
本番の送信や購入を伴う検査は、宛先・費用・キャンセル方法を確認してから行います。表示確認だけで済ませた場合は、「送信まで確認済み」とは記録しません。
「対応済み」の意味を分けて記録
4.修正済みの根拠と未確認項目を残す
「更新しました」という連絡に加え、対象URL、適用したPHPまたはパッチ、適用日時、確認した機能を残します。サーバー会社による一括適用であれば、その告知と自分の契約が対象であることを記録します。
脆弱性の修正と、過去の侵入がなかったことの確認は別です。修正後にサイトが正常でも、それだけで過去のログやデータ流出の有無まで判断できません。不審な管理者、見覚えのないファイル、異常な送信などがある場合は、保守担当と調査の範囲を決めてください。
すぐに更新できない場合はどうする?
WAFや設定変更は、更新までの危険を減らすための措置です。PHP公式は、設定変更だけではすべての攻撃経路を解消できないと説明しています。
WAFが有効でも、修正の確認は必要
WAFはWebへの通信を検査する仕組みですが、PHPのコード自体を直すものではありません。ルールが今回の攻撃に対応しているか、通信がWAFを通る構成かなどで効果が変わります。「WAFを契約している」という事実だけで対応完了にはできません。WordPress公式の更新案内
設定値をそのままコピーしない
PHP公式は暫定措置として、メモリー管理やリクエスト制限、アップロード進捗機能などの設定を示しています。ただし、適用場所やPHPワーカーの再起動が関係し、一部の設定だけでは防げない経路もあります。メモリー関連の公式説明・内部状態に関する公式説明
たとえばメモリー制限の変更は、サーバーの安定性にも関わります。フォームや画像アップロードを止める設定は、問い合わせや業務を止める可能性があります。一般のサイト運営者は、ネットで見つけた設定値を本番に貼り付ける前に、提供元または管理者へ対応を依頼してください。
公開制限や一時停止を検討する場面
修正版を適用できず、安全を確保できない場合は、管理者と公開範囲の制限や一時停止を検討します。WordPress公式も、特に古いPHPを自主管理している場合について、更新準備中のサーバー停止を検討する案内を掲載しています。WordPress公式の旧版利用者向け説明
停止する場合は、お客様向けの告知、電話などの代替連絡先、再開判断の担当を一緒に用意します。侵入の疑いがあるときは、証拠保全が必要です。自己判断でログを消したり、サーバーを初期化したりせず、専門家の指示を受けてください。
制作会社・サーバー会社への確認文
問い合わせでは、対象サイトと今回の識別番号を伝えると確認範囲が明確になります。「セキュリティは大丈夫ですか」だけで終えず、適用状況と残る作業を聞きましょう。
当社サイトで利用しているPHPについて、CVE-2026-109618およびCVE-2026-109619への対応状況を確認したく、ご連絡しました。
対象サイトは、当社ホームページと、同じ契約内の関連サイトです。現在のPHPバージョン、今回の修正適用の有無と適用日時、当社側で必要な追加作業をご案内ください。
独自パッチによる対応の場合は、対象のバージョンと今回の2件が修正対象に含まれることも確認したいです。更新に伴う動作確認の範囲と、未対応箇所があればその対応予定をお知らせください。
送るときは、実際の対象URLを追記してください。パスワードや認証コードをメール本文へ書く必要はありません。契約番号などの照合情報は、提供元が指定する窓口・方法で渡します。
国内企業の情報漏えいとの関係
今回のPHPの脆弱性と、国内企業で公表されている不正アクセスが同じ原因だとは、確認した公式資料からは判断できません。同じ時期に報道されていることだけで関連付けないことが必要です。
IPAも10月9日の注意喚起で、当時の一連の事案について特定の製品やサービスの脆弱性を狙った攻撃とは断定されていないと説明しています。個別企業の原因は、その企業の調査結果や続報で確認します。IPAの国内事案に関する注意喚起
一方、事業者が取り組むべき課題はつながっています。ソフトウェアを更新できる状態にする、不要な個人情報を残さない、担当者と連絡先を決める、バックアップから戻せるか確かめる。今回の対応を、日常の保守を点検する機会にしてください。
自社サイトのPHPや保守担当が分からない場合は、スタジオ・コハクのお問い合わせ窓口からサイトURLと分かる範囲の契約情報をご相談ください。個別の調査・対応範囲は、構成や契約内容を確認してご案内します。


