【PHP重大脆弱性】修正版8.4.27等公開|対象と今すぐやる更新

PHPのセキュリティ修正版が2026年10月21日23時(日本時間)に公開予定であることを示した図。重大な脆弱性2件でCVSS v4.0 9.2 — 図: PHP公式の告知をもとに筆者が作成

PHPの開発チーム(PHPセキュリティチーム)は、重大な脆弱性2件を修正するセキュリティリリースを、予告どおり2026年10月21日に公開しました。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。2件とも認証なしでリモートからコードを実行される可能性がある脆弱性で、PHP公式は「すべてのPHPユーザーは直ちに更新を」と呼びかけています。

この記事では、公開された内容(対象・修正版・更新方法)と、レンタルサーバー・VPS・自前サーバー・WordPress利用者それぞれが何をすればよいかを、PHP公式の発表をもとに整理します。

2026年10月21日23時すぎ更新: 修正版が公開されました

・上げる先のバージョン: 8.5系は8.5.12、8.4系は8.4.27、8.3系は8.3.36、8.2系は8.2.35

・レンタルサーバー: 自分でPHP本体は更新できないのが一般的。事業者の対応告知を確認し、案内に従う(エックスサーバー等の告知も要確認)

・VPS・自前サーバー: パッケージを更新し、PHP-FPMやApacheを再起動。Ubuntuには修正パッケージが公開済み(USN-8948-1)

・WordPress利用者: PHP本体の問題なので、WordPressの更新では直りません。PHPを更新できるのはサーバーの管理者(事業者)です

・PHP 8.1以前: 本家の更新はありません。OSや事業者の修正パッケージを確認するか、サポート中の系統へ移行します

・完全な緩和策はなく、更新だけが安全な対処です(PHP公式)

PHPの修正版一覧。8.5は8.5.12、8.4は8.4.27、8.3は8.3.36、8.2は8.2.35に更新する。8.1以前は本家の更新なし — 図: php.net News Archive 2026(2026年10月21日)をもとに筆者が作成

この記事の要点

・CVE-2026-109618(メモリ不足の処理に起因)とCVE-2026-109619(古い内部状態の残留に起因)の2件。どちらも認証不要のリモートコード実行につながり得る

・対象はWebリクエストを処理するすべてのPHP(PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed)

・mod_phpが最もリスクが高いとPHP公式。アプリのコードが動く前に攻撃が成立する実証があるとのこと

・修正版は8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。Linuxディストリビューションの更新パッケージも確認する

・8.1以前は本家の更新なし。ディストリのバックポートか、ソースビルド向けの最小バックポートが提供される

・暫定策はあるが「攻撃経路の一部を減らすだけ」で、安全にはならない。更新が唯一の完全な対策

すぐ更新できない場合の暫定策(安全にはなりません)

エックスサーバー・BASEの停止はPHPが原因?

自分のPHPのバージョンの確認とサポート状況

対象は?PHP公式が公表した内容

PHP公式は、2026年10月21日付のセキュリティ告知「Security advisory: Critical remote code execution vulnerabilities, update now」で、対象と脆弱性の概要を公表しました。PHP公式の告知の要点は次のとおりです。

脆弱性1: RCE via OOM corruption(メモリ不足に起因する破損)

・CVE-2026-109618(GHSA-w8hw-w9fx-j79w)

・メモリ不足の処理が、内部のリクエストデータが中途半端に初期化された状態のPHPを中断させることがある。その後のリクエスト後片付けで、不正なデータが正しいものとして扱われる可能性がある

脆弱性2: RCE via stale global state(古いグローバル状態の残留)

・CVE-2026-109619(GHSA-6wmf-4rv5-p3rp)

・リクエスト用の内部状態が、裏のメモリが解放されたあとも残ることがある。同じワーカーが処理する次のリクエストが、通常の初期化で消される前にその古い状態を使ってしまう可能性がある

どちらも、認証なしのリモートコード実行につながり得る重大な脆弱性です。予告時点でPHP公式が示していた深刻度は、2件ともCVSS v4.0で9.2でした。

誰が対象か

・Webリクエストを処理するすべてのPHP環境が対象

