PHPの脆弱性対策はどのバージョンに上げるべきか？WordPress運用の中小企業向けアップデート手順

2026年10月23日
情シス・IT担当
16View
0件

情シス・IT担当

1 はじめに — 高市首相が「うちは遮断しました」と述べた夜
- 1.1 この記事で扱うこと
2 1. PHPの緊急脆弱性で何が起きたのか
- 2.1 1-1. CVEとは何か
3 2. EOL（サポート終了）とは何か — 「動かなくなる日」ではなく「守られなくなる日」
4 3. 安全なPHPバージョンはどれか — 修正版とサポート期限の対応表
5 4. 「PHP 8にすれば安全」が誤りである理由
- 5.1 ディストリビューション提供版は「版数だけでは判断できない」
6 5. WordPressとPHPのバージョン兼ね合い — ここが中小企業の最大の関門
7 6. PHPバージョンの確認方法 — 10分で自社サーバの現状を把握する
8 7. OS別のPHPアップデート手順
- 8.1 7-1. Debian系（Debian 13 / php8.4-fpm）
- 8.2 7-2. RHEL系（Rocky Linux 9 / php-fpm 8.2）
9 8. CentOS 7 などサポート終了OSは「アップデート」では解決しない
10 9. アップデート時の注意点 — 中小企業で事故りやすい5点
11 10. どうしても即時更新できない場合の暫定緩和
12 11. 中小企業が今週やるべきこと（チェックリスト）
13 12. まとめ — PHPの脆弱性対策で本当に問われるのは「版数の管理」
- 13.1 参考情報（一次情報）
- 13.2 関連記事（社内）

はじめに — 高市首相が「うちは遮断しました」と述べた夜

2026年10月21日の夜、高市早苗首相が自身のSNSに次のように投稿しました。

「皆さまに今夜に対応していただきたい大至急のお願いです。多くのウェブサイトで使用されているPHPに関し、セキュリティチームが重大な2件の脆弱性に関する注意喚起を行っています」

これは、世界中のウェブサイトのおよそ7割で使われているプログラミング言語「PHP」に重大な欠陥が見つかったことを受けた警戒の呼びかけです。翌22日、官邸入りした首相は「各所ウェブサイトは大丈夫でしたか。うちは遮断しました」と述べ、首相官邸のホームページの公開を一時停止したことを明かしています。

影響は政府・自治体だけにとどまりません。京阪ホールディングスは21日午後9時ごろからホームページを一時的に休止し、JR西日本や大阪府のホームページでも検索機能などが一時停止しました。関西の企業や自治体でも、サイトを止める判断が相次いでいます。

出典: FNNプライムオンライン「高市総理が警戒呼びかけ「PHP」問題　世界7割のウェブサイトで使用のプログラミング言語に重大な脆弱性」（2026-10-22 17:39、2026-10-23参照） https://www.fnn.jp/articles/-/1137903

ここで大事なのは、止めたサイトの多くが「攻撃を受けたから止めた」のではないという点です。攻撃を受ける前に、被害を避けるために自分たちで止めています。裏を返せば、止めるべきかどうかを判断できるかどうかが、そのまま事業リスクになります。

この記事は、その判断と作業を、サーバ専任者がいない中小企業でも実行できる形に落とすことを目的としています。

まずは30分の無料相談で、自社サーバのPHP版数の確認から整理する（無料）

この記事で扱うこと

2026年10月21日、PHPプロジェクトは未認証のリモートコード実行（RCE）2件を含む緊急のセキュリティアドバイザリを公開しました。修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。

結論から書きます。安全条件は「PHP 8 にすること」ではなく、「今回の2件を修正した版以上にすること」です。同じ8.4系でも、8.4.24のままでは条件を満たしません。また、PHPを上げれば終わりではなく、OSのサポート期限とWordPressの対応バージョンが同時に絡みます。CentOS 7のようにOS自体のサポートが終了している環境では、PHPの更新だけでは解決せず、移行判断が必要になります。

