PHPの脆弱性2件に緊急修正、認証なしでサーバーを乗っ取り可能に：2年前から問題を把握も修正が難航

PHP開発チームは2026年10月21日、認証なしでサーバー上のコードを実行されるおそれがある2件の重大な脆弱性を修正し、PHP 8.5.12、8.4.27、8.3.36、8.2.35を公開した。いずれの脆弱性もCVSSスコアは9.2（Critical）と評価されている。公式告知では、すべての利用者に速やかな更新を強く推奨しており、設定変更だけで完全に防ぐ方法はない。さらにPHP Foundationは、今回の問題の一方について、2024年の時点で兆候を把握していたものの、互換性への影響や開発人員の不足から修正が難航していたことも明らかにした。

「PHP2Shell」と呼ばれる今回の脆弱性は、CMSやプラグインではなく、その基盤となるPHP本体に存在する。修正版の公開に向けた準備を伝えた既報の段階では詳細が明らかになっていなかったが、今回の公開によって、脆弱性の仕組みと設定変更による対策の限界が判明した。さらに、問題の発見から修正、公開までに長い時間を要した背景も浮かび上がっている。

2件とも異常終了時のメモリ管理に問題

1件目のCVE-2026-109618は、メモリ不足が発生した際のエラー処理に起因する。従来のPHPは、メモリの確保に失敗するとlongjmp()を使い、実行中の処理から抜ける仕組みを採用していた。しかし、内部データの初期化が完了していない段階で処理が中断されると、リクエストの終了処理が不完全なデータを正常なものとして扱ってしまう場合がある。単にメモリ不足でプログラムが停止するだけでなく、不正なメモリアクセスを引き起こし、最終的に任意のコードを実行される可能性がある点が深刻だ。

PHPをApacheに組み込んで動作させるmod_php環境では、アプリケーションのコードが実行される前に、この脆弱性を悪用できることが実証されている。HTTP経由で認証なしのコード実行が確認されており、攻撃に成功すると、Webリクエストを処理するワーカーの権限でコードが実行される。一般的な入力サイズやメモリ上限を設定した環境、複数のワーカーを使う構成でも攻撃が成立したという。

2件目のCVE-2026-109619は、問題のあるメモリ状態が次のリクエストに持ち越される脆弱性だ。致命的なエラーによって後始末が省略されたり、終了処理中に発生した警告によって内部情報が再登録されたりすると、すでに解放されたメモリへの参照がワーカー内に残ることがある。その後、同じワーカーが次のリクエストを受け付け、通常の初期化処理が始まる前にその参照を使うと、解放済みメモリへの不正なアクセスが発生する。つまり、あるリクエストで生じた異常が、その後の別のリクエストに影響する仕組みだ。

こちらの脆弱性については、mod_phpだけでなく、PHP-FPMでもセッション処理を通じたコード実行が検証されている。ただし、PHP-FPMで実証された攻撃には、アプリケーション側の処理が始まった後に致命的なエラーが発生し、さらに同じワーカーが次のリクエストを処理するという条件がある。そのため、すべてのPHP-FPM環境で同じHTTPリクエストを送れば攻撃が成功するわけではない。

Wizの研究チームは、検証時点で最新だったコンテナを使い、WordPress、Drupal、Joomlaで認証不要のコード実行に成功したと発表した。これらは検証に使用したアプリケーションであり、影響が3製品に限定されるわけではない。また同社は、コード実行に至らない場合でも、PHPプロセスのメモリからパスワードや認証トークンなどを読み出せることを確認している。脆弱性がPHP内部に存在する以上、アプリケーションの認証処理やプラグインを修正するだけでは根本的な解決にならない。

設定変更やWAFだけでは攻撃を防ぎきれない

PHP2Shellへの暫定対策を考える際には、メモリ不足を引き起こす経路と、リクエストをまたいで不正な状態が残る経路を区別する必要がある。例えば、アップロード進捗の追跡を無効にしても、メモリ制限を変更しても、それだけで2件の脆弱性をまとめて解消することはできない。10月21日に公開された公式アドバイザリの「Mitigation」節と、Cloudflareの対策説明を基に、主な暫定対策とその限界を整理すると次のようになる。

