コンテンツへスキップ
ホーム » PHP2Shell:PHPエンジンのコア部分におけるRCE脆弱性CVE-2026-109618・109619分析

PHP2Shell:PHPエンジンのコア部分におけるRCE脆弱性CVE-2026-109618・109619分析

2026年10月20日、正式公開前にあったPHPエンジンのコア部分における2件のリモートコード実行(RCE)脆弱性に関する情報が外部に流出しました。これを受け、PHPセキュリティチームは公開予定を1日前倒しし、10月21日14:00(UTC)に緊急セキュリティアップデートをリリースしました。

セキュリティ業界で「PHP2Shell」と呼ばれるこれらの脆弱性は、CVE-2026-109618とCVE-2026-109619で、いずれもCVSS v4.0で9.2(Critical)と評価されています。

今回の脆弱性が特に危険なのは、問題が特定のCMSやプラグインではなく、PHPランタイム自体に存在する点です。Webリクエストを処理するほぼすべてのPHPサーバーが影響を受ける可能性があり、一部の環境ではアプリケーションコードが実行される前に、認証なしで攻撃が成立します。つまり、アプリケーション側のログイン機能や入力検証、セキュアコーディングだけでは防ぐことができません。

本記事では、PHP2Shellと総称される2つの深刻なRCE脆弱性、CVE-2026-109618とCVE-2026-109619を技術的に分析します。さらに、Criminal IP IT資産検索を活用し、実際にインターネット上に公開されているPHPの攻撃対象領域の規模とリスク分布を確認します。

PHP2Shell脆弱性の概要

項目内容
脆弱性IDCVE-2026-109618 / CVE-2026-109619(PHP2Shell)
影響を受ける製品PHP(コアランタイム)
RCEの分類CVE-2026-109618:OOM(メモリ不足)状態でのメモリ破損によるRCE(GHSA-w8hw-w9fx-j79w)CVE-2026-109619:古いグローバル状態を悪用したRCE(GHSA-6wmf-4rv5-p3rp)
CVSSスコアCVSS v4.0:いずれも9.2(Critical)
攻撃条件認証不要。Webリクエストを処理するPHP環境が対象
影響を受けるバージョン8.2.35、8.3.36、8.4.27、8.5.12より前の各リリース
修正バージョンPHP 8.5.12、8.4.27、8.3.36、8.2.35(2026年10月21日リリース)
実際の悪用公開PoCを利用した悪用の試みを観測

技術的な原因:メモリ不足と残存する内部状態

PHPメモリの断片化の流れを示したAI生成画像

PHPセキュリティチームが公開した2つの脆弱性は、いずれもPHPがリクエストを処理する途中で発生する異常な状態を悪用するものです。

CVE-2026-109618:OOMによるメモリ破損からRCEへ

PHPはメモリ不足が発生すると、実行中のコードから処理を抜けることでエラーに対応します。

問題は、リクエスト内部のデータが部分的にしか初期化されていない段階で、処理が中断される可能性があることです。その後のリクエスト終了処理(cleanup)で、不完全なデータが正常なものとして扱われると、メモリ破損が発生します。攻撃者はこれを悪用し、Webワーカーの実行権限で任意のコードを実行できる可能性があります。

公開された説明によると、multipartリクエストの解析は、PHPをOOM状態に陥らせる経路の1つです。

CVE-2026-109619:古いグローバル状態を悪用したRCE

リクエストに関連する内部状態が、その状態を保持していたメモリの解放後も残存する場合があります。

同じワーカーが処理する後続のリクエストで、通常の初期化が行われる前にこの古い状態を使用すると、解放済みメモリを参照するUse-After-Free(UAF)が発生します。その結果、メモリ情報の漏えいや、Webワーカーの実行権限でのコード実行につながる可能性があります。

この脆弱性の特徴は、同じワーカーで処理される2つの異なるリクエストが必要になる点です。1つは内部状態を残すリクエスト、もう1つはその状態を参照するリクエストです。

なぜすべてのエンドポイントが攻撃対象になるのか

