PHPに重大な脆弱性2件！影響範囲と修正版への更新方法は？

本ページはプロモーションが含まれています

PHPに重大な脆弱性2件！2026年10月21日に緊急アップデート

2026年10月21日、Webサイトで広く利用されているプログラミング言語「PHP」に、認証なしで遠隔からコードを実行されるおそれがある重大な脆弱性2件があるとして、PHP開発チームが緊急のセキュリティアップデートを公開しました。

対象となるのは、

CVE-2026-109618
CVE-2026-109619

の2件です。

いずれもCVSS v4.0で9.2（Critical）と評価され、PHP公式はすべての利用者へ直ちに更新するよう強く呼びかけています。完全な代替対策はなく、「更新が唯一の安全な選択」としています。

公開された修正版は次の4系列です。

PHP系列	修正版
PHP 8.5	PHP 8.5.12
PHP 8.4	PHP 8.4.27
PHP 8.3	PHP 8.3.36
PHP 8.2	PHP 8.2.35

PHP 8.2については2026年12月31日にPHPプロジェクトのサポート終了を迎える予定で、8.1以前はすでに公式サポートを終了しています。

WordPressを運営している人にとっても無関係ではありません。

今回の問題はWordPress本体や特定のプラグインだけに存在する脆弱性ではなく、WordPressを動かしているPHPそのものの脆弱性だからです。

PHPの脆弱性で何が危険？わかりやすく解説

今回特に危険視されているのは、攻撃者がログインIDやパスワードを持っていなくても、外部から細工した通信を送ることで、条件次第ではPHPが動作するサーバー上で任意のコードを実行できる可能性がある点です。

これをRCE（Remote Code Execution／リモートコード実行）と呼びます。

悪用された場合には、

サイトの改ざん
不正なプログラムの設置
サーバー上の情報へのアクセス
他のシステムへの攻撃の踏み台化
サービス停止

などにつながる可能性があります。

PHP公式によると、Webリクエストを処理するPHP環境全般が対象で、

PHP-FPM
Apache mod_php
php-cgi
FrankenPHP
LiteSpeed

などが影響範囲に含まれます。

特にApacheのmod_php環境では、アプリケーション側のコードが実行される前に認証なしで攻撃を成立させられることが実証されており、PHP公式はリスクが高いとしています。

CVE-2026-109618とは？

CVE-2026-109618は、PHPがメモリ不足などの異常状態を処理する際に、内部データが完全に初期化されないまま後続処理で利用される可能性がある問題です。

PHP公式では「RCE via OOM corruption」と説明しています。

簡単にいうと、

PHPが処理途中で異常終了した際、正常ではないメモリ状態を正常なデータとして扱ってしまい、メモリ破壊から任意コード実行につながる可能性がある

という脆弱性です。

CVSS v4.0は9.2で、認証なしの外部攻撃につながる可能性があります。

CVE-2026-109619とは？

CVE-2026-109619もPHP内部のメモリ管理に関する問題です。

PHP公式では「RCE via stale global state」と説明されています。

PHPが1つのWebリクエストを処理した後、本来リセットされるべき内部状態が残り、すでに解放されたメモリを後続のリクエストで参照してしまう可能性があります。

その結果、メモリ破壊や情報への不正アクセス、遠隔コード実行につながる可能性があります。

こちらもCVSS v4.0で9.2と評価されています。

PHP脆弱性の対象バージョンは？

PHP公式が今回修正版として公開したのは、

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

です。

したがって、同じ系列を利用している場合は、少なくとも次のバージョン以上であることを確認する必要があります。

利用中の系列	更新先
PHP 8.5.11以前	8.5.12以上
PHP 8.4.26以前	8.4.27以上
PHP 8.3.35以前	8.3.36以上
PHP 8.2.34以前	8.2.35以上

海外の公的サイバーセキュリティ機関では、PHP 5以降の広い範囲が影響を受けると案内されています。PHP 8.1以前についても影響を受けるものの、PHPプロジェクトによる通常の修正版提供は終了しています。

ただしLinuxディストリビューションやLTSベンダーでは、バージョン番号を大きく変更せず修正だけをバックポートする場合があります。

そのため、

「8.1だから絶対未修正」
「バージョン番号が古いから必ず危険」

とバージョン表示だけで断定するのではなく、OSやレンタルサーバーの提供元が今回のCVEへの修正を適用済みか確認することが重要です。

PHP 8.1はサポート終了！そのまま使い続けて大丈夫？

PHP 8.1は2025年12月31日でPHPプロジェクトによるサポートを終了しています。

つまり今回の脆弱性についても、php.netから「PHP 8.1.xの新しい通常リリース」が提供されるわけではありません。

PHP公式は、

PHP 8.1以前についてはLinuxディストリビューションやLTSベンダーによるバックポート修正の有無を確認するか、サポート中のPHPへアップグレードする

よう案内しています。