暫定的な対策	軽減できる攻撃経路	残るリスク・制約
管理者がmemory_limit=-1を強制する	PHPのメモリ上限に達することで発生する、制御可能なメモリ不足	OSなど下位層でのメモリ確保失敗は防げない。可用性を確保するため、Webサーバーなどでの入力制限も必要
session.upload_progress.enabled=0	実証されたアップロード進捗のセッション処理を悪用する経路	ほかの経路で内部状態が残る問題までは解決しない
PHP 8.5でfatal_error_backtraces=0	実証された致命的エラーのバックトレースを悪用する経路	ほかの内部状態には対応せず、PHP 8.5以外にも適用できる対策ではない
CloudflareのWAFによる通信遮断	同社の検知ルールに該当する攻撃通信	PHP本体の脆弱性は修正されないため、CloudflareもPHPの更新を推奨している

これらは対策ごとの適用範囲を整理したものであり、防御性能の優劣を示すものでも、利用可能な設定を網羅したものでもない。PHPのメモリ上限を解除する場合は、アプリケーション側から設定を上書きできないようにするとともに、Webサーバーやリバースプロキシで入力サイズを制限するなど、サービスの安定稼働にも配慮する必要がある。公式アドバイザリは、代替策としてRLIMIT_ASやRLIMIT_DATAを使うと、問題となるメモリ確保失敗を引き起こす可能性があると警告している。

設定を適用する場所にも注意が必要だ。アップロード進捗の無効化は、HTTPリクエストの解析が始まる前に反映される設定で行う必要があり、PHPコード内のini_set()やPHP-FPMの.user.iniに頼ることはできない。また、設定変更後にはすべてのワーカーを再起動しなければならない。エラー表示を無効にしたり、ログに異常が記録されていなかったりしても、それだけで攻撃を防げているとは判断できない。

Cloudflareは、HTTPリクエストの内容だけでは攻撃と正常な通信を区別しにくい場合に対応するため、リクエストとレスポンスの両方を調べる防御を導入した。サーバーから返される応答にも着目して攻撃の兆候を検出し、該当するレスポンスを利用者に届く前に遮断する仕組みだ。同社は実際に攻撃通信を観測したことも明らかにしているが、通信を検出したことと、攻撃者による侵入が成功したことは区別する必要がある。いずれにしても、WAFは補助的な防御手段であり、PHP本体の更新に代わるものではない。

今回の修正版では、設定変更に頼らず、問題の根本原因に対処するための仕組みが導入された。メモリ不足が発生した場合、すぐに処理を中断するのではなく、安全に処理できる地点までエラー処理を遅らせる方式に変更されている。さらに、より高いメモリ上限に達した場合にはプロセスを直ちに終了させ、不完全な内部状態で処理が続くことを防ぐ。リクエスト間で保持してはならない内部状態についても、広くリセットするよう改められた。これにより、PHPのメモリ制限を維持しながら、異常終了時の後始末が新たな脆弱性を生む問題に対処している。

更新に際しては、Linuxディストリビューションや長期サポートの提供元が配布する修正パッケージも確認する必要がある。PHP 8.1以前のバージョンはPHPプロジェクトによる通常サポートが終了しているものの、今回はPHP 7.4、8.0、8.1向けにも最小限のソース修正が用意された。これは独自にPHPをビルドしている利用者などが脆弱性へ対処できるようにするための措置であり、旧バージョンの継続サポートが再開されたわけではない。

2024年に把握していた問題が緊急修正に至るまで

PHP Foundationの説明によると、メモリ不足に関する問題の兆候は、2024年の時点ですでに見つかっていた。Quarkslabによる外部セキュリティ監査で指摘された問題を修正する過程で、Foundationと契約するPHPコア開発者が気付いたという。当時から悪用される可能性は認識されていたものの、具体的な攻撃経路は見つかっていなかった。そのため、実際の影響が明らかになっている別の問題が優先され、今回の脆弱性への対応は後回しになった。