本記事では、当社にご相談いただいた環境を例に、よく見られる3つの構成（サポート終了OS＋mod_phpのレガシー環境、Rocky Linux 9＋php-fpm 8.2、Debian 13＋php8.4-fpm）を取り上げ、現状の確認方法・目標バージョンの決め方・OS別の更新手順・事故らないための注意点を整理します。

（この記事の数値は、2026年10月23日時点で当社にご相談いただいた環境に対して php -v などのコマンドを実行して得た実測値と、PHP公式をはじめとする一次情報に基づいています。固有名詞・IPアドレスは記載していません。）

1. PHPの緊急脆弱性で何が起きたのか

まず、今回の事象を正確に押さえます。PHP公式サイトのアドバイザリ（2026年10月21日公開）によると、今回の脆弱性は次の2件です。

CVE	内容
CVE-2026-109618	メモリ枯渇（OOM）処理の不整合により、内部リクエストデータが部分初期化のまま残り、後続処理が不正なデータを有効なものとして扱う
CVE-2026-109619	リクエストが所有する内部状態がメモリ解放後も生存し、同一ワーカーの後続リクエストが初期化前の状態を参照する

いずれも未認証で到達できる点が重く、PHP公式は「Webリクエストを処理するすべてのPHPインストール」が影響範囲だと明記しています。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed のいずれも対象です。

とくに注意すべきは、mod_php が最高リスクとされている点です。アドバイザリは、アプリケーションのコードが動き出す前に未認証のリクエストで攻撃が成立する実証があるとしています。つまり「ログイン画面の外側」で攻撃が完結しうる、ということです。

出典: PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026-10-21、2026-10-23参照） https://www.php.net/archive/2026.php#2026-10-21-5

1-1. CVEとは何か

ここで「CVE」という言葉の意味を確認しておきたいと思います。ニュースや注意喚起を読んでいると必ず出てきますが、説明されないまま使われることが多い語です。

CVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）は、世界中で発見された情報セキュリティ上の脆弱性に付けられる共通の番号です。アメリカの非営利組織 MITRE が管理し、各国の製品ベンダーや調整機関が同じ番号体系で脆弱性を参照します。

番号の形は CVE-YYYY-NNNNN で、YYYY は採番された年、NNNNN は通し番号です。今回の CVE-2026-109618 なら「2026年に採番された109618番の脆弱性」という意味になります。

CVE が存在する理由は、同じ脆弱性が組織ごとに別の名前で呼ばれるのを防ぐためです。ベンダーが「A問題」と呼び、報道が「Bの欠陥」と書き、別の組織が「C事案」と呼んでいると、どれが同じものか分からなくなります。共通の番号があれば、社内の対応記録にも、ベンダーのサポート窓口とのやり取りにも、同じ識別子を使えます。

ここで混同しやすいのが、CVE は「識別子」であって「深刻度」ではないという点です。深刻度は別の仕組みで表します。代表的なものが CVSS（Common Vulnerability Scoring System） で、0.0〜10.0 の点数で深刻さを示します。CVE が「どの脆弱性か」を指すのに対し、CVSS は「どれくらい危険か」を表します。対応の優先順位を決めるときは、両方をセットで見る必要があります。

なお、今回の2件には PHP プロジェクトから GHSA（GitHub Security Advisory）の識別子も付けられています（CVE-2026-109618 が GHSA-w8hw-w9fx-j79w、CVE-2026-109619 が GHSA-6wmf-4rv5-p3rp）。同じ脆弱性が複数のデータベースに登録されることがあり、その場合は識別子が複数存在します。どれか1つを辿れば、同じ内容にたどり着けます。

国内では、JPCERT/CC が JPCERT-AT-2026-0033 として注意喚起を公開しています。CVE 番号から国内の注意喚起にたどり着けますので、社内の報告書には「CVE-2026-109618 / 109619、JPCERT-AT-2026-0033」と併記しておくと、後から経緯を追いやすくなります。

出典: JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（JPCERT-AT-2026-0033、2026-10-22公開・更新、2026-10-23参照） https://www.jpcert.or.jp/at/2026/at260033.html

