PHPに緊急の脆弱性2件（2026年10月）WordPressサイトで今日やること

「WordPressは最新にしてあるのに、サーバー会社から緊急のお知らせが届いた」。2026年10月21日（UTC）、PHPの開発チームが深刻度Criticalの穴2件を直した新しい版を出しました。直す場所はWordPressではなく、その下で動いているPHP本体です。クライアントから預かっている制作会社が今日の対応として確かめるのは、預かり先ごとのPHPのバージョンを確かめ、修正版に入れ替わったかを見届けることです。この記事では、何が起きたかをたとえで押さえたうえで、確認の手順と、サーバーの種類ごとの動き方をまとめます。

WordPressの下で動くPHP本体に、穴が2つ見つかった

今回の問題はPHP本体にあり、ログインしていない第三者がサーバー上でプログラムを動かせるおそれがあります。ポイントは2つです。

2件とも、ログインなしに外からのリクエストで狙える穴（mod_phpでは1回のリクエストで攻撃できることが実証済み）
WordPressやプラグインの更新では直らない

PHP公式サイトの2026年10月21日のセキュリティ発表。PHPの脆弱性CVE-2026-109618とCVE-2026-109619と修正版の一覧 — PHP公式の発表。冒頭の太字に修正版の番号、Who is at risk に対象の動かし方が並ぶ（出典：php.net、2026年10月22日撮影）

厨房の料理人と、レシピ本のたとえ

レストランでたとえると、PHPは厨房の料理人、WordPressはその料理人が読むレシピ本です。今回見つかったのは、料理人の手順そのものの欠陥でした。どちらも、ふだんは出ず特定の状況でだけ表に出ます。ひとつは、作業台がいっぱいになって手が止まったとき、作りかけの皿を中身を確かめずにいつもの手順で片づけようとして思わぬ場所に手を突っ込む欠陥。もうひとつは、捨てたはずの注文票の置き場所メモだけが残り、その場所にいま置かれている別の紙を注文票として読んでしまう欠陥です。その紙は、客が紛れ込ませたものかもしれません。レシピ本をいくら新しくしても、料理人の手順は直りません。

技術的には次の2件です。名前と内容はPHP公式のセキュリティ発表に載っています。CVSSの値は、PHPの開発チームがGitHubで出した勧告（CVE-2026-109618・CVE-2026-109619）に載っています。

番号	何が起きるか	たとえ
CVE-2026-109618	メモリ不足で処理が途中で止まり、作りかけのデータを後始末で正しいものとして扱ってしまう	作りかけの皿を、中身を確かめずにいつもの手順で片づける
CVE-2026-109619	解放したはずのメモリを指す状態が残り、同じワーカーの後続のリクエストが、その場所にある別のデータを正しい状態として使ってしまう	捨てた票の置き場所に置かれた別の紙で料理を作る
共通	深刻度Critical、CVSS 4.0の基本値9.2。認証なしで遠隔からコードを実行されるおそれ	客席から厨房を操られる

WordPressやプラグインを更新しても直らない理由

直すべき場所はPHP本体なので、WordPressの管理画面からは手が届きません。 WordPressの更新ボタンが入れ替えるのは、WordPress本体とテーマとプラグインのファイルだけです。PHPはその外側、サーバーに入っているプログラムです。

公式発表によると、mod_php（Apacheに組み込む方式）では、アプリのコードが動く前に攻撃できることが実証されています。つまりWordPressがどれだけ堅くても、その手前で入られる余地があるということです。

自分のサイトのPHPバージョンを確かめる3つの方法

確かめる場所は3つあり、最初の2つで足ります。

サーバー会社の管理画面
WordPressのサイトヘルス
レスポンスヘッダー（補助として）

サーバー会社の管理画面で見る

レンタルサーバーなら、管理画面にPHPのバージョンを選ぶ設定があります。ここで見えるのは「8.3」のような系列だけのこともあり、その場合は末尾の番号まではわかりません。系列の中身が修正版に入れ替わったかは、サーバー会社のお知らせで確かめます。

