PHP2Shell

［画像: Wiz Research logo］

［画像: OpenAI logo］

［画像: Calif logo］

AIがウェブの基盤における重大な脆弱性を発見

PHP2Shellは、コアPHPで最近修正された一連の重大な脆弱性であり、CVSS 9.2の深刻度を持ち、認証されていない攻撃者がコードを実行したり、機密性の高いプロセスメモリを公開したりすることを可能にします。PHPは、WordPress、Drupal、WikipediaのMediaWikiなどのプラットフォームを含む、約70%のウェブサイトで利用されています。

調査と責任ある開示: Wiz Research — Sagi Tzadik, Shir Tamari, Nir Ohfeld および Tomer Schwartz; OpenAI Codex Security — Amy Burnett; Calif — Ryan A.

［画像］

PHP2Shellとは？

PHP2Shellは、コアPHPにおけるメモリ安全性に関する一連の脆弱性です。これは2つの関連する脆弱性クラスからなり、2つのCVEとして追跡されています。一つはメモリ不足時の処理による破損、もう一つはリクエスト間で維持される古いグローバル状態です。

脆弱なコードはPHP自体に存在します。アプリケーションコードが安全であっても、影響を受けるPHPバージョンで動作する単純な「Hello World」アプリケーションでさえ、サイトは影響を受ける可能性があります。

最新の修正済みPHPリリースを実行しているサイトは保護されています。PHPチームは、研究者と緊密に連携して包括的な修正を提供し、これらの報告に例外的な速度とプロフェッショナリズムで対応しました。

WordPress、Drupal、Joomlaは、認証されていないリモートコード実行を実証するために使用された代表的なターゲットでした。悪用にはこれらのアプリケーションのいずれかが必要なわけではありません。

約70%のウェブサイトがPHPを使用

PHPは、約70%のウェブサイトで利用されています。

PHPは、WordPress、Drupal、MediaWiki（Wikipediaを支えるソフトウェア）のプログラミング言語です。そのコアエンジンにおける脆弱性は、このエコシステム全体のウェブサイトに影響を与える可能性があります。

攻撃者ができること

• 認証なしで影響を受けるサーバー上でコードを実行し、サーバーを制御したり、機密データにアクセスしたり、横断的に移動したり、ウェブサイトを改ざんしたりする可能性があります。
• 他のリクエストやサーバー自体のパスワード、認証トークン、APIキー、証明書を含む、機密性の高いPHPプロセスメモリを読み取ることができます。
• リモートコード実行を達成する前に、メモリ開示を通じて機密データを盗むことができます。これにより、悪意のあるコード実行に焦点を当てたツールでの検出が困難になる可能性があります。

私たちは、テスト時に最新のコンテナイメージを使用したWordPress、Drupal、Joomlaに対してリモートコード実行を実証しました。また、アプリケーションに依存しないメモリ開示も実証しました。

PHP2Shellの動作

PHP2Shellが各アプリケーションを自動的に識別し、制御されたテスト環境で認証前のコマンド実行を実証する様子をご覧ください。

• ［動画: WordPressデモンストレーションビデオをダウンロード。］

  ［画像］WordPress認証前RCEデモンストレーション

• ［動画: Drupalデモンストレーションビデオをダウンロード。］

  ［画像］Drupal認証前RCEデモンストレーション

• ［動画: Joomlaデモンストレーションビデオをダウンロード。］

  ［画像］Joomla認証前RCEデモンストレーション

脆弱性

この調査では、コアPHPにおけるメモリ不足時の破損と、リクエスト間で維持される古いグローバル状態という2つの関連する脆弱性クラスが特定されました。これらはCVE-2026-109618およびCVE-2026-109619として追跡されており、深刻度はCVSS 9.2です。

これらの脆弱性クラスには、異なる悪用要件と影響を持つ複数の攻撃パスが含まれています。PHP-FPM RCEは、アプリケーションレベルのコードパスを通じて確認されました。PHPチームの修正は、実証されたパスだけでなく、根本的な失敗パターンに対処しています。

PHPのアップグレード

すべてのランタイムに修正済みのPHPリリースをインストールし、Apache、PHP-FPM、および長時間実行されているPHPワーカーを再起動してください。これが唯一の完全な修正です。アプリケーションを更新しても、その下のPHPランタイムは更新されません。

公式PHPリリースはphp.netから入手できます。下流ディストリビューションは、通常のアップデートチャネルを通じて対応するパッケージアップデートを提供します。

ブランチごとの脆弱なPHPリリースと最初の修正リリース

すぐにアップグレードできない場合

PHPのアップグレードが唯一の完全な修復策です。 以下の対策は、アップグレードの準備が整うまで特定の悪用パスへの露出を減らす可能性がありますが、すべてのバリアントに対処するわけではありません。

一部の対策は、アプリケーションの機能、パフォーマンス、または可用性に影響を与える可能性があります。設定変更をアプリケーションの要件に対してテストし、できるだけ早くPHPセキュリティアップデートを適用してください。

PHPのメモリ制限を無効にすることを検討する

memory_limit = -1 を設定すると、PHPのメモリ制限処理に依存する一部の攻撃パスを防ぐことができますが、メモリ枯渇処理はオペレーティングシステムに委譲されます。この設定では、メモリが枯渇したワーカーは終了する可能性があり、リクエストが中断され、サーバーの安定性と可用性に影響を与えます。これを有効にする場合は、Linux cgroup v2 memory.max、または同等のオペレーティングシステムメカニズムを使用して、リソース消費を抑制し、PHPプロセスへの可用性への影響を制限してください。設定変更を管理的に適用し、影響を受けるワーカーを再起動してください。

