PHP2Shell（CVE-2026-109618 および CVE-2026-109619）：PHP コアにおける認証不要のリモートコード実行の検知

本文の内容は、2026年10月22日にSysdig Threat Research Teamが投稿したブログ (URL) を元に日本語に翻訳・再構成した内容となっております。

2026年10月21日、PHP2Shell と呼ばれる CVE-2026-109618 と CVE-2026-109619 が、PHP プロジェクトによる2回の緊急リリースで修正されました。この2つの CVE は、関連する4つのメモリ安全性のバグをまとめたもので、どちらの脆弱性も CVSS v4.0 スコアは 9.2 です。認証されていない攻撃者は、HTTP リクエストだけで PHP サーバー上でコードを実行できます。動作する複数の概念実証（PoC）エクスプロイトがすでに出回っており、これらの脆弱性を報告したリサーチャーは、発見とエクスプロイト開発の両方で AI モデルが役立ったと述べています。 

リサーチャーは2026年8月にこれらのバグを PHP に報告し、PHP は9月に連携した修正作業を開始し、協調的な開示は10月22日に予定されていました。ところが10月20日、CVE の識別子とエクスプロイトの詳細が Hacker News やソーシャルメディアに流出しました。PHP は同日中に事前通知を公開し、リリースを1日前倒しして、10月21日 14:00 UTC としました。 

悪用はパッチの公開を待ってくれませんでした。Amazon Threat Intelligence は、開示の4日前にあたる10月17日に、同社の MadPot ハニーポットに対する PHP2Shell の試行を確認しています。Cloudflare は早期の攻撃を報告しており、それは10月21日 07:43 UTC、つまり修正が出荷される6時間以上前のことでした。watchTowr はこれらのバグを再現し、それぞれに対する悪用の試行が活発に行われていると報告しています。

脆弱なコードは、2012年にリリースされた PHP 5.4 までさかのぼります。バグは PHP エンジンの中にあり、個々のアプリケーションの中にはありません。そのため、アプリケーションコードに問題のない WordPress、Drupal、Joomla のサイトであっても、依然として影響を受けます。

セキュリティチーム向けの追加の推奨事項を提供し、Sysdig Secure とオープンソースの Falco のユーザー向けにランタイム検知のカバレッジを作成するため、Sysdig Threat Research Team（TRT）は PHP2Shell の悪用を分析しました。調査結果を以下にまとめます。

影響を受ける PHP バージョン

バージョン番号に加えて、PHP2Shell にさらされる可能性を判断する際に考慮すべき要素が3つあります。 

• ディストリビューションのパッケージ：Linux ディストリビューションと LTS ベンダーは、リリースの前にパッチを受け取っています。ベンダーはアップストリームのバージョン番号を変えずに修正をバックポートすることが多いため、php -v だけでなく、ベンダーのアドバイザリも確認してください。古いバージョンを報告するパッケージは、いずれもパッチを適用する必要があります。
• 影響を受ける SAPI：Web リクエストを処理するすべての PHP インストールが対象です。Apache の mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed が含まれます。PHP は mod_php を最もリスクが高いと評価しています。SAPI とは PHP が Web サーバーと接続する方法のことで、PHP が何らかの形で HTTP リクエストに応答しているなら、対象範囲に含まれます。 
• デフォルト設定：脆弱です。さらされるために必要な特定の設定はありません。

根本原因

PHP のワーカーは、リクエストをまたいで同じメモリを再利用します。リクエストが memory_limit を超えると、PHP は致命的なメモリ不足エラーに陥り、リクエストヒープを破棄します。ワーカー自体は生き残り、次のリクエストの処理を続けます。 

欠陥は、致命的なメモリ不足エラーの後に、PHP がリクエストヒープを指すグローバルポインターをクリアしないことにあります。そのため、同じワーカー上の後続のリクエストが、解放済みメモリを指す古いポインターを使ってしまいます。4つのバグはすべて、この根本原因を共有しています。 

CVE-2026-109618：セッションのアップロード進捗

• アンシリアライザーにおける use-after-free。セッションのアップロード進捗機能は、PHP が multipart/form-data のアップロードを解析している間に、セッションデータをデコードします。その際の管理情報は、アンシリアライザーのグローバル状態に保持されます。メモリ不足エラーによってリクエストヒープは破棄されますが、このグローバル状態は公開されたまま残ります。
• リモートからのメモリ漏えい。アップロード進捗機能は、セッション ID もグローバルポインターに保存します。メモリ不足エラーによって、このポインターが宙ぶらりんの状態になることがあります。同じワーカー上の後続の multipart リクエストは、セッションの初期化がポインターをリセットする前に、アップロード進捗のクリーンアップ処理に到達します。すると PHP は、再利用されたヒープの内容を URL エンコードして PHPSESSID レスポンス Cookie に格納し、クライアントに送信してしまいます。