2つの欠陥はいずれも、PHPがリクエスト変数を構築する段階で発生します。これは拡張モジュールの初期化やアプリケーションコードの実行よりも前の段階です。

そのため、静的なフォーム、ログイン用パス、ヘルスチェックなど、PHP経由でアクセスできるすべてのエンドポイントが攻撃対象領域となります。アプリケーション自体のセキュリティ対策が適切であるかどうかは、この攻撃の成立とは関係ありません。

mod_phpとPHP-FPMの違い

PHPは、特にリスクが高い環境としてmod_phpを挙げています。認証なしのリクエストによって、アプリケーションコードの実行前に攻撃が成立するエクスプロイトがすでに検証されています。

一方、PHP-FPMはリクエスト開始時に処理に失敗したワーカーを終了するため、状況が異なります。

  • CVE-2026-109618:ソースコードの分析上、PHP-FPMにも脆弱性が存在。ただし、PHP-FPM環境での完全なエクスプロイトは未実証。
  • CVE-2026-109619:mod_phpとPHP-FPMの両方でコード実行を確認。ただし、PHP-FPMでは実行中のアプリケーション内部における特定の動作に依存。

つまり、「PHP-FPMを使用しているから安全」と断定することはできません。まだ実証されていない攻撃経路があるだけで、攻撃が不可能と確認されたわけではありません。

脆弱性が発見・悪用可能となった背景

今回の脆弱性が生まれた背景にも注目する必要があります。中核となるOOMの欠陥は2020年にすでに発見され、2024年のPHP監査でも改めて確認されていました。しかし、当時は悪用可能性が証明されていなかったため、修正されませんでした。

その後、最新のAIモデルの支援によって、この弱点をより詳細に分析できるようになり、最終的にRCEへとつながる攻撃経路が構築されました。

この経緯は、脆弱性対応に重要な示唆を与えています。「悪用が実証されていない」という理由で対応が見送られた欠陥でも、分析ツールの進化によって深刻な脆弱性となる可能性があります。

長期間放置されてきた古いコード経路が、今後さらに多く発見される可能性を示す事例でもあります。

公開直後に観測された悪用の試み

公開PoCが登場した当日から、それを利用した悪用の試みが観測されました。公開された観測事例では、以下のようなパターンが確認されています。

  • PHPのアップロード進捗追跡機能(PHP_SESSION_UPLOAD_PROGRESS)を含むmultipart POSTリクエストを使用し、Webシェルの設置を試みる攻撃
  • Webシェル設置直後に、php://filterを使用したファイル読み取りリクエストが連続して発生する挙動
  • User-AgentにPoCツール名(php2shell-poc)がそのまま残っているリクエスト

Criminal IP IT資産検索で確認したPHP2Shell関連の外部公開資産

PHP2ShellはPHPエンジン自体の問題であるため、実際のリスクの規模は、インターネット上に公開されているPHPサーバーの数と密接に関係しています。Criminal IP IT資産検索を活用することで、こうした攻撃対象領域を以下のように定量的に可視化できます。

PHP資産全体の公開規模:約85万件の潜在的な攻撃対象領域

Criminal IP IT資産検索で「product: PHP」を検索した結果

Criminal IP IT資産検索クエリ – product: PHP

上記のクエリで検索した結果、2026年10月時点で、インターネット上に公開されているPHP Webサーバーは852,895件確認されました。

前述のとおり、今回の脆弱性はWebリクエストを処理するPHP環境に影響し、アプリケーションの種類に関係なく攻撃が成立する可能性があります。そのため、確認された約85万件の資産は、潜在的な攻撃対象領域に相当します。

小規模なWebサイトから基幹業務システムまで、パッチが適用されていないPHPランタイムを使用している場合、いずれも攻撃対象となる可能性があります。

このクエリで検出された資産数は、潜在的な影響範囲の下限を示すものであり、実際の規模はさらに大きいと考えられます。

管理が行き届いていない高リスク資産:約6万件のSSL証明書期限切れサーバー