・具体的には、PHP-FPM、Apache(mod_php)、php-cgi、FrankenPHP、LiteSpeedを含む

・リスクが最も高いのはmod_php。アプリケーションのコードが動く前に、認証なしのリクエストだけで攻撃が成立する実証があるとPHP公式は説明しています

修正版とサポート状況

・PHP 8.5系: 8.5.12

・PHP 8.4系: 8.4.27

・PHP 8.3系: 8.3.36

・PHP 8.2系: 8.2.35(8.2は2026年12月31日でセキュリティ修正も終了するため、移行計画が必要)

・PHP 8.1以前: PHPプロジェクトからの更新は出ません。一部のディストリビューションやLTSベンダーが修正をバックポートしています。また、PHPセキュリティチームは、ソースからビルドする人やLTSベンダーを使えない人向けに、PHP 7.4、8.0、8.1の最小限のソースバックポートを提供したとのことです

修正版のソースは、PHP公式のダウンロードページから入手できます。Windows向けのソースとバイナリも同じページにあります。Linuxディストリビューションやサポートベンダーには、パッチが事前に提供されているため、各ベンダーの更新パッケージを確認してください。

なお、有志が運営するrpms.remirepo.netについては、PHP公式が「当日は更新が出ない」と明記し、ディストリビューションのパッケージへの切り替えか、ソースからのビルドを促しています。Remiリポジトリを使っている場合は、この点に注意してください。

予告から修正版公開までの流れ

PHP公式は10月20日に「Upcoming Critical PHP Security Release(重大なPHPセキュリティリリースの予告)」を掲載し、2026年10月21日(水)14:00 UTC(日本時間23:00)にリリースすると予告していました。詳細が公になった場合や悪用の証拠が出た場合は前倒しもあり得る、とも書かれていました。予告の原文はこちら。

PHPの修正版公開までの流れを示した時系列の図。10月20日にPHP公式が予告、10月21日13時1分に国家サイバー統括室が注意喚起、夕方に一部サービスが予防的に停止、23時に修正版公開予定 — 図: PHP公式・国家サイバー統括室(X)・各社告知をもとに筆者が作成

日本の政府系の発信もありました。国家サイバー統括室(注意・警戒情報)の公式X(@cyber_forecast)は、10月21日13:01に次のように投稿しています。

PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。公開しているウェブサイトでPHPを使用しているか確認し、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いいたします。

国家サイバー統括室(注意・警戒情報) @cyber_forecast / 2026年10月21日 13:01(日本時間)　投稿を見る

10月21日、PHP公式は8.5.12、8.4.27、8.3.36、8.2.35のリリースと、上記のセキュリティ告知を公開しました。Ubuntuも同日にPHPの修正パッケージとセキュリティ告知(USN-8948-1)を出しています。

今やること(環境別)

使っている環境によって、やることは大きく違います。自分がどれに当てはまるかを確認してください。まず、更新が必要な「PHPを動かしているサーバー」を管理している人は、できるだけ早く更新します。

環境別に今夜やることをまとめた図。レンタルサーバー、VPS・自前サーバー、WordPress等のCMSの3つに分けて示している — 図: 公式告知をもとに筆者が整理(対象有無の確定情報ではありません)

1. 自分のサイトがPHPで動いているか確認する

WordPress、拡張子が.phpのページ、PHPで作られた既製・自作のアプリなどが目安です。契約中のサーバーの管理画面に「PHPバージョン」の設定があれば、PHPが使える環境です。分からない場合は、サーバー事業者のマニュアルで確認してください。

2. レンタルサーバーの利用者: 事業者の対応告知を確認する

共用のレンタルサーバーでは、PHP本体の更新は事業者側で行われるのが一般的で、利用者が自分で本体を更新することはできません。利用者にできるのは、利用中の事業者(エックスサーバー、ロリポップ、さくら、ConoHa WINGなど)の障害・メンテナンス・セキュリティ関連のお知らせを確認し、案内があればそれに従うことです。管理画面にPHPバージョンの切り替え機能がある場合は、案内に従って、サポート中の系統(8.2〜8.5)にしておきましょう。エックスサーバーは、この件に関連するメンテナンス告知が出ているため、公式の最新の案内を確認してください。

