PHP2ShellとSecurityScorecard：プラットフォームへの露出なし、お客様への影響なし
SecurityScorecardのプラットフォームはPHP2Shell脆弱性にさらされておらず、プラットフォーム本体および、その中のお客様データへの影響もありません。SecurityScorecardが所有するCVEdetails.comは、影響を受けるバージョンのPHPを実行していましたが、2026年10月21日の修正版リリースと同時に、直ちにパッチを適用しました。露出期間中のログを確認した結果、悪用や不正なデータアクセスの証拠は見つかりませんでした。SecurityScorecardのサービスへの影響はなく、ダウンタイムも発生していません。
SecurityScorecardのサービスに関して、お客様側で必要な対応はありません。このアドバイザリの以降の部分では、お客様ご自身の環境と、サードパーティについて推奨する対応を説明します。
PHP2Shellとは
PHP2Shellは、PHPランタイム自体に存在する、2件の重大なメモリ安全性の欠陥（CVE-2026-109618とCVE-2026-109619）です。いずれもCVSS v4.0で9.2と評価されています。影響を受けるバージョンのPHPを使用しているサイトは、アプリケーションコードが安全であっても、脆弱な状態にあります。PHPは、WordPress、Drupal、Joomla、Moodle、Nextcloud、MediaWikiを含め、Webサイトのおよそ70%を支えています。
- 攻撃者にできること： PHPのWebワーカーとして、認証なしでコードを実行できます。また、他のリクエストに属するプロセスメモリ（パスワード、セッショントークン、APIキー、証明書など）を読み取れます。メモリ開示の経路は、コード実行の痕跡を残さないため、検知がより困難です。
- 影響を受けるバージョン： PHP 5.4から、2026年10月21日の修正版より前のすべてのリリースまでです。
- 修正済みバージョン： 8.5.12、8.4.27、8.3.36、8.2.35です。PHP 8.1以前はサポート終了（EOL）です。PHPセキュリティチームは、7.4、8.0、8.1向けに最小限のソースバックポートを公開しました。7.3以前と5.xには、PHPプロジェクトからの修正はありません。Linuxディストリビューションや延長サポートのベンダーは、独自のバージョン番号でバックポートしたパッケージを提供しています。
- 悪用の状況： 技術的な詳細は、協調的な情報開示に先立つ10月20日に漏えいし、PHPは修正を1日前倒しで公開しました。Cloudflare、watchTowr、Amazonは、自社のネットワークやハニーポットに対する悪用の試みを報告しています。CISAの10月21日付のアラートは、公開時点で悪用は確認していないとしており、本稿執筆時点では、どちらのCVEも「既知の悪用された脆弱性（KEV）」リストに載っていません。公開されている概念実証コードは、現時点ではデフォルトのインストール環境に対してコード実行を達成できていませんが、数日以内に状況が変わると予想してください。
今すぐ行うべきこと
PHPランタイムにパッチを適用し、すべてのワーカーを再起動することが、唯一の完全な修正です。以下の手順を順番に進めてください。ほとんどの組織で、想定より多くのPHPが見つかります。
- すべてのPHPランタイムを棚卸しする。
関係者への聞き取りではなく、スキャンとクラウドテレメトリから作成します。当社の対応では、マネージドホスティング、複数のクラウドアカウントにまたがるセルフマネージドVM、サポート終了バージョンのコンテナ、どのチームも所有していない放置されたデモ用サーバーでPHPが見つかりました。IT部門以外のチームが所有するサイトも含め、それぞれを、マネージド（ベンダーがパッチ適用）かセルフマネージド（自社でパッチ適用）かでタグ付けしてください。 - 修正済みリリースにパッチを適用し、再起動する。
8.5.12、8.4.27、8.3.36、8.2.35のいずれか、またはディストリビューションのバックポートパッケージをインストールし、Apache、PHP-FPM、長時間稼働するPHPワーカーを再起動します。WordPressなどのアプリケーションを更新しても、その下のランタイムには何の効果もありません。確認は、インストールしたパッケージではなく、稼働中のバージョンで行ってください。 - アップストリームのバージョン番号ではなく、ディストリビューションのアドバイザリを追う。
ほとんどのマネージドLinuxディストリビューションでは、修正は旧バージョンの文字列を保ったまま、バックポートされたリビジョンとして提供されます。バックポートを提供するリポジトリで「8.2.35」を探しても、1日を無駄にするだけです。 - サポート終了のPHPをどうするか決める。
7.4、8.0、8.1は、ベンダーのバックポートまたはPHPの最小限のソースパッチを適用します。7.3以前は、延長サポートのチャネルがあればそれを利用し、なければシステムを隔離するかオフラインにします。CISAのガイダンスでは、すぐに更新できないシステムや、8.1以前を実行しているシステムは、パッチ適用までオフラインにするべきとされています。 - 数日以内にパッチを適用できない場合は、下記の暫定対策を講じる。
どれも更新の代わりにはならず、それぞれ一部の攻撃経路を塞ぐだけです。 - WAFルールが実際にリクエストの経路上にあることを確認する。
エッジプロバイダーは数時間以内にルールを提供しましたが、オリジンが直接応答するなら、ルールは何も守りません。当社のリスクが最も高いホストのいくつかは、クラウド上のオリジンIPへ直接名前解決されていました。オリジンへの直接通信を遮断しなければ、そのルールは見せかけに過ぎません。 - 少なくとも10月17日までさかのぼって調査する。
Amazonのハニーポットのデータでは、パッチ公開前から悪用の試みが始まっていました。次の兆候を探してください。- メモリ上限エラー、繰り返し発生する500エラー、原因不明のPHPワーカーの再起動やセグメンテーション違反
- PHP_SESSION_UPLOAD_PROGRESSフィールドを含むマルチパートPOST（特に、アップロードを受け付けないエンドポイントへのもの）
- 「php2shell」というユーザーエージェント
- レスポンス内の異常に大きなPHPSESSID値
- php-fpm、php-cgi、Apacheから起動されたシェルやダウンローダー
- 露出したホストの秘密情報をローテーションする。
2つの脆弱性のうち1つはプロセスメモリをリークするため、パッチを適用しても、すでに読み取られたものは元に戻りません。ほとんどのWebサーバーはリクエストボディを記録しないため、証拠がないことは、安全の根拠として弱いものです。パッチ未適用のまま露出していたインターネット向けホストでは、ワーカーのメモリ上にあったセッションキー、データベース認証情報、APIトークン、証明書をローテーションしてください。 - パッチ適用後は、制限を元に戻してテストする。
修正版には、ハードなメモリ不足（OOM）の制限が追加されています。この制限に達したワーカーは、終了コード137で終了します。一時的に設定したmemory_limit = -1は、実際の値に置き換えてください。post_max_sizeはメモリ予算より小さく保ち、何も使っていなければsession.upload_progressは無効のままにして、48時間はエラー率を監視してください。
すぐにパッチを適用できない場合の暫定対策
| 対策 | 対処する内容 | 注意点 |
| memory_limit = -1を管理者レベル（php_admin_valueまたはサーバー設定）で設定し、cgroup v2のmemory.maxによる上限と併用する | ほとんどの攻撃経路が依存する、PHP自身のメモリ不足による中断を取り除く | RLIMIT_ASやRLIMIT_DATAで代用してはならない。PHPは、これらが同じ脆弱な経路を引き起こすと警告している。cgroupの上限がないと、1つのリクエストでホストが枯渇し得る |
| php.ini、FPMプール、またはサーバー設定でsession.upload_progress.enabled = 0とし、すべてのワーカーを再起動する | CVE-2026-109619で確認済みのセッション経路を塞ぐ | リクエスト解析の前に適用される必要がある。ini_set()や.user.iniでは機能しない。他の亜種はカバーしない |
| fatal_error_backtraces = 0（PHP 8.5のみ）とし、再起動する | CVE-2026-109619の致命的エラーのバックトレース経路を塞ぐ | 致命的エラーのバックトレースが失われる |
| post_max_sizeを下げ（アップロードなしなら8M、ありなら32M）、Webサーバーやプロキシでも同様にボディサイズを制限する | マルチパート解析中に、攻撃者が制御できるメモリへの負荷を減らす | 正当なアップロードにも上限がかかる。アップロードのフローをテストすること |
| PHP_SESSION_UPLOAD_PROGRESSフィールドをブロックするWAFルール | 最も一般的な探索パターンを捕捉する | ほぼすべてのサイトで安全。代わりにすべてのマルチパートPOSTをブロックすると、アップロード、AJAXフォーム、一般的なフォームプラグインが壊れる。攻撃者はすでにペイロードを変化させている |
どのシステムから修正するか
まず、デフォルトのセッション設定でApache mod_phpを実行している、インターネット向けホストから着手してください。アプリケーションのバグがなくても、認証なしのコード実行が検証されたのは、この構成です。セッション経路はPHP-FPMに対しても機能し、session.upload_progressはデフォルトで有効なため、FPMのホストが次の対象です。対象外ではありません。
検出件数で順位を付けないでください。当社のトリアージでは、数百件の検出があった最もノイズの多いホストは、最も危険なホストではありませんでした。重要だったのは、稼働中でインターネットに公開され、全ポート範囲が開いており、検出件数ははるかに少ないホストでした。維持しなければならないサービスを優先しながら、各システムを以下の要素でスコア付けしてください。
| 要素 | 問うべきこと | 優先度を上げる場合 |
| エクスポージャー | システムはインターネットから到達可能か。オリジンに直接到達できるか | どちらかが「はい」 |
| 構成 | mod_phpかPHP-FPMか。session.upload_progressは有効か | mod_php、またはupload_progressが有効 |
| 悪用可能性 | マルチパートPOSTを受け付けるか。ログにすでに探索の痕跡があるか | どちらかが「はい」 |
| 緩和の速さ | 数日以内にパッチまたは暫定対策を適用できるか | 適用できない |
| データの機密性 | 攻撃者は、プロセスメモリ上やディスク上で何に到達できるか | 認証情報、トークン、個人情報や規制対象のデータ |
| 横展開 | 攻撃者はこのホストから他のホストへ移動できるか | 共有された認証情報、フラットなネットワーク、管理エージェント |
| 公共への影響 | 停止または侵害は、より大きな被害をもたらすか | サービスごとにあらかじめ決めておく |
サービスをオフラインにすればデータは守れますが、サービスは中断されます。オンラインのままにすればサービスは継続しますが、侵害のリスクがあります。悪用の状況によって選択を迫られる前に、どちらの結果なら許容できるかを、サービスごとに決めておいてください。
サードパーティと共有依存関係
エクスポージャーは、お客様に代わってPHPを運用するすべてのプロバイダーに及びます。また、多くのベンダーが、ごく少数の同じプロバイダーを共有しています。マネージドなWordPressやDrupalのプラットフォーム、cPanelやPleskの共有ホスティング、MSP、PHPを組み込んだ製品（Moodle、Nextcloud、MediaWiki、多くのアプライアンスなど）は、集中しやすいポイントです。数十件の別々のエクスポージャーに見えるものが、実際には少数の共有の単一障害点に行き着くことがよくあります。
今すぐ依存関係をマッピングしてください。優先度の高いサービスの背後にどのプロバイダーがいるのか、そしてそのうちどれが同業他社にもサービスを提供しているのかを特定します。そのうえで、それぞれにチケットを起票し、次の点を尋ねてください。
- 当社のサービスを支える、または当社のデータを扱うシステムで、PHPを実行していますか？ Webサイトだけでなく、組み込み製品やアプライアンスも含みます。
- どのバージョンのPHPと、どのSAPI（mod_phpかPHP-FPM）を実行していますか？ session.upload_progressは有効ですか？
- パッチを適用しましたか？ ワーカーは再起動しましたか？ 現在稼働しているバージョンは何ですか？
- サポート終了のブランチについては、どのバックポートのチャネルが対象ですか？
- パッチ適用までの間、それらのシステムを守るために、どのような代替的な対策を講じていますか？ オリジンにWAFを迂回して直接到達できますか？
- 10月17日までさかのぼってログを確認しましたか？ 露出していたホストの秘密情報はローテーションしましたか？
- 当社のサービスのうち、他の顧客とインフラを共有しているものはどれですか？
2つの注意点があります。第一に、多くの大規模プラットフォームは協調的な情報開示に参加し、早期にパッチを適用しました。しかし、「事前に情報を得ていた」は、確認すべき前提であって、答えではありません。当社のマネージドサイトのプロバイダーは自社でパッチ適用を行いましたが、当社はそれでもチケットを起票し、確認しました。第二に、外部から得たバージョンの証拠は、当社のものも含めて、証拠ではなく手がかりとして扱ってください。ディストリビューションのバックポートは古いバージョン文字列を保つため（誤検知）、expose_php = 0やCDNの前段配置はバージョンを完全に隠します（見逃し）。トリアージには使えますが、確定は証明（アテステーション）で行ってください。
SecurityScorecardがお手伝いできること
SecurityScorecardのSTRIKE脅威インテリジェンスチームは、公開時点で760万件以上のインターネット向け資産がPHPを実行していることを観測しています。当社のスキャンは、お客様自身のフットプリントと、ベンダーポートフォリオ全体にわたって、露出したPHPインフラを特定します。これにより、どのサードパーティが影響を受けるバージョンを公開しているか、ベンダー同士が共通して使っているプロバイダーはどれかを把握できます。Driftnetアドオンを利用しているTITAN Secureのお客様は、PHP2Shell対応ワークフローを構築できます。詳細は、こちらのウォークスルー動画をご覧ください。
本アドバイザリやSecurityScorecard自身の対応に関するご質問は、担当のアカウントチーム、またはsecurity@securityscorecard.comまでご連絡ください。悪用の状況の変化に応じて、本アドバイザリを更新します。
