はじめに

昨夜（2026年10月21日夜）、各サイトは一時的にアクセスを遮断する対応となりました。

サイトを運用・保守していると、突然のセキュリティ対応に戸惑うこともあります。今回は、WordPressでも使われているPHPについて、重大な脆弱性と修正版が発表されました。

この記事では、PHP公式の告知をもとに、更新先と、すぐに更新できない場合の暫定対策を日本語で整理します。

暫定対策だけでは安全を確保できません。修正版、または同等の修正パッチの適用を最優先にしてください。

何が発表されたのか

PHP公式は2026年10月21日、認証なしでリモートコード実行につながる可能性がある、2件の重大な脆弱性を公表しました。

対象は、Webリクエストを処理するPHP環境です。PHP-FPMやApacheのmod_phpなどが含まれ、公式は特にmod_phpのリスクを高く評価しています。

WordPressを利用している場合も、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公式の更新案内

以下は、公式が案内している暫定対策の要点です。設定はサーバー管理者と確認して適用してください。

memory_limit = -1

PHP側のメモリ上限到達を利用する攻撃経路を減らすための設定です。実際のメモリ確保失敗による経路は残ります。

アプリケーションから上書きされない設定方法を使い、コンテナやcgroupによる制限と組み合わせることが案内されています。RLIMIT_ASやRLIMIT_DATAで代用しない点にも注意が必要です。

公式が示している設定値は次のとおりです。

ファイルアップロードが不要な場合：

post_max_size = 8M

ファイルアップロードが必要な場合：

post_max_size = 32M

upload_max_filesizeはpost_max_sizeより小さくします。

なお、post_max_sizeはファイルだけでなくPOSTデータ全体の上限です。変更後は、WordPressの画像アップロードやフォーム送信など、必要な操作が行えるか確認してください。

session.upload_progress.enabled = 0

リクエスト解析前に適用されるphp.iniやサーバー設定などで変更し、すべてのPHPワーカーを再起動します。ini_set()やPHP-FPMの.user.iniには頼らないよう案内されています。

fatal_error_backtraces = 0

こちらも変更後にすべてのワーカーを再起動します。

公式は、このほかにもWebサーバー側の入力制限や、初期化前に診断を発生させる設定の見直しなどを案内しています。適用条件と限界を含め、必ず公式の暫定対策を確認してください。

レンタルサーバーを使っている場合は、まずサーバー会社の告知や管理画面を確認します。

確認したいのは、次の3点です。

問い合わせる際は、PHPのバージョンに加えて、CVE-2026-109618とCVE-2026-109619への対応状況を尋ねると確認しやすくなります。

更新後は、サイト表示、管理画面へのログイン、フォーム送信、画像アップロードなど、普段利用する機能の動作も確認しておきましょう。

まず修正の適用状況を確認し、必要な更新を行うこと。暫定対策を実施しただけで対応完了としないことが大切です。