3. VPS・自前サーバーの管理者: パッケージを更新して、PHPを再起動する

自分でサーバーを管理している場合、更新は自分の作業です。Ubuntu・Debian系はapt、RHEL系はdnfで更新するのが一般的ですが、修正版がリポジトリに反映されているかは、ディストリビューションごとに違います。反映状況は各ディストリビューションのセキュリティ情報で確認してください。更新後は、PHP-FPMやApache(mod_php)のプロセスを再起動し、新しいコードで動かします。

Ubuntuの場合の例です(PHPのバージョン部分は自分の環境に合わせて読み替えてください)。

php -v
sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Ubuntuでは、PHP公式のバージョン番号(8.3.36など)ではなく、Ubuntu独自のバージョン表記で修正が配られます。確認できた範囲では、Ubuntu 22.04 LTS(jammy)のphp8.1は8.1.2-1ubuntu2.28、24.04 LTS(noble)のphp8.3は8.3.6-0ubuntu0.24.04.13が、セキュリティ更新としてUSN-8948-1で公開されています。このため、更新後も「php -v」の表示が8.1.2や8.3.6のままのことがあります。パッケージのバージョン(dpkg -l | grep php)と、Ubuntuの告知ページを照らして確認してください。

dpkg -l | grep -E “^ii +php”
apt changelog php8.3 | head -20

PHP-FPMとApache以外(FrankenPHP、LiteSpeedなど)を使っている場合も、更新したPHP本体を使うプロセスを再起動する必要があります。Webサーバーの運用手順に従ってください。

4. WordPressなどのCMS利用者: PHP本体の更新が必要

今回はPHP本体の脆弱性です。WordPress本体やプラグインを更新しても、この問題は直りません。サーバー側のPHPが修正版になる必要があります(詳しくは次の見出し)。

5. PHP 8.1以前を使っている人は特に注意

PHPプロジェクトからの更新は出ません。使っているOSのバックポート更新(Ubuntu 22.04のphp8.1など)が出ているか、サーバー事業者が独自に修正を配る対応をしているか、確認してください。ソースからビルドしている場合は、PHPセキュリティチームが提供した最小限のバックポート(7.4、8.0、8.1向け)を使えます。可能なら、サポート中の系統への移行を計画してください。

6. 更新の前後でやること

更新の前にバックアップを取り、更新後にトップページの表示、ログイン、フォーム送信などの主要な動作を確認します。PHPの設定ファイル(php.ini、FPMのプール設定など)を自分で変更している場合は、更新後も設定が維持されているかを確認してください。

WordPressなどPHP製ソフトは?

WordPressをはじめ、PHPで動くCMSやECサイト、掲示板、自作のWebアプリは、動作の土台としてPHPを使っています。今回の脆弱性はPHP本体のものなので、これらを動かしているサーバーのPHPが修正版になっていなければ、同じ環境の上で動くアプリは、どれも影響を受ける可能性があります。

重要なのは、WordPressの更新では直らないという点です。WordPress本体やテーマ、プラグインを最新にしても、サーバーのPHPが古いままなら、この問題は残ります。対処できるのは、PHPを更新できる人(自前サーバーなら自分、レンタルサーバーなら事業者)です。

WordPress利用者が今できること

・使っているサーバーの種類を確認する(レンタルサーバーか、VPSか)

・レンタルサーバーなら、事業者の告知を確認する

・VPSなど自前管理なら、上の手順でPHPを更新して再起動する

・PHPのバージョンは、管理画面の「サイトヘルス」で確認できる

すぐ更新できない場合の暫定策(安全にはなりません)

先に結論

PHP公式は「完全な解決策は更新だけ」としています。次の暫定策は、特定の攻撃経路への露出を減らすだけで、環境を安全にするものではありません。更新できるまでの間の補助として、公式の記載どおりに示します。

CVE-2026-109618(メモリ不足に起因)

・memory_limit=-1に設定する。アプリ側で上書きできない形(PHP-FPMプールやApache設定のphp_admin_value)が望ましく、プール・ディレクトリ・アプリの設定で有限の上限が戻っていないかも確認する。PHPのメモリ制限による失敗は避けられるが、OS側のメモリ確保失敗が、脆弱な経路に達する可能性は残る

