PHP更新後にやること7項目｜PHP2Shell痕跡確認と鍵の入れ替え

PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618／CVE-2026-109619）の修正版が、2026年10月21日23時（日本時間）に公開されました。サーバーのPHPを更新できたら、次にやることは2つです。攻撃の痕跡を確認することと、漏れたかもしれないパスワードや鍵を入れ替えることです。

この記事は2026年10月22日時点で公開されている情報だけをもとに、自社サイト（WordPress・EC・会員サイト・問い合わせフォーム）の担当者と、保守を請けている制作会社が、上から順に手を動かせるようにまとめました。PHP2Shell の全体像はPHP2Shellで今やるべきことのまとめを先にご覧ください。

結論：更新は「これ以上の侵入」を止めるだけ

PHPの更新で止まるのは、これから来る攻撃です。更新するまでの間に読み取られたかもしれない情報は、更新しても取り戻せません。

理由は CVE-2026-109618 の性質にあります。Sansec と Wiz は、この脆弱性でPHPのメモリの中身が PHPSESSID クッキーに乗って外に出うること、そのメモリにはほかのリクエストのパスワード・セッショントークン・APIキー・TLS秘密鍵などが含まれうることを示しています。Wiz は、このメモリ漏えいはサーバーの乗っ取り（コード実行）がなくても起きるとしています。アプリが session_start() を呼ばない作りでも起きる点も、両社が書いています。

一方で、「侵害された」と断定できる方法は、今のところ公表されていません。PHP公式も、侵害痕跡（IoC）の一覧は出していません。そのため、この記事では「痕跡を探す」と「痕跡が見つからなくても、漏れて困る秘密は替えておく」の2本立てで進めます。

やることは次の7項目です。

危険だった期間を決める
ログで PHP2Shell の手がかりを見る
ファイル・ユーザーを点検する（一般的な改ざん点検）
ログイン中のセッションをすべて無効にする
管理者とデータベースのパスワードを変える
外部サービスのAPIキーを再発行する
サーバーの鍵・証明書と、サーバーが持つ権限を見直す

1. 危険だった期間はいつからいつまでか

点検するログの範囲と、入れ替える秘密の範囲を決めるために、まず「自社のサイトが無防備だった期間」を決めます。

日時（日本時間）	できごと
2026年8月	Calif と OpenAI がそれぞれPHPに報告。続いて Wiz も報告
10月21日 0時ごろ	CVE番号が、誤った情報つきで修正版の公開前に出回る（技術的な詳細は含まれず）
10月21日 16時43分	Cloudflare が「早期の攻撃が出始めている」と投稿し、全プランにWAFルールを展開
10月21日 23時	PHPの修正版（8.5.12／8.4.27／8.3.36／8.2.35）を公開
10月22日朝	さくらインターネット（6時30分）、エックスサーバー（6時45分）などがサーバーのPHP更新を告知

始まりは、少なくともCVE番号が出回った10月21日0時ごろ（10月20日15時ごろ・協定世界時）以降と見ます。ログが残っていれば、さらに前もさかのぼって確認してください。脆弱性がPHPに報告されたのは8月で、兆候は2024年の外部監査で見つかっていたためです。終わりは、自社のサーバーが修正版（または事業者・OS配布元が修正を当てた版）のPHPで動き始めた時点です。共用のレンタルサーバーなら事業者の完了告知の時刻、VPSや自社サーバーなら更新してPHP-FPMやApacheを再起動した時刻が目安になります。パッケージを入れ替えても、再起動するまでは古いPHPのまま動き続けていることがあるためです。

攻撃の観測は、10月22日朝の時点で報告が分かれています。piyolog のまとめによると、Cloudflare と watchTowr は悪用を観測し、Patchstack は提携するホスティング事業者から悪用の報告を複数受けた一方、侵害の確かな証拠はまだないとしています。CISA と Huntress は、その時点では観測していないとしていました。

修正の当たっていない PHP 8.1以前で動いているサイトは、期間がまだ終わっていません（事業者が古い版にも修正を当てた共用サーバーでは終わっています。事業者のお知らせで確かめてください）。入れ替えより先に、修正版が出ない古いPHPの対処を進めてください。入れ替えた鍵が、また同じ穴から漏れるおそれがあるためです。

