技術支援サービスEnglish相談する →
ホーム/確認・更新ガイド

TSUMIRA JAPAN · 確認・更新ガイド

PHP2Shellの技術解説｜CVE-2026-109618・109619の原因・影響・対策

情報確認日： · 発行：Tsumira Japan（SourceArt Ltd）

今回の問題はPHP本体のメモリ管理・リクエスト処理に関わる2件の脆弱性です。影響を受ける環境では、認証前のコード実行や情報漏えいにつながる可能性があります。サイトが表示できる、CMSを更新した、WAFを導入した、という事実だけでは修正完了と判断できません。

1. 何が、いつ公表されたのか

PHPは2026年10月21日に、CVE-2026-109618とCVE-2026-109619、および修正版を公表しました。本記事は2026年10月22日確認時点の情報を整理しています。公開日と本記事の確認日を分け、「今日」という表現で日付を曖昧にしないようにしています。

PHP2Shellは研究側の説明で使われる呼称です。サーバーの確認記録には、通称だけでなく2つのCVE番号、配布元、パッケージ情報を残してください。PHP本体の問題なので、特定のWordPressプラグインだけを探して終えると、確認範囲を取り違えます。

識別子中心となる問題管理上の着眼点
CVE-2026-109618メモリ不足時の中断と不整合な状態の処理実行方式、PHPの修正、ワーカーの入れ替え
CVE-2026-109619リクエストを越えて残る状態と解放済みメモリへの参照複数の経路を含む修正と設定の見直し

2. 用語を整理する：PHP・SAPI・ワーカー・RCE

用語本記事での意味
PHP本体アプリケーションを実行するランタイム。CMSとは別に保守される場合があります。
SAPIPHPとWebサーバーなどをつなぐ実行インターフェース。mod_php、FPM、CGIなど。
ワーカーリクエストを処理するプロセス。複数のリクエストで同じプロセスが再利用される構成があります。
OOMメモリ不足。PHP内部の制限と、OSなどの割り当て失敗は同じものではありません。
Use-after-free解放されたメモリを、有効なデータのように参照する問題。
RCE遠隔からコードを実行されること。影響範囲は、プロセスの権限や周囲の構成にも左右されます。

運用で区別したいのは、ディスク上に置かれたPHP、すでに動いているPHPプロセス、Webサイトが実際に利用するPHPの3つです。1つを更新・確認しただけでは、残りも一致しているとは限りません。

3. CVE-2026-109618：メモリ不足で処理が中断したときの問題

PHP公式の説明では、OOMによる処理中断が、まだ整合していないリクエスト状態を残す場合があります。その後の終了処理がその状態を扱うことで、メモリ破損からコード実行につながり得ます。mod_phpでは、アプリのコード開始前に到達する経路が示されています。

  1. リクエストを処理
  2. 途中でメモリ不足
  3. 不完全な状態が残る
  4. 終了処理がその状態を扱う

根拠：PHP公式のOOMアドバイザリー ↗

運用上は、「アプリでログインを確認しているから大丈夫」という判断を避けます。通信がアプリへ渡る前に何が行われるかも関わるため、アプリの認証設計とランタイムの修正を別々の確認項目にしてください。

4. CVE-2026-109619：前のリクエストの状態が残る問題

PHP公式は、ワーカーが保持する状態に、すでに解放されたリクエスト用メモリへの参照が残り、後の処理で使われる問題を説明しています。状態を残す処理と、あとで使う処理の組み合わせが重要で、エラーやセッションなど複数の経路が関係します。

  1. リクエストAの状態
  2. メモリ解放後も参照が残る
  3. ワーカーが再利用される
  4. リクエストBで古い参照を使う

根拠：PHP公式のstale global stateアドバイザリー ↗

対応記録では、ある設定項目を変更したことと、脆弱性全体が修正されたことを同一視しないようにします。プロセスを再起動しただけでコードの問題がなくなるわけでもありません。修正を含む実体への更新が先に必要です。

5. 影響：コード実行だけでなく、メモリ内の情報にも注意