WordPressをPHP 8.1以前で運用している場合は、今回だけでなく今後の脆弱性対策を考えても、PHP 8.3以降など現在サポートされている環境への移行を検討した方がよいでしょう。

WordPressも今回のPHP脆弱性の影響を受ける？

WordPressをPHPで動かしている場合は影響を受ける可能性があります。

今回問題になっているのはWordPress本体ではなくPHPランタイムです。

そのため、

WordPress本体を最新版にしている
テーマを最新版にしている
プラグインをすべて更新している

という状態でも、サーバー上のPHP自体が未修正なら今回の脆弱性への対策が完了したとはいえません。

Cloudflareも、今回の問題はPHPランタイムそのものに存在するため、WordPressのコードやプラグインだけを更新しても修正できないと説明しています。

つまりWordPress利用者がまず確認したいのは、

「WordPressのバージョン」ではなく「そのWordPressを動かしているPHPのバージョンと修正状況」

です。

WordPressでPHPバージョンを確認する方法

WordPress管理画面から現在使っているPHPバージョンを確認できます。

手順は、

「ツール」→「サイトヘルス」→「情報」→「サーバー」→「PHPバージョン」

です。

WordPress公式ドキュメントでも、サイトヘルスからPHPバージョンを確認できると案内されています。

例えば、

PHP 8.4.27
PHP 8.3.36

などと表示されていれば、今回PHP公式が公開した修正版と同等以上のバージョンです。

ただし、レンタルサーバー独自のバックポート修正が行われている場合は、表示されるバージョン番号だけで判断できないケースもあります。

最終的には利用中のレンタルサーバー会社の公式発表も確認してください。

WordPressのPHPを修正版へ更新する方法

WordPress管理画面からPHP本体を直接アップデートすることは通常できません。

PHPの更新はレンタルサーバー側の管理画面またはサーバー管理者が行います。

共用レンタルサーバーの場合は、大きく2種類あります。

1つは、レンタルサーバー会社が8.4.26から8.4.27のようなパッチバージョン更新を自動適用するケース。

もう1つは、8.1から8.3などのPHP系列変更を利用者自身が管理画面から行うケースです。

まずレンタルサーバーの公式発表を確認し、今回のCVE-2026-109618・CVE-2026-109619への対応済みか確認してください。

PHPアップデート前にバックアップした方がいい？

PHP 8.4.26から8.4.27のようなセキュリティ修正レベルの更新で大きな互換性問題が起きる可能性は比較的低いものの、バックアップは取っておく方が安全です。

特に、

PHP 7.4→8.3
PHP 8.0→8.4
PHP 8.1→8.3

など、メジャー・マイナー系列をまたぐ変更では注意が必要です。

古いテーマやプラグイン、独自PHPプログラムなどが新しいPHPへ対応しておらず、

画面が真っ白になる
500エラーが出る
管理画面へ入れない
フォームが動かない

といった不具合が起きる可能性があります。

WordPress公式も、PHP変更前にテーマやプラグインの対応状況を確認するよう案内しています。

更新前には、

WordPress本体
テーマ
プラグイン
データベース
ファイル

のバックアップを取得しておくと安心です。

エックスサーバー利用者はどう確認する？

エックスサーバーでは「サーバーパネル」から、

PHP Ver.切替

を開くことで、ドメインごとのPHPバージョンを確認・変更できます。

エックスサーバーは10月9日の時点で、10月19日にPHP 8.2～8.5を、

PHP 8.5.11
PHP 8.4.26
PHP 8.3.35
PHP 8.2.34

へ更新すると告知していました。

しかし今回の修正版が公開されたのはその後の10月21日です。

したがって、10月9日の古い告知だけでは現在の今回の脆弱性への対応状況を判断できません。

緊急更新や独自パッチが適用される可能性もあるため、最新のエックスサーバー公式のお知らせと、現在表示されるPHPバージョンを確認することが重要です。

ロリポップ利用者はどう確認する？

ロリポップでは、

ユーザー専用ページ→サーバーの管理・設定→PHP設定

から各ドメインのPHPバージョンを確認できます。

変更したいPHPを選択して「変更」を押すと、通常5～10分程度で反映されます。

ロリポップはPHP 8.3以上でのWordPress運用を推奨しており、PHP 8.1以前は公式サポートが終了しているとして、新しいPHPへの更新を呼びかけています。

ただし今回のCVEについては、単に8.3を選択すればよいのではなく、PHP 8.3.36相当の修正が提供側で適用済みか確認する必要があります。

さくらインターネットは対応中

さくらインターネットは2026年10月22日、今回のCVE-2026-109618・CVE-2026-109619について公式発表を行いました。

10月21日22時30分から予防的な緊急メンテナンスを行い、セキュリティリリース公開後は対象システムへ修正版を順次適用しているとしています。

さくらのレンタルサーバーでは、

サーバーコントロールパネル→スクリプト設定→言語バージョン設定

からPHPバージョンを変更できます。

