2件とも認証なしの乗っ取り。mod_phpは「アプリのコードが走る前」に通る

• 修正版は8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• いずれも認証不要で遠隔からコードを実行される
• 7.4 / 8.0 / 8.1 にも、例外的にバックポートが出た

昨日修正版の公開前に書いた記事の続きになる。

日本時間の23時に公開され、中身が確定した。結論から言うとかなり悪い。

確定した情報

php.netの告知はこう始まる。

PHP 8.5.12、8.4.27、8.3.36、8.2.35 は、認証されていない遠隔のコード実行を許しうる2件の重大な脆弱性を修正します。すべてのPHP利用者に、ただちに更新することを強く推奨します。

誰が危ないか

ここは具体的に書かれている。

Webのリクエストを処理しているすべてのPHP環境。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含みます。mod_phpのリスクが最も高いと考えています。認証されていないリクエストが、アプリケーションのコードが動き出す前に攻撃を引き起こせる実証済みのエクスプロイトがあります。

アプリのコードが走る前、という部分が重い。

つまりWordPressだろうが自作だろうが、中身は関係ない。ログイン画面も通らない。リクエストが届いた時点で成立しうる。

mod_php と FPM の違い

技術的な理由も書かれていた。

• mod_php — リクエストの開始に失敗しても無条件に終了処理を走らせる。だから壊れた状態がそのまま処理される
• FPM — 開始に失敗したらその子プロセスを終了させる。壊れた状態を使わずに済み、そのプロセスは外される

ただしFPMなら安全という話ではない。正常に開始した後にメモリ不足へ至る経路は残っている、と明記されている。

2件の中身

1つ目：メモリ不足の処理で壊れる

PHPはメモリが足りなくなったとき、処理を途中で打ち切って脱出する仕組みを持っている。

問題は脱出した先の後片づけだった。

メモリ不足の処理が、内部のリクエストデータが部分的にしか初期化されていない状態でPHPを中断させうる。その後のリクエストの後片づけが、不正なデータを正しいものとして扱うことがある。

そしてメモリ不足は、わざと起こせる。アドバイザリが挙げている例がこうだ。

• ファイル送信の形式ではパートに付けるヘッダーの数に上限が無い。PHPの内部表現は通信上の見た目よりずっとメモリを食うので、送信サイズの上限内でもメモリ上限を使い切らせられる
• 中身が空のファイル欄は、アップロード数の上限に数えられない。それなのに通常どおりの管理用データは作られる
• 長さの宣言が無い送信は、最初のサイズ検査をすり抜ける場合がある

上限を設定していても、上限の数え方の外から積み上げられる。これが怖いところだと思った。

2つ目：前のリクエストの残骸を踏む

PHPは1つのワーカーで複数のリクエストを順番に処理する。エラーやセッションの状態は、本来次のリクエストの前にリセットされる。

リクエストが所有していた内部の状態が、その裏にあるメモリが解放された後も生き残ることがある。同じワーカーが扱う後続のリクエストが、通常の初期化がそれをリセットする前に、その古い状態を使ってしまう可能性がある。

解放済みのメモリを指したまま次へ持ち越される。致命的なエラーがリセットを飛ばしたり、警告がクリア後に状態を埋め直したりすると、こうなる。

成立には「置く側」と「踏む側」の両方が要るとされ、その2つは別々のHTTPリクエストで起きる。

サポート切れの版にも、例外が出た

ここは昨日の記事の続きとして、正直に書いておきたい。

昨日、サポートが切れた版は一覧に載らないという話を書いた。通常はそのとおりになる。

今回は違った。

これらの脆弱性の深刻さを踏まえ、PHPのセキュリティチームは、ソースからビルドする方々やLTSベンダーを利用できない方々のために、PHP 7.4、PHP 8.0、PHP 8.1 向けの最小限のソースバックポートを提供しました。

すでに終了している版に、例外としてパッチが出ている。

裏を返せばそれだけ深刻だと判断されたということになる。通常はこうはならない。例外が出たから安心、ではなく、例外を出すほど危ないと読むのが正しい。

なお8.1以前はPHP本体からの更新は受けられないことに変わりはない。ディストリビューションやLTSの提供元が個別に対応している場合があるので、そこに確認するという案内になっている。

すぐ更新できないときの緩和策

公式が挙げているが、前置きがはっきりしている。

完全な解決は更新だけです。以下の措置は特定の攻撃経路への露出を減らしますが、その設置を安全にするものではありません。

