PHPの脆弱性（CVE-2026-109618ほか）｜未認証でコード実行のおそれ

PHP の開発チームは2026年10月21日（日本時間の同日夜）、Web サーバーで動く PHP に、認証なしで外部からコードを実行されるおそれがある脆弱性2件（CVE-2026-109618・CVE-2026-109619）を修正した版を公開しました。 前日の10月20日に「重大なセキュリティリリース」として予告されていたもので、深刻度は2件とも CVSS v4.0 で 9.2（Critical）です（PHP の発表）。 WordPress や EC-CUBE など、PHP で動く Web サイト・社内システムを持つすべての会社に関係します。

公表された内容

• 対象：PHP 8.2.35・8.3.36・8.4.27・8.5.12 より前の版（GitHub Security Advisory の記載）。Web のリクエストを処理するすべての構成が対象で、PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が例に挙がっています。危険が最も高いのは mod_php としています
• 修正版：PHP 8.5.12・8.4.27・8.3.36・8.2.35
• CVE-2026-109618：メモリ不足のときの処理で、データの準備が途中のまま中断され、その後の後片付けで壊れたデータを正しいものとして扱ってしまう問題
• CVE-2026-109619：あるリクエストの内部の状態が、メモリを解放したあとも残り、同じ処理プロセスが受ける次のリクエストで使われてしまう問題
• 悪用：PHP の発表では、mod_php に対して認証なしのリクエストでコード実行が成り立つことを検証で確かめたとしています。実際の攻撃での悪用は、10月21日の発表では触れられていません
• 古い版：PHP 8.1 以前は PHP の開発チームからの更新はありません。7.4・8.0・8.1 向けには、ソースから組み立てる人向けの最小限の修正が公開されています。OS の配布元や長期サポートの会社が修正を出している場合があるとしています
• PHP 8.2 のサポート終了：2026年12月31日で、以降は修正が出ません

更新までの回避策（発表元の案内）

PHP の発表は「更新だけが完全な対策で、以下は攻撃の入口を減らすだけ」としたうえで、次を挙げています。

• session.upload_progress.enabled=0 を php.ini などで設定し、すべての処理プロセスを再起動する（CVE-2026-109619 の確認済みの経路を塞ぐ）
• post_max_size を小さくする（アップロードが不要なら 8M、必要でも 32M など）。upload_max_filesize はそれより小さくする
• Web サーバーやプロキシで、リクエストの大きさ・項目の数・ヘッダーの数などに上限を設ける
• PHP 8.5 では fatal_error_backtraces=0 を設定する

中小企業が今日からできること

• 自社の Web サイトの PHP の版を確かめる：レンタルサーバーなら管理画面の「PHP バージョン設定」、自社のサーバーなら php -v で確かめ、8.5.12・8.4.27・8.3.36・8.2.35 より前なら更新する
• レンタルサーバー・制作会社に対応を問い合わせる：PHP の更新は事業者側で行うことが多い。契約しているサーバーの会社や、サイトを任せている制作会社に、今回の2件への対応の予定を確かめる
• PHP 8.1 以前のサイトを洗い出す：もう修正が出ない版で動いているサイト（古いキャンペーンサイト・使っていない管理画面など）は、更新できるまで止めるか、公開をやめることを考える。PHP 8.2 も12月31日で終わるため、移行の予定を立てる
• 更新までの回避策を入れる：すぐに更新できないときは、上の回避策（session.upload_progress.enabled=0 など）を入れ、処理プロセスを再起動する
• 更新のあとに動作を確かめる：問い合わせフォーム・会員ログイン・決済など、PHP で動く画面がふだんどおり動くかを確かめる