2. ログで見る：PHP2Shell の手がかりは3つ

公開情報のなかで、PHP2Shell に固有の手がかりとして書かれているのは次の3つだけです。Wiz はこれらを「調査の手がかり」として挙げており、見つかったからといって侵害が確定するわけではありません。

手がかり	どこで見るか	出典
multipart/form-data の大きなリクエストの直後に、メモリ上限エラーや HTTP 500 が続いている	アクセスログ（POST・ステータス500・サイズ）とPHPのエラーログ（メモリ上限のエラー。PHPでは「Allowed memory size of … exhausted」という文言で出るのが一般的）	Wiz／Sansec
レスポンスの PHPSESSID クッキーが、異常に長い・形が崩れている	WAFやロードバランサーのログ、レスポンスヘッダーを記録している場合のみ	Wiz／Sansec
説明のつかないPHPワーカーの入れ替わり（異常終了・再起動の増加）	PHP-FPMのログ、Apacheのエラーログ、監視ツールのメモリ使用量グラフ	Wiz

見るときの注意点が3つあります。

アプリのログにはほとんど残らない：Wiz は、この攻撃がアプリより下の層で動くため、アプリのログには文脈がほとんど残らないとしています。WordPress のセキュリティプラグインのログだけで判断しないでください。
送り返したクッキーは、通常のアクセスログに残らないことが多い：標準的なアクセスログはリクエストの記録が中心で、サーバーが返した Set-Cookie の中身までは書かれない設定が一般的です。2つ目の手がかりは、記録していた環境でだけ使えます。
ログが残っているか、消されていないかも見る：GMO Flatt Security は、攻撃を受けていないかのログ調査とあわせて、ログが記録され、改ざんから守られているかの確認を挙げています。期間中のログが欠けていたら、それ自体を記録しておきます。

ここに書いた以外の「この文字列があれば攻撃」といった検知ルールは、10月22日時点で信頼できる出典が見当たりません。ネット上の非公式なルールを使う場合は、出どころを確かめてからにしてください。

3. ファイル・ユーザーで見る（PHP2Shell 固有ではない一般的な点検）

ここからは、PHP2Shell に限らず、Webサイトが乗っ取られたときに一般的に確かめる場所です。PHP2Shell は認証なしでコード実行につながりうるため、期間中に開いていたサイトでは一度見ておく価値があります。

最近作られた・書き換えられたPHPファイル：期間中に更新日時が変わったPHPファイルを探します。画像置き場（WordPressなら wp-content/uploads）に .php があれば要注意です
管理者ユーザー：WordPress の「ユーザー」で権限が管理者の人を並べ、覚えのないアカウントがないか確かめます
.htaccess：見覚えのないリダイレクトや書き換えの行が増えていないか、更新日時とあわせて見ます
定期実行（cron）：サーバーのcron設定と、WordPress内の予定（WP-Cron）に、覚えのない処理がないか確かめます
プラグイン・テーマ：入れた覚えのないもの、更新日時が期間中に変わっているものがないか見ます

改ざんの確認手順と、見つかったときの戻し方はホームページが改ざんされたときの確認手順と復旧5ステップに詳しくまとめています。

4〜7. パスワード・APIキー・セッションを入れ替える順番

痕跡が見つからなかった場合も、期間中にPHPが扱っていた秘密は入れ替えておくのが安全側です。メモリの漏えいはアプリのログに残りにくく、「見つからない」と「漏れていない」が同じではないためです。

ただし全部を一度に替えると、決済やメール通知が止まる事故が起きやすくなります。次の順で進めてください。