代替のメモリ制限として RLIMIT_AS または RLIMIT_DATA を使用しないでください。 PHPのアドバイザリは、これらが同じ脆弱な失敗パスをトリガーする可能性があると警告しています。

この対策は、アプリケーション固有の大きな割り当てパスや、メモリ以外のトリガーをカバーしません。スレッド化されたデプロイメントでは、プロセスの終了は他のスレッドで実行中のリクエストを中断する可能性もあります。

攻撃者が制御するメモリ圧力を軽減する

• アプリケーションのアップロード要件と互換性のある値に post_max_size を下げてください。これはファイルアップロードも制限するため、正当なアップロードフローをテストしてください。
• アプリケーションが許可する場合、max_input_nesting_level を下げてください。複雑なフォームには、より高い制限が必要になる場合があります。
• アプリケーションがアップロード進捗追跡に依存していない場合は、session.upload_progress.enabled = 0 を設定してください。

これらの設定は、特定のメモリ圧力源を制限します。メモリ枯渇への他の攻撃者が制御できるパスは残ります。

PHPのエラー表示を無効にする

本番環境では display_errors = 0 を設定し、影響を受けるワーカーを再起動して、PHPエラー出力がリモートユーザーに公開されるのを防いでください。これにより、追加の情報開示パスが軽減されますが、根本的な脆弱性は修正されません。

致命的なエラーのバックトレースを適用可能な場所で無効にする

サポートされている場所で fatal_error_backtraces = 0 を設定し、影響を受けるワーカーを再起動してください。これは実証された致命的なバックトレースメカニズムに対処しますが、他のメカニズムでも脆弱性ファミリーをトリガーする可能性があります。

ワーカーの再利用を減らす

PHP-FPMの pm.max_requests を下げて、ワーカーをより頻繁にリサイクルしてください。これにより、リクエスト間で破損した状態の永続性を減らすことができますが、パフォーマンスコストがかかり、複数のリクエストに依存しないメカニズムに対処するものではありません。

悪用の影響を制限する

アプリケーションと互換性がある場合は、SELinuxまたはAppArmorポリシーを使用して、ワーカーの機能と他のプログラムの実行を制限してください。これらの制御は影響を制限できますが、すべての悪用やメモリ開示を防ぐものとして扱われるべきではありません。

アップグレード後の強化

PHPのアドバイザリは、修正における新しいハードメモリ制限について説明しています。その制限に達するとプロセスが終了し、シャットダウンハンドラが実行されなくなります。アップグレードの一部として、アプリケーションへの運用上の影響をレビューしてください。

パッチ適用後：

• memory_limit をリクエストサイズ制限および期待されるアプリケーションメモリ使用量と合わせてレビューしてください。アップグレード前に使用した一時的な memory_limit = -1 設定を再検討し、最終的なPHPの推奨事項に従ってください。
• 正当なアップロードをサポートしながら、post_max_size を設定されたメモリ予算より適切に低く保ってください。
• アプリケーションが必要とする深さに max_input_nesting_level を制限し、複雑なフォームをテストしてください。
• PHPバージョンの開示を減らすために expose_php = 0 を検討してください。これはオプションの強化であり、PHP2Shellを修正するものではありません。

これらの手順は、セキュリティアップデート後のアプリケーションの回復力をサポートします。パッチ適用に代わるものではありません。

質問と回答

私は影響を受けますか？

この調査では、PHP 5.4まで遡る影響を受けるリリースが特定されており、修正前にはほぼすべてのPHPバージョンが少なくとも1つの問題の影響を受けていました。露出は、バージョン、設定、および個々の脆弱性に依存します。公式の対象バージョンガイダンスに対して、カスタムアプリケーションを提供するランタイムを含む、すべてのPHPランタイムを確認してください。修復についてはPHPのアップグレードを参照してください。

これはWordPress、Drupal、またはJoomlaに限定されますか？

攻撃者はアカウントを必要としますか？

どのような情報が漏洩する可能性がありますか？

修正は何ですか？

WAF、CDN、またはホスティングプロバイダーのルールで保護できますか？

悪用されたかどうかを判断できますか？

なぜPHP2Shellと呼ばれるのですか？

研究にAIはどのように使用されましたか？

［画像］

Wizがお手伝いできること

Wizのお客様は、Wiz Threat Intel CenterのPHP2Shellに関するアドバイザリを参照して、エージェントレスおよびランタイムでの脆弱性検出、Wiz DefendおよびSensorによるエクスプロイト検出、自動応答ポリシー、修復ガイダンス、脅威ハンティングガイダンスをご利用いただけます。

調整と謝辞

Wiz Research、OpenAI Codex Security、Califの研究者は、発見、調整、パッチ検証においてPHPセキュリティチームおよびGoogleのGeminiチームと協力しました。Google Cloud、Cloudflare、AWS、Microsoft、Automattic、Fastly、Akamai、Imperva、Vercel、その他の業界パートナーは、すぐにアップデートできない組織のために、顧客ガイダンス、検出、および一時的な緩和策の準備を支援しました。

調査および業界協力者:

• ［画像］Wiz

• ［画像］PHP

• ［画像］GoogleのGeminiチーム

• ［画像］OpenAI

• ［画像］Calif

• ［画像］Google Cloud

• ［画像］AWS

• ［画像］Microsoft

• ［画像］Automattic

• ［画像］Fastly

• ［画像］Akamai

• ［画像］Imperva

• ［画像］Cloudflare

• ［画像］Vercel

• ［画像］Corelight

• ［画像］CrowdStrike

• ［画像］Unit 42

• ［画像］Cisco Talos

PHP2Shellに先んじる

影響を受けるPHP環境の特定や、次のステップの計画に支援が必要ですか？露出と修復に関するガイダンスについては、Wizにご相談ください。

---