JPCERT/CC の注意喚起では、対象バージョンが明示されています。PHP 8.5.12 より前の8.5系、8.4.27 より前の8.4系、8.3.36 より前の8.3系、8.2.35 より前の8.2系が対象です。そして「PHP 8.1 以前はアップデートバージョンが提供されないため、サポートされているバージョンへのアップグレードを推奨する」と書かれています。ここで出てくるのが EOL という概念です。

2. EOL（サポート終了）とは何か — 「動かなくなる日」ではなく「守られなくなる日」

EOL は End of Life の略で、ベンダーがその製品のサポートを終えた状態を指します。日本語では「サポート終了」「提供終了」と訳されます。

EOL について、実務で最も誤解されている点を先に書きます。EOL は「使えなくなる日」ではありません。 ソフトウェアは EOL を迎えても動き続けます。だからこそ厄介です。動いているように見えるので、危険になったことに気づけません。

EOL の本当の意味は、「脆弱性が見つかっても、ベンダーが修正版を出してくれなくなる日」です。今回の件に当てはめると、こうなります。

PHP 8.2 以降は、PHP プロジェクトが修正版（8.2.35 など）を出しました。だから更新すれば安全になります。
PHP 8.1 以前は EOL のため、PHP プロジェクトからの修正版が出ません。だから「更新する」という選択肢が存在しません。

PHP のサポート状況は、公式サイトで枝（8.2系、8.3系…）ごとに3段階で公開されています。

段階	意味
Active support	通常のバグ修正とセキュリティ修正の両方が提供される
Security support	セキュリティ修正のみが提供される（機能追加・通常のバグ修正は終了）
End of life	どちらも提供されない

この3段階を把握しておくと、「今はどの状態で、いつ危険側に転ぶのか」を自分で判断できます。今回でいえば、8.2系は 2026年12月31日でセキュリティサポートが終了します。つまり 8.2.35 に上げて当面の危険は避けられても、2か月後には再び「修正版が出ない枝」になります。これが、8.2系を「応急処置」と位置づけ、8.3以降への移行とセットで計画すべき理由です。

OSにもEOLがあります。 CentOS 7 は2024年6月30日にサポートが終了しました。OS が EOL になると、そのOS向けの新しいPHPパッケージは提供されません。前節で触れた「PHP 8.1 以前は更新できない」に加えて、OS側の理由でも更新できないという二重の制約が生まれます。これが第7節で扱う CentOS 7 の問題です。

EOL は「いつまで」を自分で確認する習慣が要ります。 PHP は php.net の Supported Versions ページ、OS は各ディストリビューションのリリースノートで確認できます。年1回ではなく、四半期ごとに3点（PHP・OS・CMS）の期限を眺めるのが現実的だと考えています。

出典: PHP公式「Supported Versions」（2026-10-23参照） https://www.php.net/supported-versions.php

3. 安全なPHPバージョンはどれか — 修正版とサポート期限の対応表

「どのバージョンに上げれば安全か」の答えは、修正版以上であること、そしてできるだけ長くサポートされる枝を選ぶことの2点で決まります。PHP公式のサポート期限と合わせて整理します。

選択肢	具体的な版	サポート期限（php.net 実測）	位置づけ
新規構築・移行先の第一候補	8.5.12	Active 2027-12-31 / Security 2029-12-31	最も長く維持できる
8.4系を運用中の最短解	8.4.27	Active 2026-12-31 / Security 2028-12-31	構成を変えずに安全化できる
8.3系を運用中	8.3.36	Security のみ 2027-12-31	早めに8.4／8.5へ移行したい
8.2系を運用中	8.2.35	Security 2026-12-31 終了	応急処置。移行計画が必須
8.1以前	公式更新の提供終了	EOL	更新では解決しない

ここで押さえるべき原則は3つです。

「8.5だから安全」ではありません。 8.5.12 未満の8.5系は条件を満たしません。
8.2系は2026年12月31日でセキュリティサポートが終了します。今回 8.2.35 へ上げても、数か月後には再び危険な状態になります。8.2系は「今を凌ぐ」ための選択であり、8.3以降への移行とセットで計画したいところです。
8.1以前は「更新」では解決しません。 PHP プロジェクトからの更新提供は終了しており、ソースビルドによる最小限のバックポートしか提供されません。ディストリビューション側の独自バックポートを待つか、バージョンアップ（＝OS移行）が必要になります。