Wiz Researchは、WordPress・Drupal・Joomlaを使った研究環境での認証前RCEと、PHPプロセスのメモリ情報の漏えいを報告しています。これらは特定のCMSだけに影響が限定されるという意味ではなく、PHP本体の問題の実証例として説明されています。

漏えいやコード実行が起きた場合、プロセスが扱える設定、認証情報、アプリケーションデータなどが調査対象になり得ます。ただし、この発表やバージョン表示だけから、個々のサイトですでに漏えいが起きたとは断定できません。

根拠：Wiz Researchの調査報告 ↗

事業への影響確認では、サイト停止だけでなく、予約・注文・顧客情報・外部APIとのつながりを整理します。どのデータにアクセスできるプロセスだったかを、環境に即して評価する必要があります。

6. mod_php・FPM・CGI・FrankenPHP・LiteSpeedをどう見るか

PHP公式の更新案内は、Webリクエストを処理するPHP全体を対象としています。実行方式によって確認された経路や条件は異なります。PHP公式はmod_phpのリスクを特に高く評価していますが、「FPMだから対象外」と判断する根拠にはなりません。

構成確認する対象
Apache mod_phpApacheに読み込まれるPHPモジュールとApacheプロセス
Nginx／Apache + PHP-FPM接続先のFPMバイナリー、プール、実行中ワーカー
php-cgi・FastCGI起動元、配布元、使い続けているプロセスの有無
FrankenPHP・LiteSpeedなど製品・ビルドに含まれるPHPと提供元の修正案内
コンテナー・複数ノード各イメージ・レプリカ・接続先。ホスト側だけの更新で終えない

「同じCVEに関係する」ことと、「すべての構成で同じ攻撃経路が実証されている」ことは区別します。研究時点の実証範囲を、未実証の環境の安全宣言へ読み替えないでください。

7. 修正版とバックポート：数字だけで判定しない

PHP公式系列今回の修正を含むリリース
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

これはPHP公式リリースの基準です。OS・ホスティング事業者によるバックポートでは、先頭のバージョン番号が変わらなくても修正される場合があります。系列、配布元、完全なパッケージ版、公式案内を組み合わせて確認します。

例として、Ubuntu 24.04のUSN-8948-1には8.3.6-0ubuntu0.24.04.13が掲載されています。Debianでも、そのリリース向けのセキュリティパッケージを確認します。UbuntuとDebian、第三者配布元の番号を互いに置き換えて判断しないでください。

PHP 8.1以前を使う場合は、PHP公式の継続サポートとは別に、提供元が今回の修正と保守を提供するかを確認します。単に利用可能なことは、更新が提供され続けることを意味しません。

8. 暫定策はなぜ「修正完了」ではないのか

更新を直ちに行えない場合の判断は、担当管理者と行ってください。以下は公式案内の位置づけを理解するための要点で、そのまま適用する設定手順ではありません。停止やメモリ枯渇などの運用上の影響も考慮が必要です。

対応・設定注意すべき限界
WAF・リクエスト制限通過経路や設定を要確認。ランタイムの修正を置き換えない。
memory_limit=-1PHPの制限経路に関する緩和策。メモリ使用や割り当て失敗のリスクを別途評価。
session.upload_progress.enabled=0確認されたセッション経路への対策。すべての変種に対する修正ではない。
PHP 8.5のfatal_error_backtraces=0該当する経路を対象とする限定的な対策。
display_errorsを無効化公開エラーを抑える設定と、今回の根本原因の修正は別。

設定を置く場所や、ワーカーへの反映時点も関係します。アプリ内のini_set()で変更すれば十分、とは判断できません。公式アドバイザリーを管理者が確認し、緩和策を期限付きで記録したうえで、修正版への移行を進めてください。

9. 公開URLチェックでわかること・わからないこと

得られた情報判断できる範囲
公開ヘッダーのPHP表示表示されたバージョンという手がかり。実行中の全環境ではない。
バージョンが取得できない公開情報だけでは判断不可。正常・異常のいずれも断定しない。
修正版以降の番号参考になるが、すべてのオリジン・ノードの修正を証明しない。
外部からHTTP 200応答したこと。キャッシュの場合もあり、更新完了を証明しない。

