PHPチームは2026年10月21日、認証なしのリモートコード実行（RCE）につながる2件の脆弱性を修正したPHP 8.2.35、8.3.36、8.4.27、8.5.12を公開しました。CVE-2026-109618とCVE-2026-109619は、PHPのコアにあるメモリ処理の不整合を悪用できる問題です。
PHPを使う企業が確認すべき対象は、WordPressやDrupalなどのアプリだけではありません。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHPの実行環境そのものが対象になります。
CalifはOpenAIのPatch the PlanetでGPT-5.6 Solを使って欠陥を見つけ、Wizも独立して2件を発見・報告しました。発見の背景にAIがあっても、企業の判断は変わりません。実行中のバージョンを特定し、修正版へ更新し、ワーカーの再起動まで確認することが出発点です。
※本記事は2026年10月28日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
PHP2Shellとは｜PHP本体のメモリ不整合を狙う2件
PHP2Shellは、CVE-2026-109618とCVE-2026-109619をまとめて呼ぶ名称です。どちらもアプリケーションの入力チェックだけで防ぐ種類の問題ではなく、PHPがリクエストを処理してメモリを解放・再利用する境界で発生します。
CVE-2026-109618は、メモリ不足（OOM）が起きたときの処理が、初期化途中のリクエストデータを不正な状態のまま残す問題です。PHPの終了処理がその状態を読み取ることで、プロセスメモリの開示やメモリ破壊につながります。
CVE-2026-109619は、リクエスト専用の内部状態が、所有するメモリの解放後もワーカーのグローバル状態に残る問題です。同じワーカーが後続リクエストを処理すると、解放済みメモリを使うuse-after-freeが起こり、メモリ開示やRCEにつながる可能性があります。
WizはPHP2Shellを使い、当時の最新コンテナイメージにあるWordPress、Drupal、Joomlaで認証なしのRCEを実証しました。これは各CMSに共通する欠陥という意味ではありません。脆弱なコードがPHP本体にあるため、PHP上で動くアプリケーション全体が影響を受けます。
ポイント
CMSやプラグインの更新状況だけで判定せず、Webリクエストを受けるPHPのSAPI、実行バージョン、配布元パッケージを確認します。
影響範囲と修正版｜5.4以降に広がるが更新先は4系統
Wizは、過去10年にリリースされたPHPの各バージョンが少なくとも1件の影響を受け、PHP 5.4までさかのぼると説明しています。PHP公式が今回公開した修正版は、現在の4つの系列に対応する次のバージョンです。
| 利用中の系列 | 修正版 | 確認すること |
|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.12以上か。 |
| PHP 8.4 | 8.4.27 | 8.4.27以上か。 |
| PHP 8.3 | 8.3.36 | 8.3.36以上か。 |
| PHP 8.2 | 8.2.35 | 8.2.35以上か。 |
PHP公式の2つのGitHub advisoryはいずれも、各系列の修正版未満を影響バージョンとしています。CVSS v4.0は9.2で、攻撃者の権限やユーザー操作を必要としない一方、攻撃の複雑さと前提条件はある、という評価です。
PHP 8.1以前は、PHPプロジェクトの通常の更新対象ではありません。利用しているLinuxディストリビューションやLTSベンダーが修正をバックポートしているかを確認し、提供されない場合はサポート対象の系列へ移行する計画を立てます。PHP公式はPHP 7.4、8.0、8.1向けに、ソースからビルドする利用者向けの最小限のソースバックポートも案内しています。
ポイント
「PHP 8.1.35のように数字が新しいから安全」とは限りません。PHP 8.1以前は、利用するベンダーがPHP2Shellの修正をバックポートしたかを別途確認します。
AIが発見を加速した理由｜攻撃面の広い基盤を協調して修正
OpenAIによると、Patch the PlanetではCalifがGPT-5.6 Solを使ってPHPの重大な欠陥を特定しました。Wizも独立に2件を発見・報告しており、PHPのメンテナーが修正とリリースを主導しました。
AIが担ったのは、長期間残っていたコードの状態を読み解き、複数のメモリ処理を組み合わせた攻撃可能性を検証する作業です。Wizは、PHPのバージョン、設定、メモリ配置の違いに合わせて解析やデバッグを繰り返す作業の負担をAIが下げたと説明しています。
今回の発表を「AIが脆弱性を見つけたニュース」で終わらせると、企業側の課題を見失います。AIによる発見が速くなるほど、資産台帳にないPHP、更新されていないコンテナ、再起動されていないワーカーが残る時間を短くしなければなりません。
AI基盤のランタイムや依存パッケージも同じ問題を抱えます。過去のRayフレームワークのRCE脆弱性でも、利用サービスの名前だけでなく、実際に公開されている管理インターフェースと実行環境を確認する必要がありました。
ポイント
AIによる発見速度に対抗する最初の施策は、特別なAI製品ではありません。実行環境を洗い出し、修正版を配布し、再起動後の実効バージョンを記録する運用です。
まず確認する4項目｜実行中のPHPと更新経路を分けて棚卸し
PHP2Shellの確認では、サイトの管理画面だけを見ても不十分です。アプリケーションの構成管理、コンテナ定義、ホスティングの契約情報、サーバー上の実行プロセスを照合します。
- 公開範囲：インターネットからWebリクエストを受ける本番・検証・管理系の入口を分けて記録します。
- 実行方式：PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedのどれが動いているかを確認します。
- 実効バージョン：コンテナのタグではなく、稼働中のプロセスとパッケージのバージョンを確認します。
- 更新後の状態：パッケージ更新、全ワーカー再起動、ヘルスチェック、記録の順で完了を確認します。
OpenAIは、サーバーにアクセスできる場合のphpcheck-serverと、URLだけで確認するphpcheck-urlを公開しています。URL方式はX-Powered-ByやServerのヘッダーを読むため、ヘッダーが隠されていればUNKNOWNになります。
checkerがOKを返しても、インストールそのものを検証したことにはなりません。HTTPヘッダーからは、ディストリビューションがバックポートした修正の有無を判定できないためです。URLチェックは外部からの初期確認に使い、最終判断はサーバー、コンテナイメージ、パッケージ管理の記録で行います。
公開資産の棚卸しは、PHPだけの作業ではありません。認証なしで公開される管理面がないかを点検する際は、MCPサーバーのセキュリティ実態で扱った公開範囲と認証境界の確認方法も参考になります。
ポイント
外部チェッカーは初期スクリーニングです。OKの表示だけで完了にせず、実行プロセス、配布元の修正、ワーカー再起動まで一つの記録にまとめます。
更新までの暫定対応｜設定変更は部分的な露出低減に限る
PHP公式は、修正版への更新が唯一の完全な対策だと明記しています。更新できない場合に案内される設定変更は、特定の攻撃経路を狭めるための暫定策です。安全になったと判断して更新を後回しにしてはいけません。
CVE-2026-109618には、管理者が強制するmemory_limit=-1、低いpost_max_size、入力変数やmultipartの数・サイズの制限などが案内されています。CVE-2026-109619には、session.upload_progress.enabled=0、PHP 8.5ではfatal_error_backtraces=0が案内されています。
設定変更は、適用場所にも注意が必要です。PHP公式は、ini_set関数やFPMの.user.iniに頼らず、php.ini、FPMプール、サーバー設定など、リクエスト処理の前に適用される場所を使うよう説明しています。変更後は全PHPワーカーを再起動し、実際の設定とプロセスが変わったことを確認します。
PHP公式は2026年10月23日にも、別の限定的なRCE経路について、次の通常のバグ修正版までsession.upload_progress.enabled=0を設定するよう案内しました。これもPHP2Shellの修正版への更新を置き換えるものではありません。設定変更を採用する場合は、対象、適用期限、更新担当、解除条件をチケットに残します。
Wizは10月27日、同社のテレメトリーで脆弱なインターネット公開マシンが約67%減り、影響を受ける組織数が約47.9%減ったと報告しました。観測した試行では完全なエンドツーエンドの公開PoCによる成功を確認していないとも説明していますが、これは観測範囲の結果です。更新を止める理由にはなりません。
よくある質問
Q. PHP2Shellは何を狙う脆弱性ですか？
PHP本体のメモリ処理を狙い、認証なしのRCEやプロセスメモリの開示につながる2件の脆弱性です。
Q. どのPHPバージョンに更新すればよいですか？
PHP 8.5は8.5.12、8.4は8.4.27、8.3は8.3.36、8.2は8.2.35以上に更新します。
Q. PHP 8.1以前はどう対応しますか？
ベンダーのバックポートを確認し、提供されなければサポート対象のPHPへ移行します。
Q. 更新できない場合に設定変更だけで安全になりますか？
安全にはなりません。設定変更は特定の攻撃経路の露出を下げる暫定策で、PHP公式が示す完全な対策は修正版への更新です。
まとめ
PHP2Shellは、PHPのコアにあるメモリ処理の不整合を利用して、認証なしRCEやメモリ開示につながる2件の脆弱性です。PHP公式が示す修正版は8.2.35、8.3.36、8.4.27、8.5.12で、PHP 8.1以前はベンダーのバックポート確認が必要です。
企業の担当者は、まず公開資産と社内Webを含むPHPの実行環境を列挙し、SAPI、実効バージョン、配布元、修正の有無を確認します。更新後は全ワーカーを再起動し、ヘルスチェックと記録まで完了させます。
ポイント
設定変更や外部checkerは、更新完了までの確認手段です。PHP2Shellへの対応完了は、修正版の実行、ワーカー再起動、実効状態の再確認で判定します。
関連記事
- RayフレームワークのRCE脆弱性を解説｜AI学習基盤を狙う攻撃への対応ポイント
- MCPサーバーのセキュリティ実態を解説｜21000台超が露出・92%認証なしの点検ポイント
- AIエージェントの「封じ込め失敗」が相次ぐ理由を解説｜Anthropic・Googleの公表事案に学ぶ隔離設計
- AgentOpsを解説｜AIエージェントの可観測性・評価・監視のポイント
- AIコーディングエージェントが社内画面を公開リポジトリに流出を解説｜1.3万枚・300組織超
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。