共用サーバーの場合は利用者自身がPHPをソースからインストールするのではなく、まず提供会社の対応状況を確認することが重要です。

VPS・専用サーバーの管理者はどう更新する？

VPSやクラウド、専用サーバーなど、自分でOSとPHPを管理している場合は、レンタルサーバー会社が自動的に対応してくれるとは限りません。

PHP公式は、LinuxディストリビューションやLTSベンダーにも事前に修正情報を提供しているため、各OSベンダーが提供する修正済みパッケージを利用するよう案内しています。

そのため、

PHP公式のソースを独自ビルドしている場合
OS標準パッケージを使っている場合
cPanelなどの管理環境を利用している場合

で手順が異なります。

特にOS標準PHPでは、PHP公式のバージョン番号と一致しなくても、ディストリビューション側が修正をバックポートしていることがあります。

そのため「php -vの数字だけ」でなく、OSベンダーのCVE対応状況を確認してください。

PHPを更新できない場合はどうする？

PHP公式は、今回について完全な代替策はなく、更新が唯一の安全な選択としています。

WAFやアクセス制限などはリスク低減には役立ちますが、脆弱性そのものが消えるわけではありません。

すぐ更新できない場合は、

外部公開を一時的に制限する
Webサイト・サービスを一時停止する
WAFを有効にする
不要な機能へのアクセスを制限する
修正版を適用できる環境へ移行する

といった暫定対応を検討します。

高市早苗総理も10月21日夜、自身のXでPHPを利用しているWebサイトを確認し、修正パッチを速やかに適用するよう呼びかけました。

また、すぐに適用できない場合について、Webサイトを一時停止することもリスク低減策の一つだと説明しています。

高市総理自身の公式サイトについても、対策のため一時的に遮断したと報じられています。

IPAもPHP利用状況とアップデート確認を呼びかけ

IPA（情報処理推進機構）は、正式な修正版公開前の2026年10月21日から異例の事前注意喚起を行いました。

PHPを利用している製品やWebサイトについて、提供元のセキュリティ情報を確認し、修正版公開後に速やかに対応できるよう準備するよう求めています。

IPAは事前注意喚起の時点では、

今回の2件を実際に悪用した攻撃をIPA自身が確認しているわけではない

とも説明していました。

一方、修正版公開前後には状況が変化しています。

PHP脆弱性を狙った攻撃はすでにある？

今回について「脆弱性が発見されただけなのか」「実際に攻撃されているのか」も重要です。

Cloudflareは、公開前から今回の脆弱性に対するWAF保護を展開し、その後顧客を標的にした攻撃トラフィックを観測したと発表しています。

一方、カナダのCyber Centreは、PoCが公開されているものの、10月21日時点では「active exploitation」を確認していないとしています。

これは矛盾するように見えますが、

攻撃を試みる通信が観測されたこと

と、

実際にサーバー侵害に成功した攻撃が広範囲で確認されたこと

は別です。

2026年10月22日時点で、今回のPHP脆弱性によって日本国内で大規模な個人情報漏えいが発生したと確認できる公式発表はありません。

ただし攻撃試行が観測されている以上、「まだ被害報告がないから更新しなくてよい」と考えるのは危険です。

国内では緊急メンテナンスやサービス停止が相次ぐ

今回の脆弱性を受け、日本国内でもWebサイトやサービスの一時停止が相次ぎました。

例えば、さくらインターネットは10月21日22時30分から一部サービスの予防的な緊急メンテナンスを実施しました。

バッファローも10月22日未明から一部Webサイト・サービスを一時停止し、修正と安全確認を進めています。同社は現時点で今回の脆弱性に起因する不正アクセスや情報漏えいは確認していないとしています。

LINE WORKSも自社Webサイトについて10月22日5時54分までに修正を完了し、それまでに今回の脆弱性を悪用した不正アクセスは確認していないと発表しています。

つまり、サイトやサービスが停止したからといって、

「すでに攻撃されて情報漏えいした」

という意味ではありません。

被害を防ぐため、予防的に停止している企業もあります。

自分のサイトが攻撃されたか確認する方法は？

PHPを修正した後は、「更新できたから終了」ではなく、修正前に侵入されていなかったかを確認するとより安全です。

特に確認したいのは、

見覚えのないファイルが増えていないか
WordPressに知らない管理者アカウントが作られていないか
テーマやプラグインのファイルが勝手に変更されていないか
アクセスログやエラーログに不審な記録がないか
サーバーから見覚えのない外部通信が発生していないか
不審なPHPファイルやスクリプトが設置されていないか

といった点です。

実際にAmiVoiceの運営会社も今回の対応後、Webサーバーのファイル改ざん、不審ファイル、アクセス・エラーログ、不審な外部通信、管理者アカウントなどを調査したと公表しています。

個人のWordPressサイトで判断できない場合は、レンタルサーバー会社やサイト管理者へ相談した方がよいでしょう。