ブログやネットショップは、画面に見えている部分だけで動いているわけではありません。サーバーの中でページを組み立てる仕組みの一つが、プログラミング言語のPHPです。WordPressも、このPHPを使います。
そのPHPで、外部の人がログインせずにサーバー上でコードを実行できる可能性がある、重大な脆弱性2件の修正版が2026年10月21日に公開されました。個人ブログ、企業サイト、ネットショップ、Webアプリを運営する人から、普段サービスを利用する人まで、仕組みと立場ごとの確認方法を整理します。
先に要点:修正版はPHP 8.5.12/8.4.27/8.3.36/8.2.35です。レンタルサーバー利用者は、契約先が提供する修正状況と、自分のサイトで動いているPHPを確認してください。WordPress本体の更新だけで、PHP本体の修正が済むとは限りません。[1]
情報確認・改稿:2026年10月28日(日本時間)。アイキャッチはサーバー設備のイメージ写真です。撮影:imgix/Unsplash。今回の攻撃現場やXyphaの設備を撮影したものではありません。本記事はXypha自身の修正完了や安全性を宣言するものではありません。
PHPとは?ページの「裏側」で働く仕組み

WordPressで記事を開くと、サーバー側では記事の本文や設定を読み取り、テーマに合わせたページを作り、ブラウザーへ返します。PHPは、この処理を担うプログラムを動かす土台です。読者のスマートフォンにPHPをインストールして記事を読む、という仕組みではありません。
レストランにたとえると、ブラウザーは注文するお客さん、WordPressは料理の作り方、PHPはその手順を実行する厨房の設備に近いものです。メニューを書き直すことと、厨房の設備を修理することは別の作業になります。
この区別は更新にも当てはまります。WordPress本体、テーマ、プラグイン、PHP、OSはそれぞれ更新の対象です。管理画面に「WordPressは最新」と出ていても、それだけでサーバーのPHPが今回の修正版になったことまでは分かりません。[7]
今回のPHPの脆弱性は何が問題なのか