8.5.12のリリース告知にはもっと短く書かれている。「完全な緩和策は存在せず、更新だけが唯一の安全な選択である」。

1件目への措置

• memory_limit を -1 にする。しかもアプリ側から上書きできない形で
• post_max_size を小さくする。アップロードが不要なら8M、必要なら32M。upload_max_filesize はそれより下に
• Webサーバーやプロキシ側で、展開後のサイズ、入力欄の数、パートの数、ヘッダーの数、入れ子の深さに制限をかける

1番目は直感に反すると思った。ふつう上限は付けるほうが安全に思える。

だが今回は上限があるから、わざと使い切らせて不正な状態を作れるという形になっている。だから上限そのものを外す。

あわせてRLIMIT_AS や RLIMIT_DATA で代用してはいけないとも書かれている。それ自体が、問題の割り当て失敗を引き起こすからだ。

2件目への措置

• session.upload_progress.enabled を 0 にして、すべてのワーカーを再起動
• 8.5 なら fatal_error_backtraces を 0 にして、やはり全ワーカーを再起動
• 攻撃者が到達できる致命的エラーや実行時間切れを直す

注意書きが効いている。ini_set() や .user.ini に頼ってはいけない。リクエストの解析より前に適用される場所（php.ini、FPMのプール、サーバーの設定）でないと意味がない。

そしてエラーを隠しても効かない。error_reporting や display_errors、@ で消しても、状態は埋まってしまう。

結局、何をすればいいか

レンタルサーバーを使っている場合

ほとんどの人はここに当たる。

1. 提供元の告知を見る。昨日の時点で各社が緊急メンテナンスに入っていた
2. 管理画面でPHPのバージョンを自分で選んでいるなら、確認する。古い版のままだと修正が来ない
3. 対応済みの版が選べるようになったら、切り替える

自分でビルドしていないなら、待つのが基本になる。慌てて設定を触るより確実だ。

自分で管理している場合

1. 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 のいずれかへ更新する
2. ディストリビューションを使っているならそちらのパッケージを待つ。事前に配布されているとされている
3. すぐ動けないなら上の緩和策を入れる。ただし安全にはならない
4. ワーカーを再起動する。2件目の措置は再起動しないと効かない

更新のときの注意

同じ系列の中での更新（たとえば8.3系の中で上げる）なら、互換性の心配は小さい。

問題は系列をまたぐときだ。先週、古いコードは新しいPHPでも構文チェックが通るという記事を書いた。文法が通っても動きが変わる部分がある。

とはいえ今回は急ぐ理由がはっきりしている。認証もログインも要らない攻撃なので、直すまでの時間がそのまま危険の長さになる。

この件の位置づけ

一昨日、今月の不正アクセスが多い理由を書いた。そこで挙がっていた指摘を、もう一度置いておく。

AIによる自動化を前にすると、CVSSの優先度は関係ありません。やられるか、やられないか、のどちらかです。

今回は優先度を考える必要すらない。9.2で、認証不要で、PHPそのものにある。

更新できる人は、今日のうちに。できない人は、提供元の告知を見る。

まとめ

• CVE-2026-109618（メモリ不足の処理）とCVE-2026-109619（前のリクエストの残骸）
• いずれもCVSS 9.2。認証不要の遠隔コード実行
• 修正版は8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
• 危険なのはWebを提供しているすべてのPHP環境。mod_phpが最も高い
• アプリのコードが動く前に成立しうる。中身は関係ない
• 7.4 / 8.0 / 8.1 にも最小限のバックポートが例外的に提供された
• 公式いわく「完全な緩和策は無く、更新だけが唯一の安全な選択」
• 緩和策の1つはmemory_limit を -1 にするという、直感に反するもの
• レンタルサーバーなら提供元の告知を見るのが基本

出典

• PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日。修正版、対象範囲、mod_phpのリスク、7.4/8.0/8.1へのバックポート、緩和策の全文。引用の日本語は筆者による訳）
• GHSA-w8hw-w9fx-j79w（CVE-2026-109618）RCE via OOM corruption（CVSSベクター、影響バージョン、技術的な詳細）
• GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）RCE via stale global state（同上）
• PHP「Supported Versions」（各バージョンのサポート期限）

本記事は2026年10月22日時点の公表内容に基づく。緩和策はいずれも完全ではなく、公式は更新のみが安全な解決であるとしている。設定の変更は環境によって影響が異なるため、適用の前に必ず公式のアドバイザリ本文と、利用しているサービスの告知を確認すること。本記事は法的な助言ではない。