WordPressのサイトヘルスで見る

末尾の番号まで見るなら、WordPressの管理画面が手軽です。「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」を広げると、PHPのバージョンが末尾の番号まで出ます。画面の場所はWordPress公式のサイトヘルス解説にもあります。8.3系なら8.3.36以上、8.4系なら8.4.27以上が修正版です。ただし、VPSなどで配布元のパッケージを使っている場合は、修正済みでも元の番号のまま表示されることがあります。その場合は番号ではなく、配布元のセキュリティ情報でパッケージの版を確かめてください。

レスポンスヘッダーで見る（出ていれば）

PHPは設定によって、応答に X-Powered-By という見出しを付けてバージョンを名乗ります。ターミナルで curl -sI を使うと、ページを開かずに見出しだけを取れます。

curl -sI でtsudzuri.comのレスポンスヘッダーを確認し、PHPのX-Powered-Byが出ていないことを見た実行結果 — 自サイトの見出しを取り出した実行結果。Server は cloudflare で、X-Powered-By の行は0件（2026年10月22日）

私のサイト（tsudzuri.com）は、PHPを使わずCloudflare Workers上で動いています。実際に確かめると、サーバーを名乗る見出しは Server: cloudflare だけで、X-Powered-By は1行も出ません。ただし逆は成り立たないので注意してください。PHPのサイトでも、expose_php を切っていれば名乗りません（PHPマニュアル）。出ていないから安全、とは読まないでください。

今日やること：サーバーの種類で動き方が変わる

誰がPHPを更新するかは、サーバーの種類で決まります。まず預かっているサイトとサーバーの一覧を作り、次の表で振り分けます。

サーバーの種類	PHPを更新する人	今日やること
レンタルサーバー（共用）	サーバー会社	お知らせで修正の済んだ日時を確かめ、サイトヘルスで番号を見る
マネージド型のWordPress	サービスの運営会社	お知らせを確かめ、選べるPHPの系列と番号を見る
VPS・専用サーバー	自社か保守の担当者	パッケージを更新し、PHPのワーカーをすべて再起動して番号を見る
コンテナ（Dockerなど）	自社か保守の担当者	元にするイメージを修正版に上げ、作り直して入れ替える

PHPの脆弱性に対応するときの今日やることの順番。サイトの洗い出しからPHPバージョン確認、修正版への更新、応急処置、7.4〜8.1の移行まで — 預かり先が多いときは、1の一覧づくりから。番号の確認は更新の前と後の2回行う

レンタルサーバー・マネージド型

更新するのはサーバー会社です。こちらでやるのは、お知らせを読んで修正の済んだ日時を控えることと、サイトヘルスで番号を確かめることです。古い系列（7.4など）を選んだままのサイトは、サーバー会社が修正を入れるとは限りません。サポートされている系列へ切り替える前に、テーマとプラグインが動くかをテスト環境で見ます。

VPS・専用サーバー・コンテナ

自分たちで更新します。OSのパッケージを使っているなら、配布元のセキュリティ情報を見てください。公式発表によると、Linuxの配布元にはパッチが事前に渡されています。配布元のパッケージは、元の番号のまま修正だけを取り込むことがあるため、番号だけで判断しないことが大切です。更新後はPHP-FPMなど、PHPを動かしているワーカーをすべて再起動します。

すぐ更新できないときと、サポートが終わった版の扱い

完全な解決策はアップデートだけで、応急処置は攻撃の入口を減らすにとどまります。 ここでは2つの場面に分けて書きます。

今日中に更新できないサイトの応急処置
7.4〜8.1を使い続けているサイト

今日中に更新できないときの応急処置

公式発表は、更新までのつなぎとして設定の変更を挙げています。主なものは次のとおりで、1と2はCVE-2026-109618向け、3と4はCVE-2026-109619向けです。片方の対策だけでは、もう片方の経路は防げません。