・post_max_sizeを低くする。ファイルアップロードが不要なアプリは8M、必要な場合は32M。upload_max_filesizeはpost_max_sizeより小さくする

・Webサーバーやプロキシ側で、展開後のリクエストサイズ、入力フィールド数、multipartのパート数、ヘッダー数、入れ子の深さの上限を設ける。Content-Lengthのないリクエストにも効くようにする

・コンテナやcgroupの制限を、可用性の境界として使う。影響を受けたワーカーだけを停止させる設定が望ましい。RLIMIT_ASやRLIMIT_DATAでは代用しない(脆弱なメモリ確保失敗を起こす可能性があるため)

CVE-2026-109619(古い内部状態の残留に起因)

・session.upload_progress.enabled=0にして、すべてのワーカーを再起動する。php.ini、PHP-FPMプール、サーバー設定など、リクエストの解析前に効く場所に書く。ini_set()やPHP-FPMの.user.iniには頼らない。確認済みのセッション経路を防ぐが、他の変種は防げない

・PHP 8.5では、fatal_error_backtraces=0にして、すべてのワーカーを再起動する。確認済みの致命的エラーのバックトレース経路だけを防ぐ

・リクエストごとに適用される無効・非推奨の設定で、初期化前に診断メッセージを出すものを取り除く。error_reportingやdisplay_errors、@で表示を隠しても効果はない

・攻撃者が到達できる致命的エラーや実行タイムアウトを修正する(コールバック、アップロード・インポート処理、後片付けでの失敗を含む)

繰り返しになりますが、これらは暫定策です。設定を変えたから安全、とは考えないでください。更新できる状況になったら、すぐに修正版へ上げてください。

エックスサーバー・BASEの停止はPHPが原因?

同じ10月21日、複数の大手サービスが「ソフトウェアの脆弱性」を理由に、管理画面などを止めました。ここでは、確認できた事実だけを並べます。

・エックスサーバー: 16:00から公式サイト・管理画面等を一時停止。メンテナンスページには「弊社システムで使用しているソフトウェアについて、セキュリティ上の問題(脆弱性)の詳細と修正版が本日公表される予定」とあります。サイト表示とメールソフトでの送受信は継続と案内。公式メンテナンスページ

・BASE: 全サービスの緊急メンテナンスに入り、理由は「利用しているソフトウェアに重大な脆弱性が確認されたことを受けた」措置とされています。BASEヘルプ

どちらの告知にも、「PHP」という名前は出てきません。ですので、「両社の停止はPHPの件が原因だ」と断定することはできません。確認できるのは、「ソフトウェアの脆弱性の詳細と修正版が当日公表される」という両社の説明と、PHP公式が10月21日に修正版を公開した事実が、時期の面で一致しているという点までです。両社が実際に何を理由にしたのか、いつ再開するのかは、各社の発表で確認してください。

それぞれの状況は、こちらの記事にまとめています。エックスサーバー管理画面停止の記事 / BASE緊急メンテの記事。同じ日に起きた別のメンテナンスとして、JVN iPedia・MyJVNのメンテの記事もあわせてどうぞ。

自分のPHPのバージョンの確認とサポート状況

php.netのSupported Versionsで2026年10月21日に確認した、サポート中の系統は次のとおりです。

PHP 8.2から8.5までのサポート期限を示した表。8.2は2026年12月31日、8.3は2027年12月31日、8.4は2028年12月31日、8.5は2029年12月31日までセキュリティサポート。8.1以前はサポート終了 — 図: php.net Supported Versions をもとに筆者が作成

・8.5: 通常サポート 2027年12月31日まで / セキュリティサポート 2029年12月31日まで

・8.4: 通常サポート 2026年12月31日まで / セキュリティサポート 2028年12月31日まで

・8.3: 通常サポート 2025年12月31日まで(終了済み) / セキュリティサポート 2027年12月31日まで

・8.2: 通常サポート 2024年12月31日まで(終了済み) / セキュリティサポート 2026年12月31日まで