今回の識別番号はCVE-2026-109618とCVE-2026-109619です。CVEは脆弱性を取り違えずに追跡するための番号です。2件はいずれも深刻度を示すCVSS v4.0で9.2とされています。ただし、この数値は「攻撃される確率92%」という意味ではありません。[2・3・6]
1.作業途中のメモリーが、不正な状態で扱われる
CVE-2026-109618は、PHPがメモリー不足で処理を中断したときの扱いに関係します。内部データの準備が終わる前に処理が止まり、後片付けの段階で、その不完全なデータが正しく用意されたものとして使われる場合があります。[2]
机の上で書類を分類している途中に作業が止まったのに、片付け係が「すべて分類済み」と思って次の処理を進めるような問題です。これは理解のためのたとえであり、実際にはメモリー管理の不整合です。単にサイトが重くなるだけの話ではなく、条件がそろうと外部からのコード実行につながります。
2.前の処理への参照が、次の処理に残る
CVE-2026-109619は、前のリクエストのためのメモリーが解放された後も、それを指す内部状態が処理担当のワーカーに残り、後のリクエストで使われる問題です。すでに片付けた書類の古い置き場所を、次の仕事でも参照してしまうイメージです。[3]
そのため、「自分のプラグインに怪しいコードを書いていないから関係ない」とは判断できません。PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHPの設置環境をリスクの対象として挙げています。構成によって攻撃が成立する条件は異なりますが、特定の動作方式だけの問題と決めつけないことが大切です。[1]
修正版の対応表:「8.4」だけでは判断できない
開発元が示す対象は、各系列の8.2.35未満、8.3.36未満、8.4.27未満、8.5.12未満です。8.1以前を使っている場合も対象外とは判断せず、配布元の修正状況を確認してください。[2・3]
事前予告の公開予定は10月21日23時(日本時間)でした。修正版は同日付で公開済みです。予告時刻と実際の配布開始時刻を取り違えないよう、本記事では配布開始の分単位の時刻は断定していません。[1・5]
まず、自分の環境の系列と、末尾まで含めた番号を確認します。下表はPHPプロジェクトが公開した上流版の修正番号です。Linux配布元やホスティング会社が修正を取り込む場合は、表示番号だけでなく、その事業者の適用情報も照合します。[1・6]
| 系列 / Branch | 今回の修正版 / Fixed release | 確認する点 / Check |
|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5という系列名だけで判断しない |
| PHP 8.4 | 8.4.27 | 例:8.4.21は上流修正版より前の番号 |
| PHP 8.3 | 8.3.36 | 配布元が提供する修正済みパッケージを確認 |
| PHP 8.2 | 8.2.35 | 更新とあわせて今後の移行計画も確認 |
| PHP 8.1以前 / Older branches | 通常の上流サポート対象外 | 配布元のバックポート対応か、対応系列への移行を確認 |
たとえば管理画面に「8.4」とだけ出ている場合、8.4系列を選んでいることは分かっても、8.4.27が実際に動いているかは分かりません。一方、配布元が修正だけを取り込む「バックポート」を行うケースでは、上流版と同じ番号にならないこともあります。「古い表示だから必ず未修正」「8.4を選んだから修正済み」と、どちらも早合点しないでください。
なお、PHP 8.2は2026年12月31日にセキュリティサポートを終える予定です。今回の緊急修正と、長期的にサポートされる環境へ移る計画は、あわせて考えたい点です。[8]
10月28日追記:修正版公開後の追加情報
この記事で扱う2件の修正版は、上の表のとおりです。その後、PHP公式は10月23日、セッションのアップロード進捗機能に関する追加の注意を公表しました。対象は、特定のセッション保存形式を設定したうえで、アプリケーションが実行中にその形式を切り替えるなどの条件が重なる構成です。公式は該当機能を一時的に無効にする対応を案内していますが、実行中に保存形式を変えないアプリケーションは有効のままにできるとも説明しています。自分の構成への該当性と対応は、管理担当者がPHP公式の10月23日付告知で確認してください。
また、10月26日にはWindows向け配布パッケージの8.5.12-1/8.4.27-1/8.3.36-1/8.2.35-1が公開されました。同梱するBrotliの脆弱性CVE-2026-111497に対応する再ビルドで、PHP本体の実行時バージョン番号は変わりません。Windows版を使う場合は、実行時の番号だけでなく配布パッケージも照合する必要があります。これは上記2件とは別の修正であり、すべてのOSに「-1」版が必要という意味ではありません。PHP公式の10月26日付告知に対象と条件が示されています。
まず自分の立場を確認:環境別の対応早見表
同じPHPでも、更新する担当者は契約や構成によって違います。次の表で自分に近い環境を選び、その後の共通手順で確認してください。クラウドを使っている場合も、仮想サーバーを自分で管理するのか、実行環境を事業者に任せるのかで対応が分かれます。
| 利用環境 | 最初にすること | 更新・反映を担当する人 |
|---|---|---|
| 共用レンタルサーバー・マネージドWordPress | 管理画面と契約先の公式セキュリティ情報を確認し、自分のサーバーへの適用状況を照合 | 主に事業者。利用者による系列の切り替えが必要かは案内を確認 |
| VPS・専用サーバー・クラウドの仮想サーバー | PHPの配布元と実行環境を確認。管理担当者が修正済みパッケージを適用 | 自分または委託先のサーバー管理者 |
| Dockerなどのコンテナー | PHPを含むイメージの修正版を確認し、再ビルド・再配置後の実行環境を検証 | イメージとアプリの運用担当者 |
| 事業者管理のクラウド実行環境・SaaS | 提供元の影響・修正情報と、利用者側の操作の有無を確認 | 契約上の管理範囲に応じて事業者と利用者 |
| 制作会社にサイト管理を委託 | 対象サイトを伝え、PHP本体の対応を誰が行うか確認 | 制作会社またはホスティング会社。窓口を一本化して結果を記録 |
| サイトの閲覧・サービス利用のみ | サービスの公式案内を確認。端末にPHPのパッチを入れる作業は通常不要 | サービス運営側 |
これは対応の担当を整理するための目安です。PHPを使っているか不明な場合は、分かる範囲で構成を確認し、提供元の案内を調べましょう。PHPはWordPress以外のCMSや製品内部でも使われます。[1・5]
PHPの確認から更新後の検証まで

