| 2026年10月21日23時ごろ（日本時間）、PHPに存在する2件の重大な脆弱性に対する修正版が公開されました。いずれも深刻度はCVSS v4.0で9.2であり、認証されていない外部の攻撃者がPHPを実行しているサーバー上で任意のコードを実行できる可能性があります。
結論 修正されたバージョンのPHPまたはベンダーが提供する対応済みパッケージへの更新が、唯一の完全な対策です。緩和策は攻撃経路の一部を減らすものであり、安全になったことを意味しません。 |
対象となるのは、CVE-2026-109618とCVE-2026-109619の2件です。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境が影響を受けます。PHP公式は、アプリケーションコードが動作する前に攻撃を成立させられることが実証されているmod_phpを、特に危険性が高い構成としています。
攻撃によって、PHPプロセスの権限でのコード実行、サービス停止、プロセスメモリ内の認証情報やAPIキーなどの漏えいにつながるおそれがあります。
影響はPHP 5.4以降の広い範囲に及びます。PHPプロジェクトが正式にサポートしている各系列の修正版は次のとおりです。
| 系列 | 修正バージョン | 補足 |
| PHP 8.5 | PHP 8.5.12 | 更新後に全ワーカーを再起動 |
| PHP 8.4 | PHP 8.4.27 | SimpleXMLの回帰不具合に注意 |
| PHP 8.3 | PHP 8.3.36 | 更新後に全ワーカーを再起動 |
| PHP 8.2 | PHP 8.2.35 | 2026年12月31日にサポート終了予定 |
PHP 8.1以前には通常の公式修正リリースはありません。ただし、PHP 7.4、8.0、8.1には例外的に最小限のソースパッチが公開されています。また、LinuxディストリビューションやLTSベンダーが旧版へ修正をバックポートしている場合があります。バージョン番号だけで判断せず、利用しているOSや製品ベンダーのセキュリティ情報を確認してください。
コンテナ、アプライアンス、管理画面、ネットワーク機器などに内蔵されたPHPは、ホストOSのPHPを更新しても修正されない場合があります。製品ベンダーが提供する更新も個別に確認する必要があります。
脆弱性に関する情報は、予定されていた公開より前の10月20日に外部へ漏れました。Cloudflareは修正版公開前から攻撃トラフィックを観測し、攻撃者がWAFを回避するためにリクエストを変化させていたと報告しています。公開後はパッチ差分や技術解説を利用した攻撃コードの開発が急速に進む可能性があります。
W3Techsによると、2026年10月22日時点で、サーバー側の使用言語を判別できるWebサイトの69.3％がPHPを使用しています。WordPress、Drupal、Joomlaなどでも攻撃が実証されていますが、これは特定のCMSに限った問題ではありません。WordPress本体やプラグインだけを更新しても、この脆弱性は解消しません。
迅速な更新ができない場合の緩和策を以下にまとめます。どの対策も一時的かつ部分的で、更新の代わりにはなりません。
| 対策 | 期待できる効果 | 主な限界と副作用 |
| session.upload_progressを無効化 | 確認済みのセッション経路を遮断 | 他の経路は残る。全ワーカーの再起動が必要 |
| memory_limitを無制限化 | 特定のメモリ枯渇要因を減らす | メモリ枯渇によるDoSの危険。cgroupなど外側の制限が必要 |
| POSTとアップロードを制限 | メモリ圧迫につながる入力を減らす | 正規のアップロードに影響。PHP側だけでは不足 |
| WAFを利用 | 既知の攻撃パターンを遮断 | ペイロード変化やオリジン直アクセスで回避され得る |
| disable_functions | 一般的なWebシェルの一部を制限 | 今回のメモリ破壊によるRCEの緩和策にはならない |
session.upload_progress.enabled = 0
この設定は確認されたセッション経由の攻撃経路を遮断しますが、別の経路までは防ぎません。php.ini、PHP-FPMのプール設定、またはApache設定で適用し、設定後に全ワーカーを再起動してください。ini_set()やPHP-FPMの.user.iniには依存できません。アップロード進捗表示を使用する機能が動かなくなる可能性もあります。
memory_limit = -1
PHP公式は、CVE-2026-109618の特定経路に対する緩和策として、アプリケーションから上書きできない方法でこの設定を適用することを挙げています。PHP内部のメモリ上限到達は避けられますが、攻撃や不具合によってプロセスが大量のメモリを消費し、サービスやサーバー全体を停止させる危険があります。
コンテナやcgroupによる外側のメモリ制限と組み合わせ、可能であれば問題のあるワーカーだけを停止できる構成にしてください。RLIMIT_ASやRLIMIT_DATAは、今回問題となるメモリ確保失敗を発生させ得るため、代替策として使用しないようPHP公式が注意しています。
PHP公式は、ファイルアップロードが不要な環境ではpost_max_sizeを8M、必要な環境では32M程度とし、upload_max_filesizeをそれより小さくする例を示しています。ただし、適切なContent-Lengthがないリクエストが初期検査を通過する経路があるため、PHP側の設定だけでは十分ではありません。
multipart/form-dataをWebサーバーで全面的に拒否すれば既知の攻撃経路の多くを減らせますが、ファイルアップロードや一部のフォームが利用不能になります。また、アプリケーション固有の別経路まで防げる保証はありません。
fatal_error_backtraces = 0
PHP 8.5では、確認済みのエラーバックトレース経路に対する緩和になります。設定後は全ワーカーを再起動してください。この設定も該当経路だけを防ぐもので、完全な対策ではありません。
WAFは多層防御として有効ですが、更新の代替にはなりません。Cloudflareは攻撃ペイロードが変化していると報告しています。WAFを利用する場合も、攻撃者がオリジンサーバーへ直接接続できないよう、接続元をWAF事業者のIPアドレスに限定するなどの対策が必要です。
disable_functions = exec,shell_exec,system,passthru
この設定は一般的なWebシェルの動作を制限する補助策ですが、今回の脆弱性に対する緩和策としては扱えません。メモリ破壊によってネイティブコード実行に至る場合、これらのPHP関数を経由する必要がないためです。また、対象関数を使用する正規のスクリプトが動作しなくなる副作用もあります。
PHP 8.4.27と8.5.12では、特定のSimpleXML処理とガベージコレクションが組み合わさった場合に二重解放が発生し、PHPプロセスが異常終了する回帰不具合が確認されています。これは2件のRCE修正そのものではなく、同じリリースに含まれた別のガベージコレクション修正に由来します。主な発生条件は次の組み合わせです。
発生時にはzend_mm_heap corrupted、SIGABRT、終了コード134などが確認されています。Laravel、Pest、PHPUnit、Mockeryを組み合わせたテスト環境での実例も報告されています。2026年10月22日時点では、確認済みの報告対象はPHP 8.4.27と8.5.12です。修正案はレビュー承認済みですが、確認時点では未マージです。
更新前にSimpleXMLを利用する処理やテストを確認し、更新後はPHP-FPMのクラッシュやzend_mm_heap corruptedを監視してください。ただし、この不具合を理由にインターネット公開環境を脆弱な8.4.26や8.5.11へ安易に戻すべきではありません。問題が発生する場合は該当処理を一時停止し、PHPまたはOSベンダーが提供する修正版へ進めるのが安全です。
PHPがどこで動いているかわからない。パッチの適用は終わったがすでに攻撃を受け、侵入されているのではないかという懸念がある。社内に判断できる担当者がいない。など、様々なご相談に対応可能です。お気軽にお問い合わせください。
https://form.vlcsecurity.com/form/contact_service?k3ad=php_column
国家サイバー統括室やIPAをはじめ、国内外の機関から注意喚起が出ています。修正版への更新が唯一の完全な対策です。緩和策を適用した場合も安全になったとは判断せず、更新、全ワーカーの再起動、動作確認、侵害調査まで実施することを推奨します。