今回の修正版は、このうち8.2〜8.5の各系統に提供されました。8.1以前は、PHPプロジェクトからの更新はありません。8.2は、セキュリティサポートの期限が2026年12月31日で、公式のリリース告知でも、その日以降は修正が出ないと明記されています。今のうちに8.3以降への移行を計画しておくと安心です。

自分のPHPのバージョンは、サーバーの管理画面(PHPバージョンの設定欄)や、コマンドラインのphp -vで確認できます。WordPressの場合は、管理画面の「サイトヘルス」にも表示されます。

便乗フィッシングに注意

大きな脆弱性が話題になる日は、それに便乗した偽メールや偽サイトが出回りやすくなる、というのが一般的な傾向です。今回に限った確認済みの被害情報があるわけではありませんが、次の点は習慣にしておくと安全です。

・「PHPの緊急更新」「サーバーのアカウント確認」などのメール・SMS・DMのリンクは開かない

・サーバー事業者の管理画面には、ブックマークや公式サイトから直接ログインする

・更新用のファイルやスクリプトを、出所不明のページからダウンロードして実行しない

・パスワードやカード番号の入力を求められたら、いったん止めて公式の告知を確認する

・未確認の情報をSNSで拡散しない

公式・各社の確認先

最新の情報は、次の一次情報で確認できます。いずれも、検索結果やSNSのリンクではなく、公式サイトを直接開いてください。

23時以降の確認先と避けたい行動を並べた図。php.net、JPCERT/CC、IPA、サーバー事業者、OSの更新情報を確認し、メールやSNSのリンクからの更新や偽ページに注意する — 図: 筆者が作成(一般的なセキュリティ上の注意)

・php.net(PHP公式): ニュース欄とリリース情報で、修正版と告知を確認

・Ubuntu Security Notices(USN-8948-1): Ubuntu 22.04 LTS、24.04 LTSなどの修正パッケージ

・JPCERT/CC(jpcert.or.jp): 日本向けの注意喚起

・IPA(ipa.go.jp): 重要なセキュリティ情報

・利用中のサーバー事業者の公式告知・公式X

・利用中のOS(Debian、RHEL系など)のセキュリティ情報

公式の発表を確認したら、(1)自分の環境が対象か、(2)修正版またはOSの更新パッケージが出ているか、(3)誰がいつ更新するのか、の順で判断すると迷いません。

よくある質問

Q. 修正版は、いつ公開されましたか?

2026年10月21日です。PHP公式は、予告どおり8.5.12、8.4.27、8.3.36、8.2.35を公開しました。

Q. どのバージョンに更新すればよいですか?

使っている系統に合わせて、8.5系は8.5.12、8.4系は8.4.27、8.3系は8.3.36、8.2系は8.2.35に更新します。Linuxディストリビューションのパッケージを使っている場合は、各ディストリビューションが配る更新パッケージを使います。

Q. 自分のサイトは影響を受けますか?

Webリクエストを処理するPHPを使っているなら、対象になり得ます。PHP-FPM、Apache(mod_php)、php-cgi、FrankenPHP、LiteSpeedが含まれます。修正版(またはOSの修正パッケージ)に更新されていない限り、影響を受ける可能性があると考えてください。

Q. WordPressは大丈夫ですか?

WordPressはPHPで動いているため、サーバーのPHPが修正版になっていなければ、影響を受ける可能性があります。PHP本体の問題なので、WordPressの更新では直りません。サーバーのPHPを更新する必要があります。

Q. レンタルサーバーを使っています。自分で何かするべきですか?

共用サーバーの場合、PHP本体の更新は事業者が行うのが一般的です。まずは事業者の告知を確認し、案内があればそれに従ってください。管理画面が止まっているサービスは、再開を待つ必要があります。

Q. 古いPHP(8.1以前)を使っています。

PHPプロジェクトからの更新はありません。使っているOSやサーバー事業者が、修正をバックポートしているか確認してください。たとえば、Ubuntu 22.04 LTSのphp8.1には、8.1.2-1ubuntu2.28が公開されています。ソースからビルドしている場合は、PHPセキュリティチームが提供する最小バックポートも使えます。中長期的には、サポート中の系統への移行をおすすめします。