新たに公表されたPHP2Shellの脆弱性（CVE-2026-109618およびCVE-2026-109619）は、世界中のWebインフラストラクチャに対してCVSSスコア9.2という重大な脅威をもたらし、PHPコアエンジン内で認証不要のリモートコード実行や機密メモリの漏洩を可能にします。
今すぐダウンロード
主なポイント：
- CVE-2026-109618 および CVE-2026-109619（総称して「PHP2Shell」として追跡されている）は、PHP コアエンジンにおける重大（CVSS 9.2）なメモリ安全性の脆弱性であり、認証不要のリモートコード実行や、機密性の高いプロセスメモリの漏洩を可能にするものです。
- PHPは世界中のウェブサイトの約70％を支えているため、WordPress、Drupal、Joomla、Magento、およびカスタムエンタープライズツールを含む事実上すべてのウェブプラットフォームは、アプリケーションレベルのセキュリティ対策の有無にかかわらず、攻撃の標的となる可能性があります。
- PHPのコードベースには、10年以上にわたり根本的なバグが存在していた（PHP 5.4以前のバージョンにも影響を及ぼしていた）ものの、最先端のAIモデルによって、異なるサーバー環境間でこれらのメモリ上の欠陥を連鎖させ、適応させるために必要だった複雑さの障壁が取り除かれた。
- この脆弱性の詳細は、パッチのリリース予定日よりも早い10月20日にオンライン上で流出しており、脅威アクターがインターネットを積極的にスキャンし、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は全ウェブサイトの約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日の夕方から21日の早朝にかけて、CERT-EUをはじめ、英国、ドイツ、オランダ、日本、オーストラリアの各国の機関を含むサイバーセキュリティ当局は、管理者に対し緊急パッチの適用に備えるよう促す緊急警告を発しました。CERT-EUは特に、直ちにパッチを適用できない組織に対し、脆弱性のあるPHPウェブサイトをオフラインにすることを検討するよう助言しました。 この指針に従い、いくつかの政府ポータルサイトや、任天堂などの組織が運営する商用サービスを含む数百のウェブサイトが、パッチのリリースに先立ち、一時的に運用を停止した。
2026年10月21日、UTC 13時35分頃（予定されていたUTC 14時より前）、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は、インターネット上の全ウェブサイトの約70％を支えていると推定されている, WordPress、Drupal、Joomla、Magento、ウィキペディアのMediaWikiといった主要なコンテンツ管理システムや、顧客データやビジネスロジックを扱う数え切れないほどの社内エンタープライズアプリケーションの基盤となっています。PHP2Shellの脆弱性は、特定のアプリケーションコードではなくPHPコアエンジン自体に存在するため、Webリクエストを処理するすべてのPHPインストール環境がリスクにさらされています。これには、PHP-FPMやApacheと mod_php, php-cgi、FrankenPHP、およびLiteSpeed。影響を受けるPHPバージョン上で実行される、ごく基本的な「Hello World」スクリプトでさえも、この脆弱性の影響を受けます。PHPセキュリティチームは、Apacheにおけるリスクが最も高いと評価しています。 mod_php デプロイメントにおいて、認証されていないリクエストが、アプリケーションコードが実行される前にこの脆弱性を悪用してしまう可能性がある。
さらに、世界中で何百万ものウェブサイトが、もはや積極的なサポート対象外であり、簡単に更新することもできない旧式のPHPバージョンを引き続き使用しています。PHP 5.4にさかのぼる過去10年間のほぼすべてのPHPリリースにおいて、これらの脆弱性のうち少なくとも1つが確認されています。
PHP2Shellの発見と武器化は、脆弱性悪用の経済性における転換点ともなっている。根本にあるメモリ安全性の欠陥は、10年以上にわたりPHPのコードベースに隠されたままだった。というのも、これらを実用的なエクスプロイトに変えるには、複数の複雑なバグを連鎖させ、リクエストごとの正確なメモリ割り当てを考慮する必要があったからだ。従来、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のSessionモジュールは、アップロード進行状況の処理中にセッション状態を初期化し、PS(id)にセッションIDポインタを格納することができます。クリーンアップが完了する前にメモリ不足エラーによってリクエストが中断された場合、PHPはリクエストヒープを破棄しますが、PS(id)は解放されたメモリ領域を指し続けたままになります。 その後、同じPHPワーカーによって別のマルチパートリクエストが処理されると、通常のセッション初期化によってポインタがリセットされる前に、アップロード進行状況のクリーンアップパスに到達してしまいます。 PHPはこのダングリングポインタを有効な zend_string として信頼し、回収されたヒープの内容を直接 URL エンコードして PHPSESSID レスポンスクッキーに格納します。これにより、ホストされているアプリケーションが session_start() を一度も呼び出していなくても、攻撃者は他のリクエストからパスワード、API キー、認証トークン、証明書を含む有効なワーカーメモリの領域をリモートで読み取ることが可能になります。
その同じ初期化前のウィンドウにおいて、セッションのアップロード進行状況ハンドラもセッションデータをデコードし、リクエスト固有の管理情報をグローバルなBG（アンシリアライズ）状態に格納することができます。致命的なメモリ割り当ての失敗により、この処理パスが中断され、リクエストヒープが破壊され、アンシリアライザのグローバル状態が公開されたままになります。 その後、同じワーカーへのリクエストにおいて、PHPは攻撃者が回収したメモリを、アクティブなアンシリアライザの管理情報として消費します。この「use-after-free」のプリミティブと、アドレス配置の不確実性を回避するためのPHPSESSIDメモリ漏洩を組み合わせることで、攻撃者はプロセスのメモリを破損させ、認証不要のリモートコード実行を実現できます。
CVE-2026-109619: 古いグローバル状態およびOPcacheの型混同を悪用したリモートコード実行
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) は、リクエストに固有の内部状態が、その基盤となるメモリが解放された後も残存してしまう問題です。これにより、同じワーカー上で実行される後続のリクエストが、通常の初期化によってリセットされる前に、古い状態にアクセスできてしまう可能性があります。
このCVEに該当する最初のプリミティブは、致命的なエラーのバックトレースを悪用するものです（特に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の保護機能は、着信するHTTPトラフィックを検査し、脆弱性のあるPHPワーカーに到達する前にエクスプロイトのペイロードをブロックするという、不可欠な第一防衛線となります。 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 ベンダーに連絡してバックポートされた修正プログラムを入手するか、サポート対象のブランチにアップグレードするか、あるいは PHP セキュリティチームがバージョン 7.4、8.0、および 8.1 向けに提供している最小限のバックポートを使用してソースからコンパイルする必要があります。
実行時の設定に関する回避策
すぐにパッチを適用できない環境では、 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、あるいは @ （オペレータは基となる状態へのアクセスを阻止しない）こと、およびアップロードやコールバックルーチンにおいて、攻撃者が到達可能な致命的なエラーや実行タイムアウトをすべて解決すること。
検知と脅威ハンティング
すべてのシステムにパッチが完全に適用されるまでは、セキュリティ運用チームは、Webサーバーおよびプロキシのテレメトリを監視し、悪用された兆候がないか確認する必要があります。主な兆候としては、異常なほど大量のマルチパートHTTPリクエストが集中して発生し、その後にメモリ制限エラーやHTTP 500（サーバー内部エラー）が繰り返し返される場合、予想外に大きなサイズのリクエストや形式が不正なリクエストなどが挙げられます。 PHPSESSID 送信側のHTTPレスポンスに含まれるクッキー、および原因不明のPHPワーカープロセスの頻繁な切り替えやクラッシュ。
私のRadware製品は影響を受けますか？
Radwareは、自社の製品ポートフォリオに対するCVE-2026-109618およびCVE-2026-109619の影響を評価するとともに、サイバー防御製品およびクラウドセキュリティサービスを通じて、予防的な保護措置を積極的に講じています。お客様は、すべての製品およびサービスに関する最新情報や詳細な対策手順について、カスタマーポータルに掲載されている本アドバイザリをご確認ください。
Radwareのセキュリティ研究チームは、実環境における悪用状況を継続的に監視しており、新たな情報が入り次第、Radwareの顧客ポータル上で顧客向けガイダンスを更新する予定です。
1 GitHubセキュリティアドバイザリにおけるCVE-2026-109618の識別子