Tsumiraの簡易チェックは公開情報を確認するもので、攻撃の試行や侵害調査は行いません。提供元の修正、管理画面、実行中プロセスを確認する手順へつなげるための入口として利用してください。

10. 優先順位をつけるための判断表

状況最初の行動
公開PHPの修正状況が不明実行環境と提供元を特定し、修正版と必要な作業を確認。
修正版はあるが未適用復旧準備と保守手順を確認し、適用とワーカーの入れ替えを進める。
修正版が届かない・保守対象外提供元へ確認し、露出を減らす方法と保守可能な移行先を検討。
不審なファイル・アカウント・通信がある更新だけで済ませず、証拠保全とインシデント対応を調整。
複数台で一部だけ対応済み未対応ノードを把握し、経路と全体の適用状況を確認。

この表は運用の整理案です。個別サイトの危険度判定、緊急対応時間、復旧期限を保証するものではありません。顧客情報や業務停止の影響が大きい場合は、管理者や専門家との確認を優先してください。

11. 侵害の有無と、パッチ適用は別に確認する

研究報告では、通常とは異なるリクエスト、メモリエラー、繰り返す500応答、ワーカーの不自然な入れ替わりなどが調査の手がかりとして挙げられています。いずれも単独で今回の攻撃を証明するものではありません。

不審点がある場合は、担当者へ発生時刻、対象、変更内容を伝え、既存ログを消さないようにします。ログやバックアップの扱い、調査対象、復旧経路を決めてから進めてください。認証情報の変更や復旧は、安全な管理経路から調整します。

一方で、エラーが見つからない、サイトが通常表示される、簡易チェックで新しい番号が出た、という結果も「侵害なし」の証明ではありません。侵害調査と更新の完了記録は分けて管理します。

12. 「対応済み」と報告するときに残す証跡

  • 対象ドメイン・ノード・プール・コンテナーと、対象外とした環境の理由。
  • 提供元の公式案内、導入した完全なパッケージ版・イメージ識別子、確認日時。
  • 更新後にプロセスが入れ替わった記録と、実際のWeb用PHPとの対応。
  • 問い合わせ・予約・決済などの検証結果、未解決の問題、引き継ぎ先。

サイト担当者への報告では、「何を更新したか」「どこまで確認したか」「何が未確認か」を分けると、追加の対応が必要か判断しやすくなります。根拠となる情報を残せない場合は、その点も未確認として伝えてください。

13. 次の一歩：実際の更新手順か、専門家への相談へ

コード例付きのサーバー更新・検証手順へ →

サーバー管理の経験がある方は、対象環境に合う手順と公式資料を照合してください。構成、コマンドの意味、バックアップや復旧を判断できない方は、操作を試さずに調査・更新サポートをご相談ください。

本記事は一般的な技術解説です。個別環境での安全性、侵害の有無、作業の成功を保証しません。Tsumira Japanの有料作業は、ご相談後に範囲と費用をご案内し、ご承認をいただいてから実施します。

よくあるご質問

WordPressが最新ならPHPの更新は不要ですか？

別に確認が必要です。WordPress本体とサーバーのPHPは、異なる担当や手順で保守されることがあります。

PHP-FPMなら影響はありませんか？

そのようには判断できません。実行方式ごとの経路・条件に違いがあっても、PHP公式はWeb用PHPの更新を案内しています。

WAFで防いでいるので、更新を見送れますか？

WAFは多層防御の一部です。保護範囲や迂回経路を含めて確認し、修正版への更新を進めてください。

すでに自分のサイトが攻撃されたと考えるべきですか？

公表やバージョン表示だけで侵害は断定できません。不審な兆候があれば、調査と証拠保全を専門家と進めてください。

公式情報・参考資料

公式情報や画面構成は変更される場合があります。実際の契約・設定・提供元の最新案内を優先してください。本記事は個別環境の安全性や修正完了を保証するものではありません。

ご自身のサイトについて相談したい方へ

わかる範囲の情報から、確認方法と対応範囲を整理します。有料作業は、内容と費用のご承認後に進めます。

この内容について相談する →無料簡易チェック →

Tsumira開発者・Steve vom Wegeの経歴 · Tsumira.jp ↗

関連するガイド