Criminal IP IT資産検索で「product: PHP AND ssl_expired: true」を検索した結果

Criminal IP IT資産検索クエリ – product: PHP AND ssl_expired: true

このクエリは、先ほど検出された外部公開PHPサーバーのうち、SSL証明書の有効期限が切れているサーバーを識別するためのものです。2026年10月時点で62,111件が検出され、PHP資産全体の約7.3%を占めています。

証明書の更新は、基本的な運用管理作業の1つであり、自動化も比較的容易です。それにもかかわらず証明書が更新されていないサーバーでは、PHPエンジンレベルの緊急パッチ適用も遅れる可能性があります。

今回のように短期間で緊急パッチがリリースされた場合、日常的な証明書更新が行われていない環境では、パッチの適用がさらに遅れることも考えられます。攻撃者にとっては優先的な標的となりやすく、侵害後も長期間発見されないリスクがあります。

そのため、検出された約62,000件の資産は、優先的な点検対象となります。組織内での点検においても、「期限切れ証明書+旧バージョンのPHP」 の組み合わせを優先して確認することを推奨します。

PHPのバージョンや設定が公開されたサーバー:攻撃者にとっての情報源

Criminal IP IT資産検索で「title: “phpinfo()”」を検索した結果

Criminal IP IT資産検索クエリ – title: “phpinfo()”

Criminal IP IT資産検索で、phpinfo()の出力ページが外部公開されているサーバーを調査した結果、合計2,519件が検出されました。こうしたページの公開は、今回の脆弱性において特に重要な意味を持ちます。phpinfo()の出力には、正確なPHPバージョンやビルド情報、読み込まれている拡張モジュール、実行方式(SAPI)、詳細な設定値などが含まれているためです。

攻撃者にとっては、追加の事前調査を行わなくても、脆弱なバージョンや攻撃経路(mod_phpの使用有無など)を識別できる情報源となります。

PHP2Shellは、バージョンやSAPIによってリスクが異なるため、こうした情報の公開は攻撃者が標的を選定する際の時間と労力を大幅に削減します。企業や組織では、自社が管理する資産の中に、適切に管理されていないinfo.phpやphpinfo.phpなどのファイルが存在する場合、速やかに対処し、攻撃リスクを低減する必要があります。

サポート終了(EOL)バージョンのリスク:公式パッチを適用できないサーバー

Criminal IP IT資産検索で「”X-Powered-By: PHP/7.4″」を検索した結果

Criminal IP IT資産検索クエリ – “X-Powered-By: PHP/7.4”

Criminal IP IT資産検索で「”X-Powered-By: PHP/5″」を検索した結果

Criminal IP IT資産検索クエリ – “X-Powered-By: PHP/5”

2026年10月時点のCriminal IP IT資産検索の結果では、多数の資産がHTTPレスポンスヘッダーで旧バージョンのPHPを公開していることが確認されました。

PHP 7.4は477件、PHP 5.xは618件で、合計1,000件以上の資産が公式サポートの終了したバージョンを使用していました。どちらのバージョンも、今回の脆弱性に対してPHPプロジェクトから公式のパッチリリースを受けることはできません。それぞれの状況は以下のとおりです。

  • PHP 7.4(477件): PHPセキュリティチームは、ソースコードからのビルドに利用できる最小限のバックポートブランチを提供しています。ただし、運用者が自らビルドして置き換えなければ、脆弱な状態が続きます。バイナリパッケージに依存する環境ほど、対応が遅れる可能性があります。
  • PHP 5(618件): バックポートも提供されていません。脆弱なコードはPHP 5.4から存在するため、5.4~5.6は今回の脆弱性の直接的な影響範囲に含まれます。5.3以前は今回のコード経路と関係しない可能性がありますが、すでに多数の既知の脆弱性が未修正のままとなっており、セキュリティリスクはさらに高い状況です。

特に注目すべき点は、これらの資産がPHPのバージョン情報をHTTPレスポンスヘッダーにそのまま公開していることです。これは、expose_phpのデフォルト設定が変更されていないことを示しています。攻撃者は追加の調査を行わなくても、検索するだけで「公式パッチが提供されないサーバー」の一覧を取得できる可能性があります。

