サイトが侵入されたかもしれないとき｜確認できるログと連絡先

サイトの見た目はいつも通りなのに、なんだか落ち着かない。そんな夜、ありませんか。ニュースでは「侵入」とか「乗っ取り」とか言っているけれど、入られたサイトって、見ただけで分かるものなんでしょうか。私は、何も変わっていない画面を見て、かえってそわそわするほうです。見る場所が山ほどあったら心が折れそうなので、せめて数が少ないことを祈っています。

はじめまして、モノサシ屋のみつきです。ニュースの数字や公式の発表を、読む順番に並べて比べています。

結論｜見るのはログの3項目。見つけたら消さずに契約先へ

最初にやることは1つ、ログで3項目を見ることです。JPCERT/CCが注意喚起で挙げている手がかりは、PHPがログイン状態の管理に使うクッキーの、異常に長い値や形の崩れた値、ファイル送信に使われる形式の不審なリクエスト、リクエストを処理するPHPの担当が予期せず落ちて再起動を繰り返すこと、の3つです。見つけたら、消したり直したりせず、見つけた場所と時刻を控えて契約先のサポートに伝えます。(出典: JPCERT/CC AT-2026-0033)

1. 1ログの3項目を見る
2. 2見つけた場所と時刻を控える
3. 3消さずに契約先のサポートへ伝える

何を探すのか｜この脆弱性で起きうること

PHP2Shellは、認証なしで、外からサーバーでプログラムを動かされうる脆弱性です。php.netは、ログインなしで外から好きなプログラムを動かされること（リモートコード実行）につながりうる2件の重大な脆弱性、と書いています。全体像は、PHP2Shellとはにまとめています。(出典: php.net ニュース（2026年10月21日付）)

侵入された場合に起きうることとして、セキュリティ企業のCrowdStrikeは、次の3つを挙げています。ウェブシェルは、外からサーバーに命令を送るための仕掛けのことです。(出典: CrowdStrike ブログ)

CVE-2026-109618については、Sansecが、単独でサーバーのメモリの中身が漏れうると説明しています。例に挙がっているのは、パスワード、外部サービスとつなぐための鍵（APIキー）、通信の暗号化に使う秘密鍵です。(出典: Sansec)

パッチの適用は、適用後の話です。適用の前の期間に何があったかは、ログに残った記録で見ます。契約先がパッチを適用した日時は、契約先のお知らせに書かれています。

手がかり1と2｜クッキーの値と、不審なリクエスト

3つの手がかりを、探すものとあわせて並べます。(出典: JPCERT/CC AT-2026-0033)

→ 横にスクロールできます

表の3項目のうち、1つ目と2つ目は、契約先で記録されているログの中で探します。何が記録されているかはサーバーによって違うので、記録の範囲も契約先のマニュアルかサポートで確かめます。2つ目の「ファイル送信に使われる形式」は、サイトにファイルを送るときの、リクエストの送り方のことです。

ログの場所と見方は、契約先のマニュアルで探します。見方が分からないときは、契約先のサポートに聞きます。

手がかり3｜PHPの処理担当の落ち方とエラーログの文言

3つ目は、リクエストを処理するPHPの担当が予期せず落ちて、再起動を繰り返していないかです。この担当は、サイトへの1件ずつのアクセスを受け持つPHPのプロセスのことです。

もう1つ、CrowdStrikeのブログは、PHPのエラーログに次の文言が出ることを、悪用の兆候になりうるものとして挙げています。プログラムが動き出す前に失敗していることを示す特徴、という説明です。(出典: CrowdStrike ブログ)

この文言が見つかったときの扱いは、見つけたときの節にまとめます。

ログの外｜見覚えのないファイルと通信

JPCERT/CCは、痕跡が残らない攻撃もありうる、と書いています。解説ブログのsitepickは、ログに痕跡がない場合でも、不審なプロセス、外部への通信、見覚えのないファイルの確認が必要、と整理しています。(出典: JPCERT/CC AT-2026-0033、sitepick)

探し方はサーバーごとに手順が違うので、契約先のサポートに聞くのが近道です。ログで見つけたものも、ここで見つけたものも、伝える先は同じ1か所です。

見つけたとき｜契約先への連絡とパスワードの話

見つけたものがログの記録でも、見覚えのないファイルでも、手順は同じです。消したり直したりする前に、見つけた場所と時刻を控えて、契約先のサポートに伝えます。ログの見方が分からないときも、行き先は契約先のサポートです。

見つけたあとの流れを、順番に並べます。

1. 1

   場所と時刻を控える

   ログの名前、ファイルの場所、記録されていた時刻と文言を、そのまま写します。

2. 2

   契約先のサポートに伝える

   消したり直したりする前に、控えたものを渡します。

3. 3

   パスワードの入れ替えを相談する

   入れ替えるかどうか、どの順番かは、事業者や状況で判断が分かれます。契約先に相談します。

4. 4

   公的機関のページを手元に開く

   JPCERT/CCとIPAの注意喚起のページを、契約先と話すときの一次情報にします。

契約先とは別に、相談や連絡ができる窓口もあります。JPCERT/CCのインシデント対応依頼と、IPAの情報セキュリティ安心相談窓口です。JPCERT/CCは、侵害が疑われる場合に関連するログなどの証拠を保全するよう書いていて、注意喚起の中でこのフォームへ案内しています。IPAの窓口は、ウェブサイトの改ざんや不正アクセスなどの技術的な相談が主な内容とされています。(出典: JPCERT/CC AT-2026-0033、IPA 注意喚起)

入れ替えるパスワードが多くなったときの管理は、パスワード管理ツールは必要かにまとめています。JPCERT/CCとIPAの注意喚起は、それぞれのページで読めます。(出典: JPCERT/CC AT-2026-0033、IPA 注意喚起)

見つからなかったとき｜見た範囲の記録にする

痕跡が残らない攻撃もありうる、とJPCERT/CCは書いています。見つからなかったときは、見た範囲では何もなかった、という記録にします。見た日付、見たログの名前、探した3つの手がかりを、手帳に書いておきます。

国内の各社が出した告知のうち、被害の有無に触れた記載を並べます。

→ 横にスクロールできます

公開前の攻撃については、企業によって観測が分かれています。Cloudflareは、公開前から攻撃トラフィックを観測したと書いています。Impervaは、公開前に該当する攻撃トラフィックは観測しなかったと書いています。(出典: Cloudflare ブログ、Imperva ブログ)

• 2026年10月21日php.netが、修正版を公開する
• 2026年10月22日JPCERT/CCとIPAが注意喚起を出し、JPCERT/CCがログの3項目を載せる
• 2026年10月22日国内の各社が、被害の有無について告知を出す

情報の確認日: 2026年10月23日

まとめ｜ログの3項目を見て、契約先に伝える

侵入のあとではなく、普段の備えを見直すなら、WordPress運営者がまず確認する5つのことに点検の手順があります。