PHPを修正版に更新し、PHP-FPMやApacheを再起動した。これで一区切りです。ただ、もう1つ確かめておきたいことがあります。更新する前の時間帯に、すでに侵入されていなかったか、です。
PHPの重大な脆弱性(通称PHP2Shell)では、修正版が出る前日に情報が流れ、公表の4日前の時点ですでに攻撃の試みが観測されていました。更新は今後の侵入を防ぎますが、すでに置かれた裏口までは消してくれません。
手順2と3は、サーバーを自分で管理している方向けです。レンタルサーバーの方は、手順4のWordPressのユーザー一覧と、サーバー会社の改ざん検知やウイルスチェックの結果をまず確かめてください。サイトの管理を制作会社や保守会社に任せている場合は、この記事の確認をその会社に依頼し、PHPのバージョンと、修正版を当てた日時を返事でもらってください。
この記事では、PHPの脆弱性による侵入を確認する順番を、公表されている情報と、一般的な点検の手順に分けてまとめます。10月23日時点の情報です。
先に知っておくこと 「ログに何もない」は安全の証明ではない
最初に、確認の限界を書いておきます。
セキュリティ企業のRapid7は、関連するログ(サーバーが残す動作の記録)が見当たらないことは、そのサーバーが安全である証明にはならない、と書いています。10月23日時点で、PHPの公式発表、CISA、Rapid7、watchTowrの公表情報には、この攻撃に特有の痕跡(IOC)の一覧は載っていません。
つまり、ここから紹介する確認は、侵入されていないことを証明するものではありません。明らかな異常がないかを見て、あれば専門家に相談する、という位置づけです。
1. いつからいつまで、修正前だったかを確かめる
PHPの脆弱性による侵入の確認では、最初に、確認する期間を決めます。そのサーバーで修正前のPHPが動いていたのは、いつまでか。修正版の公開は日本時間10月21日23時ごろですが、自分のサーバーに当てたのが22日の昼なら、そこまでが確認の対象です。
情報が流れたのは20日です。私は、10月17日以降を見ることにしました。Tenableによると、Amazonの脅威情報チームは公表の4日前にあたる17日に悪用の試みを観測しており、調査は少なくとも17日から始めるよう勧めています。
2. PHPのワーカーが、おかしなものを起動していないか
米国のCISAは、注意喚起の中で、PHPのワーカー(リクエストを処理するプログラム)がシェルを起動したり、道具をダウンロードしたりしていないかを監視するよう求めています。シェルは、サーバーに命令を打ち込むための窓口です。
具体的には、PHP-FPMやApacheのプロセス(サーバーの中で動いているプログラムの1つ1つ)の下で、普段は動かないプログラムが動いていないかを見ます。
ps -ef --forest | grep -A3 -E "php-fpm|apache2|httpd"
PHPの下に sh や bash、curl、wget のようなプログラムがぶら下がっていたら、要注意です。
3. 見覚えのないPHPのファイルが増えていないか
ここからは、今回の件に限らない、Webサーバーへの侵入を確かめる一般的な手順です。
侵入した攻撃者は、あとで戻ってこられるように、外から命令を送れるPHPのファイル(Webシェルと呼ばれます)を置いていくことがあります。確認期間に作られたり書き換えられたりしたPHPのファイルを探します。
find /var/www -name "*.php" -newermt "2026-10-17" -ls
/var/www の部分は、サイトのファイルを置いている場所に合わせてください。画像のアップロード用のフォルダにPHPのファイルがあったら、まず怪しいと考えてよいです。
ただし、ファイルの日付は攻撃者が書き換えられるので、この確認で見つからなくても安心はできません。より確かなのは、バックアップや配布元の元のファイルと中身を比べることです。WordPressなら、WP-CLI(WordPressをコマンドで操作する道具)の wp core verify-checksums で、本体のファイルを公式の配布物と比べられます。
4. 管理者のアカウントと、自動で動く設定
続けて、見覚えのない管理者が増えていないか、自動で動く設定が足されていないかを確かめます。
WordPressなら、ユーザーの一覧に知らない管理者がいないか。サーバーなら、定期的に命令を実行するcronの設定や、ログインに使う鍵の一覧に、覚えのないものが増えていないか。どれも、侵入した攻撃者がよく残す足場です。
5. 異常が見つかったら
何か見つかったら、自分で消して終わりにしないでください。消した後も別の裏口が残っていることがあり、どこまで入られたかがわからなくなります。
私の知り合いの会社では、怪しいファイルを見つけた担当者がすぐに消してしまい、その後の調査で侵入の経路が追えなくなりました。まずサーバーをネットワークから切り離し、証拠を残したまま、セキュリティの専門の会社に相談するのが順番です。国内では、JPCERT/CCがインシデント(セキュリティ上の事故)の報告を受け付けています。
サーバーに保存しているパスワードやAPIキー(ほかのサービスと連携するための合言葉)は、侵入の有無にかかわらず、この機会に変えておくと安心です。
確認を終えたら
PHPの脆弱性による侵入の確認で異常がなければ、ひとまず一区切りです。次に同じことが起きたときに備えて、使っているPHPのバージョンの一覧を残しておくことをおすすめします。
PHP2Shellで何が起きたのかの全体像は、こちらにまとめています。
