JPCERTがPHP侵害調査の確認点を公開｜Cookieとワーカー異常を時系列で調べる

JPCERT/CCは2026年10月22日、PHPの重大脆弱性CVE-2026-109618とCVE-2026-109619に関する注意喚起を公開し、侵害調査で確認すべき具体的な痕跡を示しました。修正版へ更新しただけで対応を終えず、PHPSESSID Cookie、multipart/form-data形式の要求、PHPワーカーの異常終了を時系列で調べる段階です。

同日には「侵害調査」の一部表現も修正されています。本稿は10月22日19時30分（日本時間）までに確認したJPCERT/CCの注意喚起と、PHP開発チームのアドバイザリを根拠にした続報です。検知項目は攻撃の有無を機械的に断定する指標ではなく、調査の入口として扱います。

修正版と技術条件は、本サイトのPHPが重大RCEの修正版を公開した際の記事で整理しています。今回は重複を避け、更新後に何を保存し、どの順序で調べ、何をもって未侵害と断定してはいけないかに焦点を絞ります。

JPCERTが示した三つの確認点

JPCERT/CCが挙げた確認点は、Webアクセスの入口、PHPのエラー、ワーカープロセスという三層にまたがります。一つのログだけで判断せず、同じ時刻帯の記録を関連付ける必要があります。

• 過去のHTTPレスポンスで、不自然に長い値や異常な形式の値を含むPHPSESSID Cookieが設定されていないか
• 不審なmultipart/form-data形式のHTTPリクエストがなく、その前後にPHPのメモリ上限に関するエラーやHTTP 500が発生していないか
• PHPワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか

重要なのは、Cookie、リクエスト、エラー、プロセス再起動を別々の担当者が別々に確認して終了しないことです。ロードバランサーやCDNには要求と応答ヘッダーが残り、Webサーバーにはアクセスログ、PHP-FPMやApacheにはエラーとワーカーの状態、OSやコンテナ基盤にはプロセス終了の記録が残る場合があります。タイムゾーンと時計のずれをそろえ、同一の要求IDや接続元、対象ホスト、時刻帯で関連付けます。

確認対象	主な記録場所	関連付ける情報
PHPSESSID Cookie	CDN、リバースプロキシ、Webサーバーの応答ログ	設定時刻、対象URL、値の長さと形式、直前の要求
multipart/form-data	WAF、アクセスログ、アプリ入口の監査ログ	Content-Type、要求サイズ、Content-Length、HTTP状態
メモリ上限・HTTP 500	PHP、Webサーバー、APM	memory_limit、OOM、例外、同時刻の要求
ワーカー異常終了	PHP-FPM、Apache、systemd、コンテナ基盤	終了コード、再起動回数、Podやプロセスの置換

調査前にログを失わない

修正版の適用やワーカー再起動は必要ですが、手順によっては揮発性の情報や短期保存のログを失います。更新作業を止めるという意味ではなく、更新と証拠保全を並行させます。対象サーバー、PHPのSAPI、稼働バージョン、設定ファイル、コンテナイメージのダイジェスト、直近の再起動時刻を記録し、変更前後を区別できるようにしてください。

本サイトの提案としては、最初にCDN・WAF・ロードバランサー・Webサーバー・PHP・OSまたはコンテナのログ保存期間を確認し、上書きされやすいものから退避します。原本を直接検索して更新日時を変えるのではなく、アクセス権を限定した場所へコピーし、取得時刻、取得者、ハッシュ値を記録します。侵害が疑われる場合は、関連ログを消去する自動ローテーションや再デプロイにも注意が必要です。

調査開始日は少なくとも修正版公開日だけに固定しません。AWSが公表前の10月17日から攻撃試行を観測した報告を踏まえ、保持できる環境では10月17日以前も含めて確認範囲を決めます。ただし、ハニーポットでの攻撃試行の観測は、自社サイトの侵害成功を意味しません。自社の記録を別途評価します。

PHPSESSIDは長さだけで決めつけない

不自然に長いPHPSESSIDは有力な調査起点ですが、正規のアプリケーションや設定によってCookieの形式は異なります。まず平常時の長さ、文字種、同じ値が使われる期間を確認し、外れ値を抽出します。値そのものに個人情報や認証情報が含まれる可能性があるため、分析用データの共有先とマスキング方針も決めます。

異常値が見つかったら、Cookieが設定された応答だけを見るのではなく、その直前に届いた要求、同じ接続元のmultipart要求、HTTP 500、PHPエラー、ワーカー再起動へ時間軸を広げます。逆に、長いCookieが一件見つかっただけでコード実行が成功したと公表するのは早計です。アプリの正規動作、スキャナー、攻撃試行、侵害成功を段階に分けて評価します。