4. 「PHP 8にすれば安全」が誤りである理由

実務で最も多い誤解が、「メジャーバージョンが新しければ安全」という理解です。しかし脆弱性対応はマイクロバージョン単位で行われます。

当社にご相談いただいた環境でも、次のような状態が実際に見つかりました。

8.4系で稼働しているが、版数は 8.4.24（修正版 8.4.27 未満）
同じく8.4系で 8.4.26（Debianのセキュリティリポジトリで提供されていた最新）
8.2系で 8.2.33（修正版 8.2.35 未満）

このうち 8.4.24 と 8.2.33 は、PHPの版数としては新しいのに、今回の2件を修正した版ではありません。つまり「PHP 8だから大丈夫」と判断すると、危険な状態を見逃します。

ディストリビューション提供版は「版数だけでは判断できない」

もう一つの落とし穴は、Debian や Red Hat が提供するPHPです。これらのディストリビューションは、PHPの版数を上げずにセキュリティパッチだけを backport する運用を取っています。そのため、php -v の表示が 8.4.26 のままで中身が修正済み、ということが起こります。

当社にご相談いただいた環境でも、次の2点は未確認として残りました。

Debian 13 の php8.4 8.4.26 が CVE-2026-109618 / 109619 を含むか（apt changelog が取得できず未確認）
Rocky Linux 9 の AppStream 8.2.35 が当該CVEを含むか（Red Hat のエラータ未確認）

したがって、更新後も「安全になった」と断定せず、ベンダーのセキュリティ情報（Debian Security Tracker、Red Hat のエラータ）で確認するという手順が必要になります。ここを飛ばすと、「更新したのに脆弱なまま」という最悪の状態を作ります。

5. WordPressとPHPのバージョン兼ね合い — ここが中小企業の最大の関門

PHPのアップデート可否は、WordPressのバージョンに強く制約されます。古いWordPressは新しいPHPで動きません。 当社にご相談いただいた環境では、次の組み合わせが見つかりました。

環境の類型	OS	Webサーバ	PHPの実行方式	PHP実測	WordPress実測	判断
A. レガシー環境	CentOS 7.9（EOL）	Apache 2.4.6	mod_php	5.4.16	4.9.26	最も危険。PHP更新だけでは不可
B. レガシー環境	CentOS 7.8（EOL）	Apache 2.4.6	mod_php	7.4.8	—	危険。8.x系リポジトリ無し
C. レガシー環境	CentOS 7.9（EOL）	Apache 2.4.6	mod_php	7.4.29	6.0	危険だが移行は比較的容易
D. 現行環境	Rocky 9.3	Apache 2.4.57	php-fpm	8.2.33	—	即時更新可（8.2.35）
E. 現行環境	Debian 13	nginx 1.26.3	php8.4-fpm	8.4.24	最新系	即時更新可（8.4.26）
F. 追従済み	Debian 13	nginx 1.26.3	php8.4-fpm	8.4.26	最新系	ベンダー待ち

ここから読み取るべき実務的な結論は3つです。

第一に、PHP 5.4 / WordPress 4.9 の組み合わせは「更新」では抜けられません。 WordPress 4.9系は PHP 8系で動作しないため、PHPだけ上げるとサイトが壊れます。逆にWordPressだけ新しくしても、PHP 5.4では最新のWordPressが動作しません。PHP更新とWordPress更新をセットで計画する必要があります。

第二に、mod_php は優先度を上げるべきです。 今回のアドバイザリが mod_php を最高リスクとしている以上、FPM環境と同じ優先度で扱うのは判断を誤ります。

第三に、現行環境（D・E）は「今すぐ安全化できる」ということです。8.2.35 や 8.4.26 への更新は、パッケージマネージャの操作で完結します。まずここを片付けてから、レガシー環境の移行に時間を割くのが合理的です。

6. PHPバージョンの確認方法 — 10分で自社サーバの現状を把握する

対策の第一歩は「自社の現状を知る」ことです。サーバにSSHログインできる前提で、次のコマンドを実行してください。推測で表を埋めず、実測値だけを記録するのがコツです。

