PHP 8.2〜8.5 の修正版より前のバージョンでWebリクエストを処理しているサーバーは、すべて今回の2件の重大な脆弱性（CVE-2026-109618・CVE-2026-109619）の対象で、修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 の4つ、PHP公式は「更新が唯一の安全な選択」としています。PHP公式は2026年10月21日、認証なしのリモートコード実行につながる2件を修正したと発表しました。オランダの国家サイバーセキュリティセンター（NCSC-NL）はこの2件を「php2shell」と呼んでいます。この記事では「自分は対象か」「今すぐ何をするか」を、PHP公式・GitHubのセキュリティアドバイザリ・公的機関の発表に書かれた内容だけで整理します。
【結論】
- 対象：Webリクエストを処理するすべてのPHP（PHP-FPM・Apache mod_php・php-cgi・FrankenPHP・LiteSpeed）。影響バージョンは 8.2.35／8.3.36／8.4.27／8.5.12 より前です。
- 今すぐやること：PHPを修正版（8.5.12・8.4.27・8.3.36・8.2.35）か、OS・ベンダーが配布する修正済みパッケージに更新し、PHPのワーカーを再起動します。レンタルサーバーは契約先の公式のお知らせを確認します。
- 更新できない場合：設定による緩和策はありますが、PHP公式は「完全な緩和策はない」と明記しています。あくまで更新までのつなぎです。
早見表：2つの脆弱性と修正版
PHP公式の告知とGitHub上のセキュリティアドバイザリ（GHSA）の記載です。
| 項目 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 公式の名称 | RCE via OOM corruption（メモリ不足の処理での破損によるリモートコード実行） | RCE via stale global state（古いグローバル状態の再利用によるリモートコード実行） |
| アドバイザリ | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| 深刻度（CVSS v4.0） | Critical・9.2 | Critical・9.2 |
| 想定される影響 | 認証なしでのリモートコード実行（Webワーカーのアカウントの権限で） | 認証なしでのメモリの解放後使用（use-after-free）、メモリ内容の漏えい、リモートコード実行 |
| 影響バージョン | 8.2.35未満／8.3.36未満／8.4.27未満／8.5.12未満（GHSAの記載） | |
| 修正版 | PHP 8.5.12・8.4.27・8.3.36・8.2.35 | |
| 公開日時（日本時間） | 事前告知：2026年10月20日／修正版：2026年10月21日（予定は23:00、GHSAの公開時刻は22:34） | |
CVSSのベクタは2件とも CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N です。ネットワーク経由で権限もユーザーの操作も不要、成功すると機密性・完全性・可用性に大きな影響がある一方、攻撃の複雑さは「高」、前提条件は「あり」と評価されています。
なお、PHP 8.2 は2026年12月31日でサポート終了となり、それ以降はセキュリティ修正も出ません（PHP公式）。8.2.35 に更新した場合も、移行の計画が必要です。
自分は影響を受ける？ 環境別の切り分け
PHP公式は対象を「Webリクエストを処理するすべてのPHP」とし、Apache の mod_php を最もリスクが高いとしています。mod_php では、アプリのコードが動く前に認証なしのリクエストで攻撃が成立することが実証されているためです。
| 環境 | 対象か | 何をすべきか |
|---|---|---|
| レンタルサーバー（共用サーバー） | サイトをPHP 8.2〜8.5で動かしていて、PHPが修正版より前なら対象 | 契約先の公式のお知らせ・管理画面で対応状況を確認。PHPのバージョンを選べる場合は、選んでいるバージョンも確認します。 |
| 自社サーバー・VPS（Linux） | Webで使うPHPが修正版より前なら対象 | ディストリビューションやLTSベンダーの更新パッケージを適用し、PHP-FPMやApacheを再起動します。 |
| WordPress | WordPressを動かしているPHPが対象。WordPress本体やプラグインの更新では直らない | PHP本体を修正版にします（上の2行のどちらかの手順）。 |
| Docker・コンテナ | イメージに入っているPHPが修正版より前なら対象 | ホスト側のPHPを更新しても、イメージや機器に同梱されたPHPが更新されるとは限りません（NCSC-NL）。修正版を含むイメージで作り直し、入れ替えます。 |
| PHP 8.1 以前 | PHPプロジェクトからの更新はありません | ベンダーのバックポート（修正の移植）を確認するか、サポート中のバージョンへ移行します。ソースからビルドする人向けに、PHP 7.4・8.0・8.1 用の最小限のソースバックポートも公開されています。 |
| 製品・ネットワーク機器（内部でPHPを使うもの） | 内部でPHPを使っていれば影響の可能性 | 製品のマニュアルや開発元・提供元のセキュリティ情報を確認します（IPA）。 |
自社サーバーでApacheとPHP-FPMを組み合わせて監視ツールなどを動かしている場合も、Webで使うPHPなら対象です（構成の例：Zabbix Server 6.0 のインストール手順（AWS/Red Hat/MySQL/Apache））。
今すぐやること：バージョン確認と更新
1. 使っているPHPのバージョンを確認する
- コマンドで確認：サーバーに入れる場合は
php -vでPHPのバージョンとSAPI名（cli など）が表示されます（PHPマニュアルのコマンドラインオプション）。これはコマンドライン版の情報で、Webサーバーが使うPHPとは別のこともあるため、Web側の確認も合わせて行います。 - Web側で確認：
phpinfo()は、PHPのバージョンやサーバー情報、設定値などを出力する関数です（PHPマニュアル）。出力には環境変数やサーバー変数なども含まれるため、確認用に置いたファイルは確認後すぐに削除します。 - WordPressで確認：管理画面の「ツール」→「サイトヘルス」→「情報」タブの「サーバー」セクションに、ウェブサーバーやPHPに関する情報が表示されます（WordPress.org のサイトヘルス画面の解説）。
表示されたバージョンが 8.5.12・8.4.27・8.3.36・8.2.35 より前なら更新が必要です。ただし、ディストリビューションやLTSベンダーが修正をバックポートしたパッケージを配布する場合もあるため（PHP公式・NCSC-NL）、番号だけで判断せず、ベンダー側の告知で修正済みかどうかを確認します。
2. 修正版に更新し、ワーカーを再起動する
- OSのパッケージの場合：LinuxディストリビューションとLTSベンダーには事前にパッチが渡されています（PHP公式）。ベンダーの更新パッケージを確認します。
- ソースから入れている・Windowsの場合：修正版のソースとWindows版のバイナリは php.net のダウンロードページにあります。
- remirepo を使っている場合：CERT-EU（EUの機関向けのCSIRT）は、有志が運営する rpms.remirepo.net はリリース当日には更新が出ないとし、PHPチームがディストリビューションのパッケージかソースからのビルドへの切り替えを求めていると伝えています。
- 更新後：PHP-FPM・Apacheなど、PHPを動かしているプロセスを再起動し、もう一度バージョンを確認します。
すぐに更新できない場合の緩和策（完全ではない）
PHP公式は、以下の対策は特定の攻撃経路を減らすだけで、安全にするものではないと明記しています。更新までのつなぎです。
| 対象 | 公式の緩和策 | 注意点（公式の記載） |
|---|---|---|
| CVE-2026-109618 | memory_limit=-1 を、アプリから上書きできない方法（FPMプールやApache設定の php_admin_value など）で設定 | プール・ディレクトリ・アプリの設定で有限の値に戻っていないか確認する。より下のレベルのメモリ確保の失敗は、引き続き脆弱な処理に到達しうる |
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・FPMプール・リクエスト解析の前に効くサーバー設定で行う。ini_set() やFPMの .user.ini には頼らない。確認済みのセッションの経路は防げるが、別の変種は防げない |
PHP 8.5 では fatal_error_backtraces=0 にして、すべてのワーカーを再起動 | 確認済みの「致命的エラーのバックトレース」の経路だけを防ぐ | |
| リクエストごとに適用される、無効・非推奨の設定（初期化の前に診断メッセージを出すもの）を取り除く | error_reporting・display_errors・@ で表示を隠しても効果はない | |
| 攻撃者が到達できる致命的エラーと実行タイムアウトを解消する | コールバック・アップロード処理・後片付けでの失敗も含む |
2つの脆弱性のしくみ（公式の説明の範囲で）
CVE-2026-109618：メモリ不足のときに処理を途中で打ち切るしくみ
PHPは、メモリ不足（OOM）のエラーが起きると処理を途中で打ち切ります。PHP公式によると、リクエストの内部データが一部しか初期化されていないタイミングで打ち切られると、後片付けの処理がその不完全なデータを正しいものとして扱ってしまうことがあります。GHSAでは、multipart形式（ファイルのアップロードなどで使う形式）の解析で、PHPの制限内のままメモリ不足に至る方法が複数あるとしています。
mod_php では、開始処理が失敗しても後片付けの処理が必ず実行されるため、アプリのコードが動く前に問題が起きます。WordPressのセキュリティプラグインのような、アプリ側の対策より前の段階です。FPMについては、ソースの分析上は影響を受けるとされています（完全な攻撃の実証はない、とも明記）。
CVE-2026-109619：前のリクエストの「古い状態」が残るしくみ
PHPのワーカーは複数のリクエストを順番に処理します。PHP公式によると、あるリクエストの内部の状態がメモリの解放後も残り、同じワーカーが処理する次のリクエストが、初期化の前にその古い状態を使ってしまうことがあります。GHSAは、致命的なエラー（メモリ不足を含む）で本来のリセットが行われないことを原因の一つに挙げ、PHP 8.5 の致命的エラーのバックトレース機能と、セッションのアップロード進捗機能（初期設定で有効）を使う経路を「確認済み」としています。緩和策の表に fatal_error_backtraces と session.upload_progress.enabled が出てくるのはこのためです。
攻撃の具体的な手順は、この記事では扱いません。
公式に書かれていないこと・現時点でわからないこと
- 実際の悪用：PHP公式の告知とGHSAには、攻撃に悪用されたことを確認したという記載はありません。IPAは2026年10月21日の事前告知の時点で「悪用した攻撃を確認しているわけではない」としています。一方でCERT-EUは、技術的な詳細が公開の場で議論され、初期の概念実証コード（PoC）が出回り始めたことから、すでに悪用されている可能性が高まっていると評価しています。
- 国内の被害：2026年10月22日時点で、この2件による国内の被害を公的機関が発表したものは確認できませんでした。
- 公的機関の注意喚起：IPAは2026年10月21日に「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を公開し、PHPを使うプログラムの棚卸しと速やかな適用の準備を求めています。サポート終了の古いPHPを使い続けるサイトも見受けられ、攻撃者が極めて短時間で攻撃を実行する可能性があるとしています。JPCERT/CCの注意喚起とJVNの掲載は、2026年10月22日時点で確認できませんでした。
- 古いバージョンの範囲：GHSAの影響バージョンはサポート中の 8.2〜8.5 で示されています。IPAの事前告知は、CERT-EUが「PHP 5以降が影響を受ける」と記載していたことに触れています。7.4より古い系列の扱いは、PHP公式の告知に書かれていません。
- 各レンタルサーバーの対応状況：公式のお知らせを確認できていないため、この記事では書いていません。
国内で公表されたサイバー攻撃・情報漏えいの事例は、2026年 国内の情報漏えい・サイバー攻撃一覧にまとめています。また、AIが実在の脆弱性を自力で突く研究が進んでいる点は、AWS Security AgentがCVE 37件中33件を突破した発表の解説で取り上げています。
よくある質問
WordPressを最新版にすれば大丈夫ですか？
いいえ。今回の脆弱性はPHP本体にあり、修正はPHP 8.5.12・8.4.27・8.3.36・8.2.35に入っています。WordPressを動かしているPHPを修正版に更新する必要があります。
レンタルサーバーを使っている場合は何をすればいいですか？
契約しているサーバー会社の公式のお知らせで、PHPの更新状況を確認してください。WordPressなら「ツール」→「サイトヘルス」→「情報」タブの「サーバー」でPHPに関する情報を確認できます。
PHP 8.1以前を使っている場合はどうなりますか？
PHPプロジェクトからの更新はありません。ディストリビューションやLTSベンダーのバックポートを確認するか、サポート中のバージョンへ移行してください。
設定変更（緩和策）だけで安全になりますか？
なりません。PHP公式は「完全な緩和策はなく、更新が唯一の安全な選択」としています。memory_limit や session.upload_progress.enabled などの設定変更は、特定の攻撃経路を減らすだけです。
すでに攻撃に悪用されていますか？
PHP公式の告知には、悪用を確認したという記載はありません。IPAは10月21日の事前告知の時点で悪用を確認していないとしています。CERT-EUは、概念実証コードが出回り始めたことで悪用の可能性が高まっていると評価しています。
まとめ
- CVE-2026-109618・CVE-2026-109619は、Webリクエストを処理するPHPを対象とした、認証なしのリモートコード実行につながる2件の脆弱性です（CVSS v4.0 9.2・Critical）。
- 修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35。OS・ベンダーの修正済みパッケージやイメージに更新し、ワーカーを再起動します。
- WordPress本体の更新では直りません。レンタルサーバーは契約先の公式のお知らせを確認します。
- 設定による緩和策は「完全ではない」と公式が明記しています。PHP 8.1以前は、ベンダーのバックポートかサポート中のバージョンへの移行が必要です。
参考（確認日：2026年10月22日）
- PHP公式：セキュリティアドバイザリ（2026年10月21日）
- PHP公式：セキュリティリリースの事前告知（2026年10月20日）
- PHP公式：ChangeLog（8.5.12ほか）／サポート中のバージョン
- GitHub（php/php-src）：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub（php/php-src）：GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について（2026年10月21日）
- CERT-EU：Security Advisory 2026-018
- NCSC-NL：php2shell（GitHub）
- PHPマニュアル：コマンドラインオプション（php -v）／phpinfo
- WordPress.org 日本語：サイトヘルス画面
コメント