セッションのアップロード進捗はデフォルトで有効です。この処理は、アプリケーションコードが動くより前のリクエスト解析中に実行され、アプリケーションが session_start() を一度も呼び出さない場合でも動作します。認証やアプリケーションのフィルターでは防げません。

CVE-2026-109619：致命的エラーのバックトレースと OPcache

• 致命的エラーのバックトレースにおける use-after-free。PHP は、直近の致命的エラーのバックトレースをグローバル変数に保持しています。メモリ不足エラーはリクエストヒープを破棄しますが、このグローバル変数はクリアしません。ワーカー上の次のリクエストは、前のリクエストのメモリを指すポインターを見つけてしまいます。
• OPcache における型の混同（type confusion）。OPcache がコンパイル済みスクリプトを共有メモリに永続化している間に、タイミング悪くメモリ割り当てが失敗すると、ワーカー間で内部スロットの整合性が失われます。その結果、あるワーカーが誤った型でデータを解釈してしまいます。

影響

PHP2Shell は、PHP エンジン自体に存在する、認証不要のリモートコード実行の欠陥が2つ組になったものです。これらはアプリケーションより下の層に存在し、アプリケーションコードが動くより前にトリガーされるため、影響を受けるバージョンのインターネットに公開されたあらゆる PHP サーバーがさらされます。その影響は、他のユーザーの機密情報が気づかれないまま盗まれることから、ワークロード上での完全なコード実行、さらにホストへと続く経路にまで及びます。 

• 認証情報なしでの、認証不要のリモートコード実行。脆弱な PHP サーバーに HTTP リクエストを送れるクライアントであれば、誰でも Web サーバーのユーザーとしてコードを実行できます。ログイン、アプリケーションのバグ、ユーザーの操作は不要です。
• 有名なアプリケーションや一般的なアプリケーションだけでなく、すべての PHP アプリケーションがさらされる。バグはエンジンの中にあるため、影響を受けるバージョンの PHP 上では、最小限のアプリケーションでさえ脆弱になり得ます。
• 他のユーザーのリクエストから機密情報が漏えいする。メモリ漏えいは、RCE がなくても単独で成立します。解放済みのプロセスメモリが、認証されていないクライアントに返されます。そのメモリには、同じワーカーが処理した他のリクエストのデータが含まれている可能性があり、認証情報、セッショントークン、API キー、さらには TLS 秘密鍵まで含まれ得ます。 
• コンテナの侵害と、ホストへの経路。PHP コンテナは、インターネットに公開される一般的なワークロードです。そこでコードが実行されると、攻撃者はコンテナのサービスアカウント、マウントされたシークレット、ネットワーク上の足場を手にします。そこから、Copy Fail や Dirty Frag のようなカーネルの LPE（ローカル権限昇格）を使えば、ホストにまで到達し得ます。

Sysdig Secure による PHP2Shell の検知

マネージドポリシーを使用している Sysdig Secure のお客様は、この活発な脅威を特定して対応するための検知機能を利用できます。Sysdig TRT はすでに、Sysdig Secure に PHP2Shell の Threat Intelligence エントリを公開しており、Sysdig の脆弱性管理は、イメージとホスト全体で脆弱な PHP バージョンを検出します。また、既存のランタイム検知ルールがポストエクスプロイト活動もカバーしています。 

Threat Intelligence

Sysdig Secure のお客様には、Threat Intelligence フィードにすでに PHP2Shell のエントリが用意されています。このエントリには、欠陥の概要、修正済みバージョン、暫定的な緩和策がまとめられています。さらに、お使いの環境で影響を受けているホストとワークロードの数も表示されます。その数を選択すると、影響を受けるアセットのフィルター済み検索が開きます。

脆弱性管理

Sysdig の脆弱性管理は、環境全体で CVE-2026-109618 と CVE-2026-109619 を検出します。

• イメージ：パイプラインとレジストリのスキャンにより、OS のパッケージマネージャー経由でインストールされた脆弱な PHP ランタイムを含むイメージを、本番環境に到達する前にフラグ付けします。
• ランタイムのワークロードとホスト：実行中のワークロードとホストは、新しい CVE と自動的に照合されます。再スキャンは不要です。
• ディストリビューションのバックポート：照合にはベンダーのアドバイザリが使われるため、パッチ適用済みのディストリビューションのパッケージが、アップストリームのバージョン番号だけを理由に脆弱と報告されることはありません。
• 優先順位付け：PHP パッケージが使用中のワークロードでフィルターし、インターネットに公開されているものから着手してください。

ランタイム検知

Sysdig TRT は、PHP2Shell 向けに2つの階層型ランタイムルールを作成し、動作するエクスプロイトに対して検証しました。これらは、Sysdig Runtime Behavioral Analytics ポリシーと Sysdig Runtime Notable Events ポリシーのマネージドルールとして提供されます。2つのルールは、PHP Web Worker Killed by Fatal Signal と PHP Web Worker Crash Followed by Shell Execution です。