調べたいこと	実行するコマンド
OSの種類とバージョン	`cat /etc/os-release`
PHPのバージョン（CLI）	`php -v`
実際にWebを処理している方式	`apachectl -M 2>/dev/null \	grep -i php `または` systemctl list-units –type=service \	grep -i php`
FPMのバージョン	`php-fpm -v`（Debian系は `php-fpm8.4 -v`）
WordPressのバージョン	`wp core version --allow-root`（WP-CLI）またはダッシュボードの「更新」画面
更新可能なパッケージ	Debian系: `apt list –upgradable \	grep php `/ RHEL系:` dnf check-update php\*`

重要な注意点: php -v は「コマンドラインで動くPHP」の版数を表示するだけです。Webサイトを処理しているのがPHP-FPMであれば、php-fpm -v の値が実態になります。当社にご相談いただいた環境でも、CLIとFPMで異なる版数が混在しているサーバが実在しました。「CLIとFPMの両方を確認する」を習慣にしたいところです。

7. OS別のPHPアップデート手順

ここからは、実際の更新手順です。いずれも作業前のバックアップが前提になります（第9節参照）。

7-1. Debian系（Debian 13 / php8.4-fpm）

# 1. 現状の確認とバックアップ
php-fpm8.4 -v
cp -a /etc/php/8.4 /root/backup_php84_$(date +%Y%m%d)

# 2. 更新可能なパッケージを確認
apt update
apt list --upgradable | grep php8.4

# 3. 更新（1台ずつ）
apt upgrade php8.4-cli php8.4-fpm php8.4-common

# 4. 反映と確認
php-fpm8.4 -v
systemctl reload php8.4-fpm

ポイントは1台ずつ更新することです。ロードバランサ配下であれば、片系を外して更新し、疎通確認後に戻します。またOPcacheが有効な環境では、FPMの再読み込みなしに新コードが反映されません。reload（またはrestart）を必ずセットで行います。

7-2. RHEL系（Rocky Linux 9 / php-fpm 8.2）

# 1. 現状確認
php -v

# 2. 更新可能か確認
dnf check-update 'php*'

# 3. エラータの内容を確認してから更新
dnf update 'php*'

# 4. 反映確認
php -v
systemctl restart php-fpm

注意点: Rocky 9 の AppStream が提供する 8.2.35 が、今回のCVEを修正済みかはエラータで確認が必要です。版数だけを見て「8.2.35だから安全」と断定しないでください。

8. CentOS 7 などサポート終了OSは「アップデート」では解決しない

ご相談いただいた中で最も重い問題が、CentOS 7 系のサーバ群でした。CentOS 7 は2024年6月にサポートが終了しており、PHP 8系の公式RPMが提供されていません。確認した範囲では、PHP 8系のサードパーティリポジトリ（remi-php8x）が存在しないことも確認しています。

つまり、これらの環境では「yum update php で上げる」という解決策が存在しません。選択肢は次の3つです。

OSごと移行する（推奨）: Debian 13 や Rocky 9 の新規ホストを立て、サイトを移設します。社内の標準構成（Debian 13 + nginx + php-fpm）に揃えれば、以降の運用が一段と楽になります。
サードパーティリポジトリの提供状況を再確認する: remi の EL7 サポート状況を確認し、後付けできるかを見ます。ただし確認した範囲では提供が無く、これに賭けるのは危険です。
暫定的に緩和する（根本解決ではない）: mod_php から php-fpm へ切り替え、次節の暫定設定を併用します。

判断の目安: WordPress 4.9系のように古いCMSが載っている場合は、1.（新規構築＋データ移行）が結果的に最短です。新しいホストで最新のWordPressを構築し、コンテンツとデータベースを移す流れになります。DNSの切り替えで元に戻せますので、作業自体は可逆です。

一方、WordPress 6.0系のようにPHP 8系で動くCMSであれば、OS移行の難易度は下がります。ただしCentOS 7のままではPHP 8系が入りませんので、結局はOS移行が必要になります。「CMSが新しいか」ではなく「OSがサポートされているか」が分岐点になります。