確認から反映検証まで / Verification flow
1.実行中のPHPを確認
Check the running PHP version
↓
2.配布元・サーバー会社の修正情報と照合
Match vendor patch information
↓
3.修正の反映とサイトの動作を確認
Verify deployment and site operation
↓
4.確認日時と結果を記録
Record the result and time
Xypha作成の確認手順図。サーバー側の作業は契約先の案内に従ってください。
①「サイトヘルス」で実行中の番号を見る
WordPress管理画面の「ツール」→「サイトヘルス」→「情報」を開き、「サーバー」の項目でPHPバージョンを確認します。ここで見ているのは、WordPressが動いている環境の情報です。公開ページの見た目が変わらなくても、サーバー側の更新は行われるため、見た目だけで判断しないようにします。[7]
「64ビット値をサポートしています」という表示は処理環境についての説明であり、今回の脆弱性が修正済みであることを示す文言ではありません。問い合わせ用のメモには、末尾までのバージョン番号、確認した日時、対象ドメインを残しておくと照合しやすくなります。
②契約先が提供するPHPと修正状況を確認する
レンタルサーバーでは、利用者が系列を選び、実際の細かな更新やサーバー側の反映は事業者が管理することがあります。利用者が自由にPHP本体を入れ替えられるとは限りません。コントロールパネルと公式告知を確認し、不明なら契約先へ問い合わせます。
管理画面の項目名は事業者ごとに異なります。「PHP設定」「PHPバージョン」「実行環境」などを探し、ドメイン別の設定がある場合は対象を取り違えないようにします。特定企業の操作手順を他社へそのまま当てはめず、契約先の公式マニュアルを確認してください。
VPS・クラウド・コンテナーを自分で管理する場合
サーバー管理者は、PHPの配布元が提供する修正済みパッケージと、その適用方法を確認します。OSの配布パッケージ、外部リポジトリー、ソースからの導入などで更新方法は変わります。サーバーに合わない更新コマンドを一律に実行せず、配布元のセキュリティ情報に従ってください。[1]
コマンドラインのphp -vはPHPのバージョン確認に使えますが、そこで確認するのはそのコマンドが呼び出すPHPです。Webサイト側のPHP-FPMやApacheが別のPHPを使う構成もあるため、CLIの番号だけで公開サイトへの反映完了と判断しないでください。[9]
コンテナーでは、ホストOSのPHPを更新しても、イメージに含まれるPHPまで更新されたとは限りません。修正済みのベースイメージ・パッケージを取り込み、必要な再ビルドと再配置を行い、実際に稼働しているコンテナーで確認します。再起動だけで古いイメージが新しくなるわけではありません。[10]
③反映後に番号と動作を確認する
事業者から修正済みの案内を受けたら、対象サイトにも反映されたかを確認します。確認の記録は、「告知を見た」「設定を変更した」「実行環境で反映を確認した」に分けると、途中の作業を完了と取り違えにくくなります。
サイト側の確認では、トップページだけでなく記事、検索、フォームなど普段使う機能も見ます。独自開発や古いプラグインがあるサイトで系列を変更する場合は、バックアップと互換性の確認も必要です。修正の提供方法が分からないまま、複数の設定を次々と変更すると、原因の切り分けが難しくなります。
管理を任せている場合:問い合わせで確認する3点
ホスティング会社や制作会社が「メンテナンス実施」「修正版提供」と発表していても、自分の契約環境への適用、追加操作の必要性、動作確認はそれぞれ確認します。「修正版が選べる状態」と「自分のサイトで修正版が動いている状態」を区別することが大切です。
- 対象:自分のドメイン・サーバー・利用プランは影響と修正の対象か。
- 適用:2件とも修正済みか。利用者側で切り替えや再配置などが必要か。
- 確認:どの情報・表示・作業記録で適用を確認できるか。未完了なら完了予定と暫定対応は何か。
制作会社へ委託している場合は、WordPress更新だけでなく、PHP本体の更新を契約のどちら側が担当するかも確認します。一般の利用者は提供元の案内を確認し、サーバー操作は管理担当者に任せてください。
問い合わせるなら、次のように具体的に聞くと、必要な情報を整理できます。パスワードや認証コードを本文に書く必要はありません。
PHPの脆弱性CVE-2026-109618/CVE-2026-109619について確認したいです。対象は[ドメイン・サービス名・サーバー識別情報]、利用環境は[レンタルサーバー/VPS/クラウドなど]です。確認できたPHPの番号は[番号/不明]です。対象サーバーへの修正適用の有無、利用者側の切り替え・再起動などの作業が必要か、修正済みであることの確認方法を教えてください。
すぐ更新できないときと、一般の読者への影響
PHP公式は、完全な解決は更新であり、設定による暫定対策は特定の攻撃経路のリスクを減らすものにとどまると説明しています。単にエラー表示を隠したり、WordPressの保護プラグインを入れたりしただけで、PHP本体の修正が済むわけではありません。[1・3]
CERT-EUは、すぐに修正できない場合、修正と検証が終わるまでインターネットから到達するアプリケーションを公開ネットワークから隔離することを検討するよう勧めています。[6]
ここでいう停止は、見た目を「メンテナンス中」にするだけとは限りません。PHPでメンテナンス画面を表示しているなら、PHPへの処理は残ります。どこで通信を止めれば対象のPHPに届かなくなるのか、サーバー管理者と確認する必要があります。これは処理の流れから考えられる注意点です。共有サーバーの利用者が、自己判断でサーバー全体の設定を変える話ではありません。
一方、一般の読者がこのニュースを見たからといって、スマートフォンにPHPの修正プログラムを入れる必要はありません。今回まず対応が求められるのは、PHPでWebリクエストを処理するサーバーの管理側です。利用中のサービスが停止している場合は公式案内を確認し、不審な「復旧のためのログイン」案内などに認証情報を入力しないようにしてください。
まとめ
今回のPHPの脆弱性は、Webサイトの裏側で使うメモリー管理と内部状態に関わる問題です。修正版の公開と、自分のサイトへの適用完了を区別することが、対応の出発点になります。
まず自分がPHPを管理する立場か、事業者や制作会社に任せている立場かを確認し、実行環境と配布元の修正状況を照合しましょう。WordPressならサイトヘルスも確認に使えます。「WordPressは最新」「PHPは8.4」「メンテナンスの終了予定時刻を過ぎた」という情報だけで、安全と結論づけないことが大切です。更新が自分の権限でできない場合も、対象と番号を整理して問い合わせれば、次に必要な作業を確認できます。
出典・関連記事
以下は2026年10月22日に確認した一次資料と、10月28日に追加確認したPHP公式情報です。設定や対応状況は変わるため、作業時には各公式ページの最新案内も確認してください。
- PHP公式:重大なリモートコード実行の脆弱性と修正版(2026年10月21日)
- PHP開発元:CVE-2026-109618のアドバイザリー
- PHP開発元:CVE-2026-109619のアドバイザリー
- PHP Foundation:今回の修正とセキュリティ体制
- IPA:2026年10月21日の事前準備の呼びかけ
- CERT-EU:Critical Vulnerabilities in PHP
- WordPress公式:サイトヘルス画面
- PHP公式:サポート対象のバージョン
- PHP公式:コマンドラインのオプションとバージョン確認
- Docker公式:イメージの再ビルドとベースイメージの更新
テクノロジーの仕組みをさらに知りたい方は、量子計算の誤りを減らすGoogleの「魔法状態の培養」もどうぞ。こちらは今回のPHPとは別分野の、計算を支える技術の解説です。



コメント