新しく開示されたPHP2Shellの脆弱性（CVE-2026-109618およびCVE-2026-109619）は、世界のWebインフラストラクチャに対してCVSS 9.2の重大な脅威をもたらします。これにより、コアPHPエンジン内で未認証のリモートコード実行と機密メモリの漏えいが可能になります。
今すぐダウンロード
主なポイント：
- CVE-2026-109618およびCVE-2026-109619（総称してPHP2Shellとして追跡）は、コアPHPエンジンにおける重大な（CVSS 9.2）メモリ安全性に関する脆弱性であり、未認証のリモートコード実行および機密性の高いプロセスプロセスメモリの漏えいを引き起こします。
- PHPは世界中のすべてのWebサイトの約70%を支えているため、WordPress、Drupal、Joomla、Magento、カスタムエンタープライズツールなど、事実上すべてのWebプラットフォームが、アプリケーションレベルのセキュリティに関係なく危険にさらされています。
- 根本的なバグは1十年以上にわたりPHPのコードベースに存在していましたが（PHP 5.4以降のバージョンに影響）、現代の最先端AIモデルにより、異なるサーバー環境間でこれらのメモリの欠陥を連鎖させ適応させるために必要だった複雑性の障壁が取り除かれました。
- 脆弱性の詳細が予定されていたパッチのリリース前にオンラインで流出したため、脅威アクターがインターネットを積極的にスキャンし、AIを利用してエクスプロイトの作成を自動化する中で、修正のための猶予期間が大幅に短縮されました。
- 唯一の完全な対策は、PHP 8.5.12、8.4.27、8.3.36、または8.2.35へのアップグレードです。同時に、Security Update Services（SUS）を通じてRadware Web Application Firewall（WAF）のシグネチャを展開し、即座の暫定的な保護としてランタイム設定のハードニングを適用する必要があります。
新しく開示されたPHP2Shellの脆弱性（CVE-2026-109618およびCVE-2026-109619）は、世界のWebインフラストラクチャに対してCVSS 9.2の重大な脅威をもたらし、コアPHPエンジン内での未認証のリモートコード実行および機密メモリの漏えいを可能にします。PHPはすべてのWebサイトの約70%を支えているため、特定のアプリケーションロジックやセキュリティ体制に関係なく、ほぼすべてのプラットフォームとカスタムアプリケーションがエンジンレベルで危険にさらされています。このリスクをさらに悪化させているのが、調整されたパッチのリリース前に脆弱性の詳細が流出した点です。これにより、組織が防御を配備する前に、攻撃対象領域に対して脅威アクターがAI支援による自動エクスプロイト生成を活用するための決定的な先手をとる結果となりました。
迅速な緩和策には多層防御アプローチが必要であり、永続的な修復策としてアップストリームのエンジンパッチ（PHPバージョン 8.5.12、8.4.27、8.3.36、または8.2.35）の適用を最優先とする必要があります。直ちにパッチを適用できない組織の場合は、Security Update Services（SUS）経由でRadware Web Application Firewall（WAF）のシグネチャを展開して不正なマルチパートリクエストをインターセプトし、着信するエクスプロイトペイロードをブロックすることで、暫定的な保護を確立しなければなりません。この境界防御は、パッチが完全に適用されるまでの間、稼働中のPHPワーカープロセスを隔離して保護するために、セッションアップロードプロセスの無効化や厳格なメモリ制限の強制といった厳格なランタイム設定のハードニングによって積極的に強化される必要があります。
概要とタイムライン
2026年10月20日の夜、コアスクリプトエンジンであるPHPの2つの重大な脆弱性に関する詳細とCVE識別子が、予定されていた調整済み開示の前にHacker Newsフォーラムに流出しました。CVE-2026-109618およびCVE-2026-109619として追跡され、総称してPHP2Shellと呼ばれるこれらの欠陥は、CVSSの深刻度評価で9.2の評価を受けています。どちらの脆弱性も、パスワードやユーザーセッションを必要とすることなく、認証されていない攻撃者がリモートで任意のコードを実行したり、Webサーバーのメモリから直接機密データを抽出したりすることを可能にします。
この早期の流出により、脅威アクターが脆弱性を認識する前に、ディフェンダーがパッチの準備のために通常頼りにしていたリードタイムが失われました。10月20日の夜から10月21日の未明にかけて、CERT-EUや、イギリス、ドイツ、オランダ、日本、オーストラリアの国家機関を含むサイバーセキュリティ当局は、管理者に緊急パッチの準備を促す警告を発令しました。特にCERT-EUは、直ちにパッチを適用できない組織に対し、脆弱性のあるPHPウェブサイトを一時的にオフラインにすることを検討するよう助言しました。このガイダンスに従い、パッチのリリース前に、いくつかの政府ポータルや任天堂などの組織による商用サービスを含む数百のウェブサイトが一時的に運用を停止しました。
2026年10月21日協定世界時（UTC）13時35分頃（予定されていたUTC 14時00分のスケジュールに先立ち）、PHP開発チームはバージョン8.5.12、8.4.27、8.3.36、および8.2.35で緊急パッチをリリースしました。脅威の深刻さを考慮し、メンテナはサポート終了となったブランチ（具体的にはPHP 7.4、8.0、8.1）向けに最小限のソースコードバックポートも提供しました。パッチが公開されて間もなく、概念実証（PoC）エクスプロイトがオンラインで出回り始めました。セキュリティ研究者は、WordPress、Drupal、Joomlaの最新のデフォルトコンテナイメージに対して、認証なしでのリモートコード実行を達成できる複合エクスプロイトスクリプトを実証しました。
リスク評価：攻撃対象領域とAIの変曲点
PHPはインターネット上のすべてのWebサイトの推定70%を支えており、WordPress、Drupal、Joomla、Magentoなどの主要なコンテンツ管理システム（CMS）やWikipediaのMediaWikiの基盤として機能しているほか、顧客データやビジネスロジックを処理する数多くの内部エンタープライズアプリケーションの基盤となっています。PHP2Shellの脆弱性は、特定のアプリケーションコード内ではなく、コアPHPエンジン自体に存在するため、Webリクエストを処理するすべてのPHPインストールが危険にさらされます。これには、PHP-FPM、Apacheと mod_php, php-cgi、FrankenPHP、LiteSpeedを実行している環境が含まれます。影響を受けるPHPバージョンで実行されている基本的な「Hello World」スクリプトでさえ脆弱です。PHPセキュリティチームは、未認証のリクエストがアプリケーションコードの実行前にエクスプロイトを引き起こす可能性があるApache mod_php のデプロイメントにおいて、リスクが最も高いと評価しています。
さらに、世界中の数百万のWebサイトが、すでに積極的にサポートされておらず簡単にアップデートできないレガシーPHPバージョンを稼働させ続けています。PHP 5.4に遡る過去10年間のほぼすべてのPHPリリースが、これらの欠陥の少なくとも1つの影響を受けています。
PHP2Shellの発見と武器化は、脆弱性エクスプロイトの経済性における転換点をもたらしました。根本的なメモリ安全性の欠陥がPHPのコードベースに10年以上にわたって隠れていたのは、それらを動作するエクスプロイトに変換するために、複数の複雑なバグを連鎖させ、リクエスト間での正確なメモリ割り当てを考慮する必要があったためです。これまで、PHPのバージョン、サーバーの設定、メモリレイアウトの違いにより、あるターゲット向けに構築されたエクスプロイトは、大規模な手動によるリバースエンジニアリングとデバッグを行わない限り、別のターゲットでは失敗していました。
PHP2Shellの発見につながった調査において、Wizの研究チームはこの溝を埋めるため、Gemini 4 ArgonやGPT-5.6 SolなどのフロンティアAIモデルを活用しました。研究チームによると、Argonは脆弱性の発見と修復支援において特に重要な貢献を果たしたとのことです。大規模言語モデルをデバッグツールと組み合わせることで、メモリ障害の分析、修正の反復、そして複雑なエクスプロイトチェーンを異なるPHPのバージョンや設定に合わせて自動的に適応させることが可能になります。脆弱性が早期に漏洩したため、脅威アクターはすでに公開されているPHPサーバーをバージョンごとにカタログ化し、AIを使用してパッチ適用前後のソースコードを比較している可能性があり、その結果、わずか数時間で動作するエクスプロイトの生成が可能になっています。
PHP2Shellの技術的解体
PHP2Shellの脆弱性は、リクエストのセットアップ、クリーンアップ、および状態管理のプロセスにおいて、アプリケーション層よりも下位で動作します。これらの欠陥は、4つの異なるメモリ破損および開示プリミティブを含む2つの主要なCVEに分類されますが、研究チームは、根本的な問題はコードベースの深部に根ざしており、他のバリアントもこれらと同じ識別子に収まるものであると指摘しています。
図1：PHP2Shellの脆弱性
CVE-2026-109618：アウト・オブ・メモリ（OOM）破損およびメモリ開示によるRCE
CVE-2026-109618（GHSA-w8hw-w9fx-j79w 1）は、内部リクエストデータが部分的にしか初期化されていない段階でアウト・オブ・メモリ処理がPHPを中断させた場合に発生します。これにより、後続のリクエストクリーンアップルーチンが無効なデータを有効なデータとして処理してしまいます。この状態を引き起こすことが確認されているベクターは、通常のモジュール初期化が完了する前の早期リクエスト起動時に実行される、RFC 1867マルチパートリクエストの解析に存在します。
この初期化前のウィンドウ内において、PHPのセッションモジュールはアップロード進捗処理中にセッション状態を初期化し、PS(id)にセッションIDポインタを公開することができます。クリーンアップが完了する前にアウト・オブ・メモリのエラーによってリクエストがアボートされた場合、PHPはリクエストヒープを破棄しますが、PS(id)は解放されたメモリ割り当てを指したままになります。同じPHPワーカーによって後続のマルチパートリクエストが処理される際、通常のセッション初期化がポインタをリセットする前に、アップロード進捗のクリーンアップパスに到達します。PHPはこのダングリングポインタを有効なzend_stringとして信頼し、回収されたヒープの内容を直接PHPSESSIDレスポンスクッキーにURLエンコードします。これにより、ホストされているアプリケーションが一度もsession_start()を呼び出していなかったとしても、攻撃者は他のリクエストからのパスワード、APIキー、認証トークン、証明書を含むライブなワーカーメモリ領域をリモートから読み取ることができます。
同じ初期化前のウィンドウにおいて、セッションのアップロード進捗ハンドラーはセッションデータをデコードし、リクエストが所有するブックキーピングをグローバルなBG(unserialize)状態に格納することも可能です。致命的なメモリ割り当て障害がこのパスを中断し、リクエストヒープを破棄して、アンシリアライザーのグローバル状態が公開されたままになります。同じワーカーに対する後続のリクエストにおいて、PHPは攻撃者によって回収されたメモリを、有効なアンシリアライザーのブックキーピングとして消費します。この解放後使用（use-after-free）プリミティブとPHPSESSIDのメモリ開示を組み合わせてアドレスレイアウトの不確定性をバイパスすることにより、攻撃者はプロセスメモリを破損させ、認証なしのリモートコード実行を達成することができます。
CVE-2026-109619：古いグローバル状態およびOPcacheの型混同によるRCE
CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）は、リクエストが所有する内部状態が、その基盤となるメモリが解放された後も存続し、同じワーカー上の後続のリクエストが通常の初期化によってリセットされる前に古い状態にアクセスしてしまうという問題を含んでいます。
このCVEにおける1つ目のプリミティブは、致命的エラーのバックトレースを悪用するものです（特にPHP 8.5に影響を与えます）。PHPは、直近の致命的エラーのバックトレースをエグゼキュータのグローバル変数EG(last_fatal_error_backtrace)に保持します。致命的なアウト・オブ・メモリのエラーが発生した場合、PHPはそのグローバル値を未定義にすることなくリクエストヒープを破棄し、その結果、生存しているワーカーには前のリクエストからの解放済みメモリへのポインタが残されます。次のリクエストの際にその同じワーカーが早期の診断メッセージを出力すると、エグゼキュータが状態を再初期化する前にダングリングポインタにアクセスしてしまいます。その後、PHPは攻撃者によって回収されたメモリを使用してダングリングバックトレースの更新または破棄を試み、リモートコード実行につながるクロスリクエストの解放後使用（use-after-free）の条件を作り出します。
2つ目のプリミティブには、OPcacheの共有メモリにおける型混同が関係しています。OPcacheはコンパイルされたPHP構造体を共有メモリに格納し、ワーカーごとのランタイムポインタマップへのインデックスを割り当てます。ワーカーは共有フロンティアを介してこれらを調整します。zend_accel_script_persist()の実行中、PHPはプロセスローカルのフロンティア（CG(map_ptr_last)）を前進させた後、完了時に更新された共有フロンティアを公開します。これら2つのステップの間でメモリ割り当て障害が発生した場合、プロセスローカルの前進は維持されたままとなり、部分的に永続化されたオブジェクトは、共有状態が依然として利用可能とみなしているスロットを参照することになります。別のワーカーがそれらのスロットの1つを別のランタイムオブジェクトのために再利用すると、古い共有メタデータが間違った型のポインタとして解決され、共有OPcacheの状態が破損し、認証なしのリモートコード実行が可能になります。
緩和策：多層防御戦略
PHP2Shellはアプリケーション層よりも下位で実行されるため、標準的なアプリケーションログには侵入に関するコンテキストがほとんど含まれないことがよくあります。そのため、防御側は多層的なアプローチに頼る必要があります。具体的には、即座に封じ込めるための境界型Webアプリケーションファイアウォール（WAF）保護の導入、パッチ適用が遅れる場合のエンジンレベルでの設定回避策の適用、サーバーのテレメトリの監視、そして恒久的な修正のためのアップストリームPHPパッチのインストールです。
Radwareによる即座の暫定防御
パッチがテストされ、本番環境全体にロールアウトされるまでの間、WebアプリケーションおよびAPI保護は、脆弱なPHPワーカーに到達する前に受信HTTPトラフィックを検査し、エクスプロイトペイロードをブロックするための不可欠な第一線となります。Radwareのセキュリティアップデートサービス（SUS）は、Cloud Application Protection、AI Xploit Shield、およびオンプレミスのAppWallやDefense Proといった保護ソリューション全体にわたり、CVE-2026-109618およびCVE-2026-109619を標的としたエクスプロイトの試行を検知・緩和するための更新されたシグネチャとポリシーを提供します。Radwareのフル・トランザクション検査およびポジティブセキュリティモデルは、厳格なHTTP準拠を強制し、異常なマルチパートリクエストのフィルタリング、過大なサイズまたは不正な形式を持つヘッダーおよびボディ構造のブロック、そしてセッションクッキーへのリークしたプロセスメモリの反映防止を行います。
恒久的な修復：PHPのアップグレード
公式のPHPセキュリティアップデートを適用することが、これらの脆弱性をその根源から排除するための唯一の完全な解決策です。管理者は直ちにPHP 8.5.12、8.4.27、8.3.36、または8.2.35にアップデートする必要があります。主要なLinuxディストリビューションおよび長期サポート（LTS）ベンダーには事前にパッチが提供されており、更新されたパッケージが配信されています。
ボランティアによって維持されている rpms.remirepo.net リポジトリに依存している組織に対しては、初期リリースの際にサードパーティリポジトリで可用性の遅延が発生したため、公式のディストリビューションパッケージに切り替えるか、ソースからビルドすることがPHPチームから推奨されています。サポートされていないバージョン（PHP 8.1以前）を実行しているレガシー環境の場合、管理者はバックポートされた修正についてLTSベンダーに問い合わせるか、サポートされているブランチへのアップグレードを行うか、あるいはバージョン7.4、8.0、および8.1向けにPHPセキュリティチームが提供する最小限のバックポートを使用してソースからコンパイルする必要があります。
ランタイム設定の回避策
直ちにパッチを適用できない環境においては、 PHPチームは、特定の攻撃経路への露出を軽減するための一時的な設定策を提示しています ただし、これによってインストール環境が完全に安全になるわけではありません。すべての設定は、アプリケーション側で上書きされないよう、サーバーまたはFastCGI Process Manager（FPM）プールレベル（例： php.ini または php_admin_value のApache/FPM設定など）で強制適用する必要があり、管理者は ini_set() または .user.ini ファイルに依存してはなりません。
への露出を軽減するには CVE-2026-109618（OOM破損）管理者は次のように設定する必要があります memory_limit = -1 また、プール、ディレクトリ、またはアプリケーションの設定によって有限の制限が再導入されていないことを確認してください。これにより制御可能なPHPメモリ制限エラーは解消されますが、根本的なシステム割り当てエラーが脆弱なコードパスに到達する可能性は依然として残ります。そのリスクを軽減するために、厳格な post_max_size （ファイルアップロードを必要としないアプリケーションでは8M、アップロードが必要な場合は32Mに設定）を強制し、 upload_max_filesize を post_max_size未満に維持してください。さらに、デコードされたリクエストサイズ、入力フィールド数、マルチパートのパート数、ヘッダー数、ネストの深さについて、Webサーバー、リバースプロキシ、またはWAFレベルで厳格な制限を課し、これらのルールが有効な Content-Length ヘッダーを持たないリクエストにも適用されるようにしてください。最後に、メモリ枯渇時に影響を受けるワーカープロセスのみを終了するように構成された可用性の境界として、コンテナまたはLinuxの cgroup 制限を使用してください。 RLIMIT_AS または RLIMIT_DATAこれらは脆弱な割り当てエラーを直接引き起こすため、使用しないでください。
への露出を軽減するには CVE-2026-109619（ステールグローバルステート）管理者は次のように設定する必要があります session.upload_progress.enabled = 0 すべてのPHPワーカーを再起動することで、確認されているセッションのアップロード進捗に関する悪用経路をブロックします。PHP 8.5環境では、さらに以下を設定してください。 fatal_error_backtraces = 0 すべてのワーカーを再起動し、致命的なバックトレースベクターを塞ぎます。また、管理者は、エンジン初期化前に診断警告を発出する無効または非推奨のリクエスト単位の設定をすべて削除する必要があります（警告を隠蔽するだけでは、 error_reporting, display_errorsや @ 演算子を使用しても、基盤となる状態へのアクセスは防止できない点に注意してください）。さらに、アップロードルーチンやコールバックルーチンにおける、攻撃者が到達可能な致命的エラーや実行タイムアウトを解決してください。
検出と脅威ハンティング
すべてのシステムのパッチ適用が完了するまで、セキュリティ運用の担当チームは、ウェブサーバーおよびプロキシのテレメトリーを監視し、悪用の兆候を確認する必要があります。主な兆候には、マルチパートHTTPリクエストの異常なバーストに続くメモリ制限エラー、またはHTTP 500内部サーバーエラーの頻発、予期せず巨大化または不正に形成された PHPSESSID Cookie（送信側HTTPレスポンス内）、およびPHPワーカープロセスの説明のつかない頻繁な再起動やクラッシュが含まれます。
Radware製品への影響はありますか？
Radwareは、自社製品ポートフォリオに対するCVE-2026-109618およびCVE-2026-109619の影響を評価すると同時に、当社のサイバー防御製品およびクラウドセキュリティサービスを通じて予防的な保護を積極的に提供しています。お客様はカスタマーポータルにてこのアドバイザリを確認し、すべての製品・サービスの更新情報や詳細な緩和策手順をご確認ください。
Radwareのセキュリティ研究者は、実際の環境（in-the-wild）における悪用活動を引き続き監視しており、新しい情報が入り次第、Radwareカスタマーポータルでお客様向けガイダンスを更新します。
1 CVE-2026-109618のGitHubセキュリティアドバイザリ識別子