なお、PHP公式アドバイザリには、rpm.remirepo.net に依存している場合の注意も書かれています。ボランティア運営のリポジトリは当日中に更新が間に合わないことがありますので、ディストリビューションのパッケージに切り替えるか、ソースからビルドすることを勧めています。CentOS 7 で remi に頼っている環境は、この勧告にも該当します。

9. アップデート時の注意点 — 中小企業で事故りやすい5点

サーバ専任者がいない組織では、次の5点でつまずくことが多いです。

① SAPI（実行方式）の確認漏れ 前述のとおり、CLIとFPMで版数が違うことがあります。更新後は実際にWebを処理している方式の版数を確認します。

② バックアップ未取得のままの作業 最低限、次の3つを退避します。設定ファイル（/etc/php.ini、/etc/php-fpm.d/*、/etc/httpd/conf.d/php.conf）、インストール済みパッケージの一覧（rpm -qa > rpm_before.txt）、データベースのダンプ。撤回手段を確保してから作業するのが原則です。

③ 全台の同時更新 更新は1台ずつ、可能なら開発環境→本番環境の順で行います。PHP-FPMの再起動は数秒のリクエスト断を伴いますので、アクセスの少ない時間帯を選びます。

④ 同梱ツールの見落とし phpMyAdmin のようなPHP製ツールが同じサーバに入っていると、PHP更新で動作しなくなることがあります。更新前に一覧化し、別途検証します。

⑤ 表示だけの動作確認 管理画面ログイン、お問い合わせフォームの送信、プラグインの主要機能、画像アップロードまで確認します。PHPのバージョン違いは、画面上は正常に見えて裏でエラーを出していることがあります。エラーログ（/var/log/php-fpm/error.log 等）も必ず確認します。

10. どうしても即時更新できない場合の暫定緩和

「今日中には上げられないが、週末まで待てない」という場合、PHP公式が示している暫定策があります。ただしこれは根本解決ではなく、攻撃経路を狭めるだけである点を明確にしておきます。PHP公式自身が「更新のみが完全な解決策である」と書いています。

対策	設定	効果
メモリ枯渇処理の不整合を避ける	`memory_limit = -1` を `php_admin_value` で設定（アプリ側から上書きさせない）	CVE-2026-109618 の攻撃経路を塞ぐ
セッションアップロード進捗を無効化	`session.upload_progress.enabled=0` を php.ini / FPM プール設定で指定し、全ワーカーを再起動	CVE-2026-109619 の確認済み経路を塞ぐ
巨大リクエストを弾く	`post_max_size = 8M`（ファイルアップロードが不要な場合）	攻撃の足がかりを減らす
最高リスク構成を避ける	mod_php → php-fpm へ切り替え	アドバイザリが指す最高リスク構成から脱する

これらはあくまで時間を稼ぐ措置です。修正版への更新が完了した時点で、設定は元に戻すか、妥当な値へ見直します。

なお、JPCERT/CC は侵害調査の観点も示しています。不自然に長いPHPSESSID Cookie、不審な multipart/form-data リクエスト、PHPワーカーの予期しない異常終了や頻繁な再起動などです。更新前に攻撃を受けていた可能性を否定できない場合は、これらの痕跡を確認しておくことをお勧めします。

11. 中小企業が今週やるべきこと（チェックリスト）

最後に、実行順序を整理します。優先度の高い順に並べています。

優先	やること	判断のポイント
1	全サーバのPHP版数と実行方式（mod_php / php-fpm）を一覧化する	CLIとFPMの両方を実測する
2	mod_php で動いているサーバを特定する	アドバイザリが最高リスクと明記
3	現行OS（Debian 13 / Rocky 9 など）のサーバを修正版へ更新する	8.2.35 / 8.4.26 以上。ベンダーエラータを確認
4	サポート終了OS（CentOS 7 等）の移行計画を立てる	PHP更新では解決しないと認識する
5	WordPressのバージョンとPHP対応の関係を確認する	古いWPは新PHPで動かない
6	即時更新できない環境に暫定緩和を適用する	根本解決ではないと理解する
7	更新後、実際にWebを処理している版数と動作を確認する	表示だけでなくフォーム・管理画面まで