PHP2Shell の攻撃が成功すると、攻撃者はコマンドラインを手に入れ、そこから先は、あらゆる Web RCE の後に攻撃者が行うことをします。リバースシェルを開き、ツールをダウンロードして実行し、マイナーを起動し、クラウドの認証情報を盗み、あるいはカーネルの LPE を試して root を取ろうとします。Sysdig Secure はすでに、デフォルトで有効なポリシーに含まれるマネージドルールで、こうしたポストエクスプロイト活動を検知します。これらのルールの多くは、親プロセスではなく挙動に基づいて一致するため、アプリケーションをどの PHP ランタイムが処理していても、同じように機能します。 

オープンソースの Falco による PHP2Shell の検知

Falco が見るのはシステムコールであり、HTTP リクエストではありません。悪意のあるリクエストそのものは見えませんが、そのリクエストがホスト上で引き起こすことは見えます。php ワーカーから起動されるシェルプロセスを検知するなど、考えられる検知戦略は数多くありますが、ノイズが大きな課題になることがよくあります。Sysdig Secure で先ほど示したように、既存のポストエクスプロイト検知戦略の多くが適用できます。

推奨事項

• すべてのサーバーで PHP をアップデートする：8.5.12、8.4.27、8.3.36、8.2.35、またはベンダーがパッチを適用したパッケージに移行してください。これが唯一の完全な修正です。アプリケーションコードでは修正できません。
• パッチ適用後、すべての PHP ワーカーを再起動する：古いワーカーは、脆弱なコードを実行し続けます。
• 今日パッチを適用できない場合は、暫定設定で緩和する：PHP は、これらの設定がリスクを低減するものの、取り除くものではないとしています。
  
  • php_admin_value を通じて memory_limit=-1 を設定し、アプリケーションが上書きできないようにします。代わりに、Web サーバーまたはプロキシでリクエストサイズの上限を強制してください。RLIMIT_AS や RLIMIT_DATA は使用しないでください。
  • php.ini または FPM プール設定で session.upload_progress.enabled=0 を設定します。ini_set() や .user.ini には頼らないでください。
  • PHP 8.5 では、さらに fatal_error_backtraces=0 も設定します。
  • すべてのワーカーを再起動し、CLI ではなく Web リクエストを通じて設定値を検証してください。‍
• アップロードが不要な場合は、エッジで multipart/form-data をブロックする：これにより、セッションのアップロード進捗の経路とメモリ漏えいを防げます。ただし、すべてのバグをカバーできるわけではなく、ファイルのアップロードや一部のチェックアウトフォームが動かなくなります。
• ‍環境を監査する：影響を受けるすべてのホストとワークロードを見つけ、インターネットに公開されているものから着手してください。Sysdig Secure のお客様は、Threat Intelligence エントリと脆弱性管理の検出結果を利用できます。 ‍
• 10月17日までさかのぼって調査する：悪用は開示の前から始まっていました。Web シェル、新しい cron ジョブ、新しいアカウント、Web サーバープロセスから起動されたシェルがないか確認してください。‍
• シークレットをローテーションする：メモリ漏えいがあるため、コード実行の兆候が見られなくても、さらされたサーバーのシークレットはローテーションすべきです。‍
• デフォルトのランタイムポリシーを有効にする：既知の脅威、脅威インテリジェンスとの一致、挙動の異常といった、ポストエクスプロイトの挙動に対する検知を利用してください。インターネットに公開された Web アプリケーションでは、Web サーバーから起動されたシェルや不審なコマンドをアラートの対象にしてください。Sysdig Runtime Threat Detection、Sysdig Runtime Threat Intelligence、Sysdig Runtime Behavioral Analytics の各ポリシーが、ポストエクスプロイトの段階を捉えます。インターネットに公開された PHP については、Sysdig Runtime Notable Events ポリシーも有効にするか、少なくとも、Web サーバーから起動されたシェルや不審なコマンドに関するそのルールを有効にしてください。

まとめ

PHP2Shell は、最も広く展開されている Web ランタイムである PHP コアにおける、2つの重大な CVE にまたがる4つのメモリ安全性のバグで構成されています。悪用は修正が存在する前から始まっており、PHP は2012年から脆弱なコードを抱え続けてきました。

これは、Copy Fail と Dirty Frag に続く、今年3件目の、古くから広く信頼されてきたコア部分に潜む影響の大きい欠陥です。これらの脆弱性と同様に、PHP2Shell も AI の支援によって発見されました。パッチが存在する前から悪用が始まり得るため、防御側はこれらの脆弱性に「侵害されている前提（assume breach）」の考え方で臨むべきです。まずパッチを適用してください。そのうえで、すべてのワーカーにパッチが適用されて再起動されるまでの間は、暫定設定、エッジでのフィルタリング、ランタイム検知を使って、このギャップを埋めてください。

‍