順番	何を替えるか	なぜ	やり方の要点
4	ログイン中の全セッション（全員を一度ログアウト）	セッショントークンが漏れていると、パスワードなしで管理画面や会員ページに入られうる	WordPress は wp-config.php のセキュリティキー（salt）を作り直すと、既存のログイン状態がすべて無効になる。ほかのアプリは「全端末からログアウト」機能か、制作会社に依頼
5	管理者パスワード（WordPress・EC管理画面など）	期間中のログイン操作で送られたパスワードがメモリに乗っていた可能性がある	使い回しをやめ、2段階認証を有効にする。同じパスワードを使っていたほかのサービスも替える
5	データベースのパスワード	PHPが毎回の処理で読み込む設定値のため	サーバー側でDBのパスワードを変え、wp-config.php など設定ファイルの値も同時に書き換える
6	外部サービスのAPIキー（決済・メール配信・Google・SMS・在庫連携など）	決済代行やメール配信のキーが漏れると、なりすましの決済・送信に使われうる	新しいキーを発行 → 設定を差し替え → 動作確認 → 古いキーを無効化、の順。先に古いキーを消すと止まる
7	SSH・FTP・サーバー管理画面のパスワード／鍵	乗っ取られていた場合、サーバー内の設定ファイルから読まれうる	痕跡があったら最優先。なければ定期変更のついでで可
7	TLS秘密鍵とSSL証明書	Sansec が漏れうるものに TLS 秘密鍵を挙げている	VPS・自社サーバーは鍵を作り直して証明書を再発行し、古い証明書は失効させる。PHP公式がリスク最大とする mod_php で動かしていた場合は優先度を上げる

実務で多いつまずきは2つあります。1つ目は、APIキーを差し替えたあと、問い合わせフォームの自動返信や決済の完了通知が止まっていることに数日気づかない例です。差し替えたら、実際にテスト送信・テスト決済まで通してください。2つ目は、salt を書き換えるときの書き間違いです。wp-config.php の記号が1つ欠けるだけで管理画面が開けなくなります。そうなったときはWordPressのログイン画面が404・真っ白になるときの原因を参考にしてください。

会員サイトやECで、期間中にログインした会員がいる場合は、会員のパスワードも漏れた可能性があります。痕跡が見つかったときは、会員へのパスワード変更の案内も検討してください。替えたものと日時は、一覧にして残しておくと、あとで説明が必要になったときに役立ちます。

Mihata では、WordPress を中心にホームページの制作から公開後の保守まで行っております。「点検する人が社内にいない」「保守会社と連絡がつかない」という場合は、よろしければサービスの内容もあわせてご覧ください。

共用サーバーと VPS・自社サーバーでできる範囲

共用のレンタルサーバーでは、PHPの更新もサーバーの奥のログも事業者の管理です。利用者がやるのは、事業者の告知を確かめることと、自分のアプリ側の秘密を替えることが中心になります。

やること	共用レンタルサーバー	VPS・自社サーバー・クラウド
PHPの更新	事業者が実施。各社のお知らせで、使っている版に修正が当たったかと完了時刻を確認	自分で更新し、PHP-FPM・Apacheを再起動
ログの確認	管理画面のアクセスログ・エラーログが見られる範囲で	Web・PHP-FPM・WAF・監視のログまで見る
ワーカーの異常終了	利用者からは見られないことが多い。気になれば事業者に問い合わせ	PHP-FPMのログとメモリのグラフで確認
セッション・管理者・APIキー	利用者がやる（アプリ側の作業なので同じ）	同じ
DB・FTPのパスワード	サーバーの管理画面から変更	自分で変更
SSL証明書	事業者が発行する無料SSLが多い。事業者のお知らせに従う	自分で鍵を作り直して再発行
サーバーが持つ権限	該当しないことが多い	クラウドならIAMロールやサービスアカウントの権限を確認（GMO Flatt Security の推奨）

国内の主なレンタルサーバーの対応状況はレンタルサーバー別のPHP脆弱性への対応まとめで整理しています。最新の状況は、契約している事業者のお知らせで確かめてください。

痕跡が見つかったときの初動

手がかりや改ざんの跡が見つかったら、直す前に次の順で動きます。

止める：サイトを静的なメンテナンス画面に切り替えるか、サーバーごと外部から切り離します。Sansec は、アプリのメンテナンスモードではPHPがリクエストを先に解析してしまうため、PHP2Shell の攻撃は防げないとしています
残す：ログ・不審なファイル・データベースを、消したり上書きしたりする前に別の場所へコピーします。あとで原因と範囲を調べる材料になります
入れ替える：前の章の表を、SSH・FTP・会員パスワードまで含めて最優先で進めます
相談する・報告する：次の表の窓口に相談します