PHPを利用する主要CMSへの影響:WordPressの外部公開資産

Criminal IP IT資産検索で「product: WordPress AND product_version: “7.1.3”」を検索した結果

Criminal IP IT資産検索クエリ – product: WordPress AND product_version: “7.1.3”

PHP2Shellの実質的な影響範囲を考えるうえで、もう1つ重要なのが、PHP上で動作する主要なアプリケーションへの影響です。その代表例が、世界的に広く利用されているCMSのWordPressです。

WordPress自体が最新バージョンであっても、基盤となるPHPランタイムに脆弱性が存在すれば、そのリスクの影響を受けます。2026年10月時点で、上記の条件を使用してWordPressの外部公開資産を検索した結果、1,457件が検出されました。

これは、「アプリケーション自体に問題がなくても、基盤となるエンジンの脆弱性によってリスクが生じる」 というPHP2Shellの特徴を、実際の資産データから考えるための事例です。CMSやフレームワークを利用するユーザー、組織、企業は、アプリケーションのアップデート状況だけでなく、その基盤となるPHPランタイムのバージョンも必ず確認する必要があります。

攻撃対象領域の分析結果まとめ

Criminal IP IT資産検索クエリ検出件数意味
product: PHP852,895潜在的な攻撃対象領域全体
product: PHP AND ssl_expired: true62,111管理が行き届いていない可能性がある優先点検対象(約7.3%)
title: “phpinfo()”2,519PHPバージョン・設定情報を公開しているサーバー
“X-Powered-By: PHP/7.4”477EOLのPHP 7.4:バックポートに依存
“X-Powered-By: PHP/5”618EOLのPHP 5.x:パッチ適用経路が実質的に存在しない環境
product: WordPress AND product_version: “7.1.3”1,457基盤となるPHPエンジンのリスクを受ける代表的なCMS

対応策

今回のPHP2Shellに対して、根本的かつ確実な対策は修正バージョンへのアップデートです。これに代わる一般的な設定変更による緩和策はありません。以下の暫定措置によって攻撃対象領域を一時的に縮小することはできますが、必ずパッチ適用とアップデートを実施し、根本的な対応を完了する必要があります。

パッチ適用までの暫定的な緩和策

以下の設定は、特定の攻撃経路への露出を減らすものであり、脆弱性自体を修正するものではありません。そのため、パッチ適用までの暫定措置としてのみ利用してください。

  • CVE-2026-109618: memory_limit=-1に設定し、アプリケーションによる任意の変更を制限します。また、post_max_sizeを低く保ち、Webサーバーやプロキシ側でリクエストサイズを制限。
  • CVE-2026-109619: session.upload_progress.enabled = off に設定し、すべてのワーカーを再起動します。PHP 8.5では、追加でfatal_error_backtraces = 0 に設定。

パッチの適用

  1. 外部公開資産の一覧を把握: Criminal IP IT資産検索の結果を社内の資産一覧と照合し、インターネット上に公開されているPHPサーバーから優先順位を設定します。
  2. 使用中のブランチに対応する修正バージョンへアップデート: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35へ更新します。Linuxディストリビューションのパッケージを使用している場合は、該当ディストリビューションのセキュリティアップデートを確認してください。修正状況はバージョン文字列だけで判断せず、変更履歴(Changelog)に対象CVEの修正が反映されているか確認する必要があります。
  3. アップデート後にすべてのワーカーを再起動: PHP-FPMやApacheなど、関連するすべてのワーカーを再起動し、新しいPHPインタープリターを読み込ませます。再起動しなければ、更新前の脆弱なプロセスが引き続きリクエストを処理する可能性があります。
  4. コンテナ環境もあわせて更新: 実行中のコンテナだけでなく、ベースイメージやCI/CDパイプラインも更新する必要があります。
  5. サポート終了(EOL)バージョンへの対応: PHP 8.1以前のEOLバージョンは、サポート対象バージョンへのアップグレードを原則とします。すぐに移行できない場合は、LTSサポート提供元のバックポートパッケージを利用するか、PHPセキュリティチームが提供する7.4・8.0・8.1向けの最小限のバックポートブランチを使用し、独自にビルドする必要があります。

