検知と対応

攻撃を受けたか?

すべての亜種を捉える単一のルールはなく、脆弱なコードはアプリケーションより下の層で動くため、アプリのログには何も残らないことがあります。これらの兆候は優先順位付けのために使い、安全の証明には使わないでください。

最終確認 2026-10-22

兆候がないことは安全の証明ではない

メモリ漏えいの経路では、サーバー上でコードを一切実行せずに機密情報を盗めます。調査結果にかかわらずパッチを適用してください。

調べる価値のある兆候

兆候なぜ重要か確認場所
multipart POST の直後にメモリ上限の致命的エラーメモリ枯渇はトリガーの一つです。CVE-2026-109619 には OOM に依存しない経路もあり、OOM エラーがなくても除外できません。PHP/FPM のエラーログ + Web アクセスログ
1 つのクライアントから HTTP 500 が集中エクスプロイトは標的のメモリ配置に合わせるため、何度も試行する必要があります。アクセスログ
SIGSEGV / SIGABRT でワーカーが落ちる、またはワーカーの入れ替わりが異常に多い失敗した use-after-free の試行はワーカーをクラッシュさせがちです。FPM ログ、Apache エラーログ、dmesg / journal
レスポンスに異常に長い、またはパーセントエンコードされた PHPSESSIDメモリ漏えいの経路は、漏れたヒープメモリを URL エンコードしてセッション Cookie に書き込みます——session_start() を呼ばないサイトでも発生します。Set-Cookie を記録しているリバースプロキシ/CDN/WAF のログ(標準のアクセスログにはない)
Web ルートに新しい .php ファイル、PHP ユーザーによる想定外の子プロセス典型的な侵入後の挙動:Web シェル、curl/wget、www-data からのリバースシェル。ファイルシステム、EDR、プロセス監査

通常の PHPSESSID は短い英数字です(デフォルトで 32 文字)。数百文字に及んだり、%xx のバイト列が含まれていたりするのは異常です。

ログを検索する

パスは Debian/Ubuntu のデフォルトです。環境に合わせて調整し、少なくとも 2026 年 10 月初旬以降の期間を対象にしてください。

shell
# 1. Memory-limit fatals (PHP's exact message)
sudo grep -rh "Allowed memory size of" /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ /var/log/nginx/ 2>/dev/null | tail -50

# 2. Workers killed by signals
sudo grep -rhE "exited on signal (6|11)|exit signal (Segmentation fault|Aborted)" \
  /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ 2>/dev/null | tail -50
sudo journalctl --since "2026-10-01" | grep -E "php.*segfault" | tail

# 3. Clients producing many 500s on POST (combined log format)
sudo awk '$6=="\"POST" && $9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | sort | uniq -c | sort -rn | head -20

パッチ適用後は、新しいハードメモリリミットによってもワーカーが突然終了することがあります。1 回の終了だけでは攻撃の証拠にはなりません——同じクライアントや同じリクエストパターンに集中しているかを見てください。

プロキシでメモリ漏えいを捉える

nginx + shell
# Temporary: log Set-Cookie on responses to spot oversized PHPSESSID values.
# This writes session IDs to disk — restrict the file and remove it afterwards.
# In the http {} block:
log_format php2shell '$remote_addr [$time_local] "$request" $status "$sent_http_set_cookie"';
# In the server {} block:
access_log /var/log/nginx/php2shell.log php2shell;

# Then, from a shell, look for long or percent-encoded session cookies
grep -E 'PHPSESSID=[^;"]{64,}|PHPSESSID=[^;"]*%' /var/log/nginx/php2shell.log

侵入後の痕跡を探す

shell
# PHP files changed in the web root since the bugs became known (adjust path/date)
sudo find /var/www -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort | tail -100

# Processes the web user is running right now (shells and downloaders are red flags)
ps -u www-data -o pid,ppid,lstart,cmd | grep -vE 'php-fpm|apache2|httpd'

# Established connections owned by PHP / Apache — review every remote address
sudo ss -tpn state established | grep -E 'php|apache|httpd'

WAF の対応状況

マネージドルールはパッチ適用までの暫定策です。利用中の事業者の PHP2Shell 関連情報を確認してください。Cloudflare はルール ID を公開しています——Cloudflare のページ を参照。

セキュリティベンダーの検知

これらの製品を使っている場合、各社の記事で提供済みのシグネチャやハンティングクエリが紹介されています。

GitHub の「PoC」スクリプトをサーバーで実行しない

エクスプロイトやスキャナーのリポジトリは信頼できないコードとして扱ってください。公開されていても有効性や安全性の証明にはなりません。ベンダーの確認方法を優先し、本番で未知のスクリプトを実行しないでください。

何か見つかったら

  1. まず証拠を保全:再構築の前にログをコピーし、可能ならディスク/メモリのスナップショットを取ってください。
  2. ホストにパッチを適用するか隔離します。その場で掃除するより、クリーンなイメージから再構築するほうが確実です。
  3. PHP がメモリ上で見られたものはすべて入れ替える:DB パスワード、API キー、OAuth クライアントシークレット、SMTP 認証情報、アプリの鍵(APP_KEY、WordPress のソルト)、PHP がアクセスできた TLS 秘密鍵。
  4. セッションを無効化して盗まれた Cookie を使えなくし、管理者に再ログインしてもらってください。
  5. 影響範囲を確認:それらの認証情報で他に何にアクセスできるか(クラウドアカウント、社内 API、他のデータベース)。