multipartとメモリエラーを同時に見る理由

CVE-2026-109618の公式アドバイザリは、multipart解析でメモリ不足へ到達し得る複数の条件を説明しています。使用可能なContent-Lengthがない要求、非常に多いパートヘッダー、空のファイル項目、入れ子のフィールド名などです。見かけ上の要求サイズが小さくても、PHP内部で大きなメモリを使う場合があります。

そのため、単純にPOSTサイズが大きい要求だけを検索すると見落とします。Content-Type、Content-Lengthの有無、パート数、ヘッダー数、フィールド名の深さ、応答状態を組み合わせます。WAFやCDNで要求本文を記録していない場合でも、周辺メタデータとPHP側のOOM、HTTP 500、ワーカー終了を突き合わせることで優先順位を付けられます。

ただし、通常のファイルアップロードや大量フォーム送信でもmultipartと500エラーは発生します。業務上のアップロード時間帯、既知のバッチ、負荷試験、デプロイ失敗を除外しながら調べます。公開フォームだけでなく、管理画面、API、画像・文書の取り込み、問い合わせフォームなど、PHPが要求を解析する入口を一覧にしてください。

ワーカー再起動は可用性監視だけでは足りない

PHP-FPMでは子プロセスの置換が通常運用でも起こるため、再起動件数だけでは判断できません。設定されたmax_requests到達、デプロイ、オートスケール、ヘルスチェック失敗、OOM Killer、セグメンテーションフォルトなど原因を分けます。ベースラインより急増した時間帯と、不審な要求やHTTP 500が重なるかを確認します。

Apacheのmod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedではプロセスモデルとログの場所が異なります。PHP公式はWebリクエストを処理する各構成を確認対象とし、特にmod_phpではアプリケーションコードの実行前に成立する攻撃が実証されたと説明しています。CMSの監査ログだけでは、アプリより前で起きた異常を捉えられない点に注意してください。

痕跡がなくても未侵害とは断定できない

JPCERT/CCは、複数の悪用経路があり、単一の検知ルールですべてを検出できるとは限らないと明記しています。攻撃手法やログ設定によっては痕跡が残らない場合もあります。三つの確認点で該当がなかったことは安心材料の一つですが、安全の証明ではありません。

調査では、不審なプロセス、外部通信、予期しないファイル作成、Webルートや一時ディレクトリの変更、永続化設定、認証情報の利用も確認します。WAFで遮断されたイベント、オリジンへ直接届いた通信、内部ロードバランサー経由の要求を分けます。Cloudflareの観測とWAF確認を扱った記事も、入口側の調査範囲を決める参考になります。

更新後に実施する順序

1. 対象PHPと公開経路を棚卸しし、証拠保全の担当者と保存先を決める
2. PHP 8.5.12、8.4.27、8.3.36、8.2.35またはベンダーの修正済みパッケージへ更新する
3. 稼働中の全ワーカーとコンテナが修正版へ切り替わったことを確認する
4. 10月17日以前を含む調査期間を決め、Cookie、multipart、500、OOM、ワーカー終了を時系列で照合する
5. 不審プロセス、外部通信、ファイル変更、資格情報利用まで範囲を広げる
6. 侵害が疑われる場合は証拠を保全し、対象を隔離して影響範囲と認証情報の扱いを判断する

PHP公式が示す暫定策は特定の攻撃経路を減らすもので、完全な対策は更新です。memory_limitやsession.upload_progressの変更だけで安全になったとは扱えません。更新できない環境は公開制限や隔離を検討し、EOLのPHP 8.1以前はサポートされる系統への移行またはベンダーのバックポート有無を確認します。

今回新たに確定したこと

10月21日のPHP公式発表で修正版と攻撃条件が明らかになり、10月22日のJPCERT/CC注意喚起によって国内運用者向けの侵害調査項目が具体化しました。対応の完了条件は「バージョンを上げた」だけではありません。修正版の稼働確認、過去ログの保全と照合、侵害を示す追加痕跡の確認までを一つの作業として管理する必要があります。

関連記事

• PHPが重大RCEの修正版を公開！8.5.12など4系統へ緊急更新
• AWSがPHP脆弱性の公表前の攻撃試行を報告｜10月17日からの記録確認を推奨
• PHP脆弱性を狙う攻撃通信をCloudflareが観測｜WAFと調査範囲を点検する