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やSNSに流出しました。PHPは同日に事前告知を公開し、リリースを1日前倒しして10月21日14:00（UTC）としました。
攻撃はパッチの公開を待ちませんでした。Amazon Threat Intelligenceは、開示の4日前にあたる10月17日、同社のハニーポット「MadPot」に対するPHP2Shellの攻撃試行を確認しました。Cloudflareは、修正版の公開より6時間以上前の10月21日07:43（UTC）に早期の攻撃を報告しています。watchTowrもこれらのバグを再現し、それぞれに対する悪用の試みが活発に行われていると報告しました。
脆弱なコードは、2012年にリリースされたPHP 5.4にまでさかのぼります。バグはアプリケーションではなくPHPエンジン内部にあります。そのため、アプリケーションコードに問題のないWordPress、Drupal、Joomlaのサイトであっても、影響を受けます。
セキュリティチーム向けの追加の推奨事項を示し、Sysdig SecureおよびオープンソースのFalcoユーザー向けのランタイム検知を整備するため、Sysdig Threat Research Team（TRT）はPHP2Shellの悪用を分析しました。結果を以下にまとめます。
影響を受けるPHPバージョン
|
PHPバージョン |
状況 |
対応 |
|
5.4～7.3 |
サポート終了。PHPプロジェクトによる修正はありません。 |
パッチ適用済みのブランチへ移行してください。 |
|
7.4、8.0、8.1 |
公式アップデートは未公開です。PHPセキュリティチームは、これらのバージョンに限り最小限のソースバックポートを公開しました。 |
ベンダーがパッチを適用したディストリビューションのパッケージを使うか、サポート対象のブランチへ移行してください。 |
|
8.2、8.3、8.4、8.5 |
ブランチ8.2.35、8.3.36、8.4.27、8.5.12で修正済み |
修正版以降にアップデートしてください。 |
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の型混同：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のスレットインテリジェンスエントリを公開しています。また、Sysdigの脆弱性管理は、イメージとホストにわたって脆弱なPHPバージョンを検出します。既存のランタイム検知ルールは、侵入後の活動もカバーしています。
スレットインテリジェンス
Sysdig Secureのお客様は、スレットインテリジェンスフィードに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の後と同じことを行います。リバースシェルを開き、ツールをダウンロードして実行し、マイナーを起動し、クラウドの認証情報を盗み、あるいはrootを得るためにカーネルのLPEを試みます。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サーバまたはプロキシでリクエストサイズDの上限を強制してください。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のお客様は、スレットインテリジェンスのエントリと脆弱性管理の検出結果を利用できます。
- 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の支援を受けて発見されました。パッチが出る前に悪用が始まることもあるため、防御側は「侵害されている」ことを前提に、これらの脆弱性へ対処すべきです。まずパッチを適用してください。そのうえで、すべてのワーカーにパッチを適用して再起動するまでは、暫定設定、エッジでのフィルタリング、ランタイム検知を使って、対策の穴を埋めてください。