パッチ適用後の確認事項

  • Webサーバー・PHPログの確認: パッチ公開前後、特に10月20日以降のログを遡って確認。異常に大きなmultipart POSTリクエスト直後のメモリ制限エラー、繰り返し発生するHTTP 500エラー、原因不明のPHPワーカー再起動などの有無を確認。
  • ファイルの完全性と侵害の痕跡を確認: Webルート配下のファイルの完全性を確認。あわせて、Webサーバーの実行アカウントに関連するcron設定、SSH鍵、起動スクリプトなどに、攻撃者がアクセスを維持するための仕組みが設置されていないか点検。
  • PHPの設定情報の公開を制限: 外部からアクセス可能なphpinfo()ページ(info.php、phpinfo.phpなど)を削除し、expose_php = Offに設定。HTTPレスポンスヘッダーからのPHPバージョン情報の公開を制限。

FAQ

Q1. PHP-FPMを使用していれば安全ですか?

安全とは断定できません。特にリスクが高いのはApache mod_php環境ですが、CVE-2026-109619については、mod_phpとPHP-FPMの両方でコード実行に到達したことが確認されています。

PHP-FPMでは、まだ完全に実証されていない攻撃経路があるだけで、悪用が不可能と確認されたわけではありません。

Q2. WordPressなどのアプリケーションが最新バージョンでも影響を受けますか?

影響を受ける可能性があります。今回の脆弱性は、アプリケーションではなくPHPエンジン自体に存在します。アプリケーションのセキュリティ対策が適切であっても、基盤となるPHPランタイムが脆弱なバージョンであれば、攻撃対象となる可能性があります。

結論

PHP2Shell(CVE-2026-109618・CVE-2026-109619)は、「自社のアプリケーションコードは安全だから問題ない」という考え方が通用しない、ソフトウェア基盤のPHPエンジンに存在する脆弱性です。10年以上前から潜在していた欠陥が、分析ツールの進化によって実際のエクスプロイトへと発展したことは、「悪用が実証されていない」という理由で対応が見送られてきた古いコード経路も、深刻なセキュリティリスクとなり得ることを示しています。

すでに悪用の試みが観測されており、侵害が確定した事例が明らかになる前の今こそ、早急な対応が求められます。PHPランタイムを8.5.12 / 8.4.27 / 8.3.36 / 8.2.35へアップデートし、ApacheやPHP-FPMを含むすべてのワーカーを再起動する必要があります。

また、アプリケーションのバージョンだけでなく、その基盤となるPHPランタイムを確認し、修正状況についてはバージョン文字列ではなく、変更履歴(Changelog)に対象CVEの修正が反映されているかを基準に判断することが重要です。何よりも、セキュリティ対策は、自社がどのような資産をインターネット上に公開しているのかを把握することから始まります。

Criminal IP IT資産検索を活用し、外部公開されたPHP資産、サポート終了バージョン、設定情報が公開されているエンドポイントを事前に可視化することで、攻撃者に先んじた対応が可能になります。さらに、こうした検索クエリを継続的な攻撃対象領域管理(ASM)の運用に組み込むことで、今回のようなエンジンレベルの脅威に対しても、安定した対応体制を構築できます。

なお、関連して、サイバー攻撃の可能性に伴うKiteworksの予防的システム停止勧告: 関連外部公開インフラ分析 の記事も参考にできます。

Criminal IP(criminalip.io/ja/register)に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス(TI)分析を直接ご確認いただけます。


本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。
今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。

データソース: Criminal IP(https://www.criminalip.io/ja)、Help Net Security(https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/)、The Hacker News(https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html)

関連記事: https://www.criminalip.io/ja/knowledge-hub/blog/10392

コメントを残す

Criminal IP(クリミナルアイピー)をもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む