相談先	こんなとき
IPA 情報セキュリティ安心相談窓口	何をすればよいか、技術的な相談をしたい
警察のサイバー事案に関する相談窓口	被害の相談・通報をしたい。都道府県警察の窓口か、警察庁のオンライン受付を使う
個人情報保護委員会（漏えい等の対応）	顧客・会員の個人データが漏れた、または漏れたおそれがある

個人情報保護委員会によると、不正の目的による漏えい等（第三者によるものを含む）や、本人が1,000人を超える場合などは、漏れた「おそれ」の段階でも報告の対象になります。速報は発覚から3〜5日以内、確報は30日以内（不正の目的によるものは60日以内）です。自社が対象になるかは、委員会の案内や弁護士に確かめてください。

まとめ：痕跡が見つからなくても、秘密は替えておく

PHPの更新で止まるのは、これからの攻撃だけ。更新前に漏れたかもしれない秘密は残る
危険だった期間は、少なくとも10月21日0時ごろから、自社のPHPが修正版（または修正の当たった版）で動き始めた時点まで。ログが残っていれば、さらに前もさかのぼる
PHP2Shell 固有の手がかりは「大きな multipart の直後のメモリエラー・500」「異常な PHPSESSID」「ワーカーの異常終了」の3つ。侵害を断定する方法はまだ公表されていない
入れ替えは、セッション → 管理者・DBパスワード → APIキー → サーバーの鍵・証明書の順。APIキーは新キーで動作確認してから古いキーを消す
痕跡があれば、止める・残す・入れ替える・相談するの順で動く

よくある質問

PHPを更新したら、もう安全ですか？

これからの攻撃は止まりますが、更新前にメモリから漏れたかもしれないパスワードやAPIキー、セッションは残ります。PHP2Shell（CVE-2026-109618）はメモリの中身がPHPSESSIDクッキーに乗って漏れうるため、更新後に秘密を入れ替えておくのが安全側です。

PHP2Shellで攻撃されたか確認する方法はありますか？

2026年10月22日時点で、侵害されたと断定できる方法や公式の侵害痕跡の一覧は公表されていません。手がかりとして挙げられているのは、大きなmultipart/form-dataリクエストの直後のメモリ上限エラーやHTTP 500、異常に長いか形の崩れたPHPSESSIDクッキー、PHPワーカーの説明のつかない異常終了の3つです。

痕跡が見つからなければ、パスワードを変えなくてもよいですか？

メモリの漏えいはアプリのログにほとんど残らないとされているため、見つからないことと漏れていないことは同じではありません。全セッションの無効化、管理者とデータベースのパスワード、外部サービスのAPIキーは、痕跡がなくても替えておくことをおすすめします。

WordPressで全員をログアウトさせるにはどうすればよいですか？

wp-config.phpのセキュリティキー（salt）を新しい値に書き換えると、既存のログイン状態がすべて無効になり、全員が再ログインになります。WordPress公式の生成ページで新しい値を作れます。書き間違えると管理画面が開けなくなるため、作業前にファイルのバックアップを取ってください。

共用のレンタルサーバーを使っていますが、自分で何をすればよいですか？

PHPの更新とサーバー側のログは事業者の管理なので、まず事業者のお知らせで、使っている版に修正が当たったかと、その完了時刻を確かめます。そのうえで、WordPressなどのセッション無効化、管理者パスワード、データベースとFTPのパスワード、外部APIキーの入れ替えは利用者側の作業です。

APIキーを再発行するときの注意点は？

新しいキーを発行し、設定を差し替えて動作を確かめてから、古いキーを無効にする順番で進めます。先に古いキーを消すと、決済やメール通知が止まります。差し替え後は、テスト送信やテスト決済まで通して確認してください。

自社で点検しきれない、保守の担い手が決まっていないなど、PHP2Shell への対応でお困りのことがあれば、お気軽にご相談ください。