はじめに
昨夜（2026年10月21日夜）、各サイトは一時的にアクセスを遮断する対応となりました。
サイトを運用・保守していると、突然のセキュリティ対応に戸惑うこともあります。今回は、WordPressでも使われているPHPについて、重大な脆弱性と修正版が発表されました。
この記事では、PHP公式の告知をもとに、更新先と、すぐに更新できない場合の暫定対策を日本語で整理します。
暫定対策だけでは安全を確保できません。修正版、または同等の修正パッチの適用を最優先にしてください。
何が発表されたのか
PHP公式は2026年10月21日、認証なしでリモートコード実行につながる可能性がある、2件の重大な脆弱性を公表しました。
- CVE-2026-109618：メモリ不足時の処理に関する問題
- CVE-2026-109619：解放済みメモリを参照する内部状態が、後続のリクエストに残る問題
対象は、Webリクエストを処理するPHP環境です。PHP-FPMやApacheのmod_phpなどが含まれ、公式は特にmod_phpのリスクを高く評価しています。
WordPressを利用している場合も、PHP環境の対応状況を確認する必要があります。PHP公式告知
① 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 |
| PHP 8.1以前 | サポート対象版への移行、または提供元の修正状況を確認 |
例えばPHP 8.3.35を利用している場合、更新先は8.3.36以降です。
ただし、提供元が修正をバックポートしている場合もあります。バージョン番号だけで判断せず、利用しているパッケージやサービスの案内も確認してください。 PHP公式の更新案内
② すぐにアップデートできない場合
以下は、公式が案内している暫定対策の要点です。設定はサーバー管理者と確認して適用してください。
対策A：PHPのメモリ制限を変更する
memory_limit = -1
PHP側のメモリ上限到達を利用する攻撃経路を減らすための設定です。実際のメモリ確保失敗による経路は残ります。
アプリケーションから上書きされない設定方法を使い、コンテナやcgroupによる制限と組み合わせることが案内されています。RLIMIT_ASやRLIMIT_DATAで代用しない点にも注意が必要です。
対策B：POSTデータの容量を制限する
公式が示している設定値は次のとおりです。
ファイルアップロードが不要な場合：
post_max_size = 8M
ファイルアップロードが必要な場合：
post_max_size = 32M
upload_max_filesizeはpost_max_sizeより小さくします。
なお、post_max_sizeはファイルだけでなくPOSTデータ全体の上限です。変更後は、WordPressの画像アップロードやフォーム送信など、必要な操作が行えるか確認してください。
対策C：セッションのアップロード進捗機能を停止する
session.upload_progress.enabled = 0
リクエスト解析前に適用されるphp.iniやサーバー設定などで変更し、すべてのPHPワーカーを再起動します。ini_set()やPHP-FPMの.user.iniには頼らないよう案内されています。
PHP 8.5では追加設定も確認する
fatal_error_backtraces = 0
こちらも変更後にすべてのワーカーを再起動します。
公式は、このほかにもWebサーバー側の入力制限や、初期化前に診断を発生させる設定の見直しなどを案内しています。適用条件と限界を含め、必ず公式の暫定対策を確認してください。
③ WordPressの制作・保守ではどう対応するか
レンタルサーバーを使っている場合は、まずサーバー会社の告知や管理画面を確認します。
確認したいのは、次の3点です。
- 今回の2件の脆弱性について、対応済みか
- 修正版への切り替えなど、利用者側の操作が必要か
- 未対応の場合、提供予定と推奨される暫定対応は何か
問い合わせる際は、PHPのバージョンに加えて、CVE-2026-109618とCVE-2026-109619への対応状況を尋ねると確認しやすくなります。
更新後は、サイト表示、管理画面へのログイン、フォーム送信、画像アップロードなど、普段利用する機能の動作も確認しておきましょう。
まず修正の適用状況を確認し、必要な更新を行うこと。暫定対策を実施しただけで対応完了としないことが大切です。