memory_limit を、アプリから上書きできない方法で -1 にする（制限を外す。値を下げるのではない）
post_max_size を小さくし、Webサーバー側でもリクエストの大きさや項目数を制限する
session.upload_progress.enabled を 0 にして、すべてのワーカーを再起動する（ini_set() や .user.ini では足りない）
PHP 8.5なら fatal_error_backtraces を 0 にして再起動する

PHP公式発表の If you cannot update immediately の節。脆弱性ごとの緩和策の一覧 — 公式発表の緩和策。冒頭で「完全な解決策は更新だけ」と念を押している（出典：php.net、2026年10月22日撮影）

報道では、Cloudflareを経由しているサイト向けに、CloudflareがWAF（不正な通信を止める仕組み）で既知の攻撃経路を止めるルールを無料プランを含めて配ったとされています（Help Net Security）。Cloudflareを通していないサイトには効きません。通していても、入口を減らすだけです。

7.4〜8.1は「特例の修正」で、移行は避けられない

7.4・8.0・8.1は、すでにPHPの公式サポートが終わった版です。今回は深刻さを踏まえて、公式のセキュリティチームが最小限の修正をソースコードで用意しました。とはいえ、これは自分でPHPを組み立てる人向けの特例です。レンタルサーバーでこの系列を選んでいるサイトに、自動で届くとは限りません。利用者としては、サポート中の8.2以上の系列（できれば8.3以上）へ切り替えるのが対応です。

WordPressの推奨は、PHP 8.3以上です（WordPress公式の動作環境）。8.2も、2026年12月31日でセキュリティ修正が終わります（PHPのサポート期間の一覧）。8.2以下のサイトは、今回の修正とは別に、上の系列へ移す予定を年内に立ててください。

更新の担当と頻度を見直す、という選択肢

今日の対応が済んだら、預かっているサイトの数だけ同じ作業が毎回発生する体制を見直す価値があります。WordPressを使う場合、PHPの更新は保守契約の中で回す定常作業になります。どの構成でも、何かの更新は続くんです。レンタルサーバーでPHPの更新をサーバー会社が引き受けている場合は、今の体制で十分回ります。

私のサイトはEmDashというCMSで、PHPを使っていません。今回のPHPの件で、自サイトの作業はありませんでした。ただし、更新がゼロになるわけではありません。使っているライブラリ（npmパッケージ）の脆弱性の通知は届くので、その確認と更新は私の仕事として残っています。サーバー機の面倒を見る作業が消え、ライブラリの更新が残る。この差はサーバー保守を抱えたくない制作会社へでまとめました。

EmDashがPHPに依存しない理由はPHPの脆弱性とEmDashの関係で、EmDash以外も含めた選び方はPHPに依存しないCMSの選び方で書いています。移すかどうかは、更新の頻度や、誰が保守を受け持つかで決まります。今日の修正を飛ばして移行で済ませる、という順番にはしないでください。

よくある質問

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

大丈夫ではありません。今回の修正はPHP本体に入るもので、WordPressの更新では入りません。サイトヘルスでPHPの番号が修正版になっているかを見てください。

アクセスの少ない小さなサイトでも狙われますか

狙われる前提で動いてください。攻撃はログイン不要で外からのリクエストで狙えるとされ（mod_phpでは1回のリクエストで実証済み）、サイトの大きさは関係しません。お問い合わせフォームしかないサイトでも、PHPで動いていれば対象です。

X-Powered-Byが出ていなければPHPではないのですか

そうとは限りません。PHPは初期設定では名乗りますが、設定で消しているサイトや、CDNなど手前のサーバーで消えているサイトもあります。本当にPHPかどうかは、サーバー会社の契約内容かサイトヘルスで確かめてください。

まとめ

PHPの更新を確実に回しつつ、体制ごと軽くしたい。そう考えたときは、綴に相談してください。WordPressからEmDashへの引っ越しも、EmDash以外のPHPに依存しないCMSへの移行もお手伝いできます。進め方はWordPressからの移行支援に書いています。預かっているサイトの数や更新の担当が決まっていなくても、状況を聞かせてもらえれば一緒に整理できるので、お問い合わせから連絡してください。

本記事は2026年10月時点の情報です。