修正が難航した理由は、技術的な問題にもあった。検討された修正案には、既存のコードとの互換性を損なうもの、新たなサービス妨害のリスクを生むもの、多数のPHP拡張機能に変更を求めるものがあり、簡単には方針を決められなかったという。全員の合意を重視するセキュリティチームの意思決定方式も、判断を難しくする要因となった。さらに、PHPエンジンの内部構造を熟知する開発者は少なく、それぞれがほかの業務も抱えていたため、修正作業は数カ月にわたって中断と再開を繰り返した。

Foundationは今回の経緯について、修正の遅れはセキュリティチームの意思決定プロセスとリソース不足に起因する「構造的な失敗」だったと認めている。問題の存在を認識していても、互換性や安定性を確保した修正方法を決定し、実際に配布するまでには大きな隔たりがあった。脆弱性を発見する能力だけでなく、難しい技術的判断を迅速に下せる開発体制が必要だったことを示す経緯だ。

状況が変わったのは、2026年8月に具体的な攻撃実証が報告されてからである。Foundationによると、CalifとOpenAIが同じ根本原因をそれぞれ独立に報告し、その後、Wizなどからも新たな攻撃経路が報告された。これによって脆弱性の影響が明確になり、Foundationのセキュリティ担当者は修正を最優先事項と位置づけた。今回の発見は、AIがまったく知られていなかった問題を一から見つけたという単純な話ではなく、以前から認識されていた危険性について、具体的な悪用方法が明らかになったという側面がある。

公開直前には、修正版をいつ配布するかという問題も生じた。10月20日にCVE番号などの情報が流通し始めたことを受け、PHP開発チームは当初予定していた10月22日14時UTCから、21日14時UTCへと公開を1日前倒しした。Foundationによれば、Linuxディストリビューションなどの配布元はまだ更新パッケージの準備を進めており、直ちに公開すると、修正版を簡単に適用できない利用者が残るおそれがあったという。こうした事情を踏まえ、1日の前倒しが妥協点として選ばれた。修正コードが完成しても、利用者が実際に更新できる状態を整えるには、別の準備期間が必要だったのである。

AIが短縮する脆弱性の実証時間と、保守者に残る課題

OpenAIの発表によると、Califは「Patch the Planet」の取り組みの中で、GPT-5.6 Solを使って今回の問題を発見した。一方、独立に脆弱性を発見したWizも、Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを調査に活用したことを明らかにしている。ただし、脆弱性の発見や攻撃の実証にAIが使われたことと、PHP本体の修正を完了させることは別の問題だ。実際の修正作業とリリースを主導したのは、PHPの保守者たちである。

Wizは特に、AIが複雑な攻撃手法を異なる環境へ適応させる作業を効率化する点を強調している。メモリの不正な読み書きを利用する攻撃は、PHPのバージョンや設定、メモリ配置の違いによって成否が左右される。そのため、ある環境で成功した攻撃を別の構成でも成立させるには、失敗の原因を調査し、攻撃方法を繰り返し調整しなければならない。同社の評価では、AIとテスト・デバッグ用のツールを組み合わせることで、こうした作業に必要な専門家の負担を減らせるという。防御側が脆弱性の危険性を素早く実証できる一方、修正情報の公開後には攻撃者による手法の調整も容易になる可能性がある。

一方、Foundationが今回の修正で直面したのは、既存環境との互換性とサービスの安定性をどう両立させ、誰が最終的な判断を下すかという問題だった。同財団は今後、全員の合意に固執せず、多数決や妥協による意思決定を可能にする方向で手続きを改めるとしている。また、対応が難航している案件を早期に指導部へ報告する仕組みも整備する方針だ。PHP全体の内部構造に精通した開発者を増やすため、PHPを利用する企業などに継続的な資金支援も呼びかけている。

OpenAIが提案する脆弱性の協調的な開示手順も、問題の発見と修正だけでなく、配布元による準備から公開後の更新適用までを含むものだ。今回の緊急更新で重要なのは、修正版が公開されたという事実だけでなく、実際に外部からの通信を処理しているPHP環境へ修正が行き渡るかどうかである。そして、今後同様の重大な問題が見つかった際に迅速に対応するには、AIによる発見・実証の効率化に加え、互換性や安定性への影響を検証し、必要な判断を下せる保守者の確保が欠かせない。