CVE-2026-109618 — メモリ不足(OOM)処理の破損によるリモートコード実行
概要
PHPは、メモリ不足(OOM)のエラーが起きると longjmp() で処理を中断してリクエストの処理を打ち切ります。ところが、リクエスト用のメモリが初期化の途中の状態でこれが起きると、そのメモリが無効な状態のまま残り、リクエストの終了処理がそれを有効なデータとして扱ってしまいます。失敗するメモリ確保は、無効なメモリと関係がなくてもかまいません。
公式アドバイザリによると、multipart(ファイルアップロードなどで使う形式)の解析にある複数の問題を使うと、PHPの見かけ上の上限(post_max_size など)の範囲内のリクエストでもOOMを起こせ、認証なしでのリモートコード実行につながります。Apacheのmod_phpでは、アプリケーションのコードが動く前の段階で成立します。
影響を受けるバージョン
- PHP 8.2 系: 8.2.35 未満(8.2.0 以上)
- PHP 8.3 系: 8.3.36 未満(8.3.0 以上)
- PHP 8.4 系: 8.4.27 未満(8.4.0 以上)
- PHP 8.5 系: 8.5.12 未満(8.5.0 以上)
影響を受ける構成: php.netは、Webリクエストを処理するすべてのPHP(PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed)が対象としています。リスクがもっとも高いのはmod_phpで、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立することが実証されています。
PHP 8.1 以前: php.netからの更新は提供されません(サポート終了)。ディストリビューションやLTSベンダーがバックポートを提供している場合があるため提供元に確認するか、サポート中のブランチへ移行してください。ソースからビルドする利用者向けに、PHPセキュリティチームが7.4・8.0・8.1用の最小限のバックポートを公開しています。
公式アドバイザリの分析では、PHP-FPMも影響を受け得る(完全な攻撃はまだ実証されていない)、FrankenPHPはmod_phpと同様に影響を受ける可能性が高い、LSAPIはアプリケーションによる攻撃の可能性が高い(未検証)とされています。
自分のPHPバージョンを確認する
- WordPress: 管理画面「ツール → サイトヘルス → 情報 → サーバー」の「PHPバージョン」
- レンタルサーバー: 管理画面(コントロールパネル)の「PHPバージョン設定」などのメニュー
- SSH:
php -v(CLI用。Webサーバー側と異なる場合があります)
PHPバージョンの確認方法を詳しく見る → / WordPressの場合 →
対策
- 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以降へ更新してください(できれば各ブランチの最新リリース)。
- レンタルサーバーでは、事業者の公式のお知らせで更新状況を確認し、必要なら管理画面でPHPのバージョンを切り替えます(エックスサーバーの手順)。Linuxディストリビューションの更新パッケージは、各ディストリビューションで確認してください(php.netによると、ディストリビューションとLTSベンダーには事前にパッチが提供されています)。
- PHP 8.1 以前はphp.netの修正版がありません。サポート中のブランチへ移行するか、提供元のバックポートを確認してください。
- rpms.remirepo.net を使っている場合: php.netは、当日は更新が提供されないため、ディストリビューションのパッケージへの切り替えかソースからのビルドを推奨しています。
- 更新後は、PHP-FPMやWebサーバーを再起動して、すべてのワーカーが新しいPHPで動いていることを確認してください。
すぐに更新できない場合の緩和策(部分的)
memory_limit=-1を、アプリケーションから上書きできない方法(FPMプールやApacheの設定のphp_admin_valueなど)で設定し、どのプール・ディレクトリ・アプリケーションの設定でも有限の値に戻されていないことを確認します。PHPのメモリ上限による失敗はなくなりますが、その下のメモリ確保が失敗した場合は、なお脆弱な経路に到達し得ます。設定後はすべてのPHPワーカーを再起動します。post_max_sizeを低めにします。ファイルアップロードが不要ならpost_max_size = 8M、必要ならpost_max_size = 32M。upload_max_filesizeはpost_max_sizeより小さくします。- Webサーバーやプロキシで、デコード後のリクエストサイズ・入力フィールド数・multipartのパート数・ヘッダー数・ネストの深さに上限を設けることを検討します。Content-Lengthが使えないリクエストにも上限がかかるようにします。
- コンテナやcgroupのメモリ上限は可用性の境界として使えます(できれば該当のワーカーだけを停止させる設定に)。
RLIMIT_ASやRLIMIT_DATAで代用しないでください。脆弱なメモリ確保の失敗を引き起こします。
あわせてCVE-2026-109619の緩和策も確認してください(公式アドバイザリでも関連する報告として案内されています)。
よくある質問
CVE-2026-109618はどのバージョンが対象ですか？
PHP 8.2〜8.5の各ブランチで、8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 より前のバージョンが対象です。PHP 8.1以前はphp.netの修正版がありません。
WordPressのサイトも影響を受けますか？
WordPressのバージョンではなく、サーバーで動いているPHPのバージョンと構成で決まります。php.netはWebリクエストを処理するすべてのPHPが対象としているため、サイトヘルスなどでPHPのバージョンを確認し、修正版より前なら更新してください。
memory_limit=-1 にすれば安全ですか？
いいえ。公式アドバイザリは、memory_limit=-1 は主な緩和策だが完全ではなく、その下のメモリ確保が失敗した場合は脆弱な経路に到達し得るとしています。完全な対策は修正版への更新だけです。
自分のサイトが該当するか確認できますか？
phpcheck.jpでサイトのURLまたはPHPバージョンを入力すると、このCVEに該当するかを無料で判定できます。
出典
- php-src Security Advisory GHSA-w8hw-w9fx-j79w
- CVE-2026-109618 (CVE.org)
- php.net: Security advisory: Critical remote code execution vulnerabilities, update now
- PHP 8 ChangeLog
- www.php.net/ChangeLog-8.php#8.5.12
- www.php.net/ChangeLog-8.php#8.4.27
- www.php.net/ChangeLog-8.php#8.3.36
- www.php.net/ChangeLog-8.php#8.2.35
最終確認日: 2026-10-21