WordPressの管理画面に更新通知が出ているけれど、忙しくて後回しにしている。小さな会社のサイトだから、狙われるわけがない。 ??その判断が、検索順位の消滅と広告アカウントの停止を同時に引き起こすことがあります。 WordPressの脆弱性を放置した場合、実際に何が起きるのか。攻撃者がサイトに侵入してから、ビジネスに実害が出て、復旧に至るまでの流れを段階ごとに解説します。
この記事でわかること
- 攻撃者がまず何をするのか（侵入直後の動き）
- 乗っ取られたサイトがどう「収益化」されるのか
- なぜ被害に気づけないのか
- 検索・広告・メールに出る具体的な実害
- 復旧の難易度を決める要因
- 最低限やるべき4つの対策
先に結論
- 攻撃は人ではなくボットが無差別に行います。企業規模も知名度も関係ありません。
- 侵入後まず設置されるのは「裏口」です。この時点を過ぎると、更新だけでは解決しません。
- 被害は意図的に隠蔽されます。管理者が見ても異常が再現しないよう作られています。
目次
1. 前提：攻撃は「人」ではなく「ボット」が行う
ここを誤解している人が多い
WordPressが標的になりやすい理由
セキュリティ企業Sucuriの調査では、同社が検知したマルウェア感染のうち95.5%がWordPressサイトでした。世界のCMSシェアで圧倒的な首位であることが、そのまま攻撃対象としての量を決めています。 さらに、WordPressはオープンソースでソースコードが公開されています。これは開発の透明性という長所である一方、攻撃者が事前にコードを読み込めることも意味します。
2. 第1段階：侵入と永続化（数秒?数分）
攻撃者が最初にやること
バックドアはどこに仕込まれるのか
- mu-pluginsディレクトリ：ここに置かれたPHPは、管理画面のプラグイン一覧に表示されないまま必ず自動で読み込まれます
- テーマのfunctions.php：難読化されたコードが、既存コードの末尾や中間に紛れ込みます
- アップロードフォルダ内のPHPファイル：画像ファイルを装った名前が使われます
- index.phpやwp-config.phpへの1行挿入：本体ファイルそのものが書き換えられます
Sucuriのレポートによれば、復旧作業を行った侵害サイトの49.21%から、少なくとも1つのバックドアが発見されています。侵害イコール裏口の設置、と考えて差し支えありません。
データベースにも仕込まれる
ファイル側だけではありません。wp_optionsテーブルやwp_postsテーブルにコードが格納され、ファイルを全て削除・再設置しても、DBに残ったコードが再びバックドアを生成するという構成が一般的です。
不正な管理者アカウントの追加
一見それらしい名前の管理者ユーザーが追加されます。ユーザー一覧画面から自分自身を隠す細工がされているケースもあり、管理画面を見ても気づけません。
ここが分岐点です
3. 第2段階：乗っ取ったサイトの収益化
裏口を確保した攻撃者は、そのサイトを資産として運用し始めます。日本の中小企業サイトで実際に多いパターンを挙げます。
SEOスパム（最も多い）
サイト内に大量のスパムページが自動生成され、検索エンジンにインデックスされます。ブランド品の偽サイト、出会い系、オンラインカジノといったキーワードのページが、日本語で大量に生成されるのが典型です。 Sucuriの調査では、リモートスキャンを行ったサイトの42.22%から何らかのSEOスパムが検出されており、なかでも「Japanese SEO spam（日本語キーワードスパム）」は最も多く観測された種類でした。日本語圏のサイトは明確に標的になっています。
条件付きリダイレクト
スマートフォンからのアクセスのみ、あるいは検索流入のみを別サイトへ飛ばす手口です。症状は「なぜか問い合わせが減った」という形で現れます。 原因をサイトの侵害だと疑わないまま、広告費を増やしたり記事を追加したりして、さらに損失を広げてしまうことがあります。
フィッシングサイトのホスティング
銀行やカード会社、宅配業者を装ったページが、正規ドメインの配下に設置されます。この場合、自社は被害者であると同時に、加害の舞台を提供した側になります。
スパムメールの送信踏み台
サーバーから大量のスパムメールが送信されます。自社のドメインとIPアドレスがスパムリストに登録され、通常の業務メールが取引先に届かなくなります。
決済情報の窃取（ECサイトの場合）
決済フォームにスキミングコードが挿入され、入力されたカード情報が外部に送信されます。サイトの見た目も決済の流れも正常に動くため、発覚が遅れがちです。
4. なぜ被害に気づけないのか
クローキングという手法
| アクセス元 | 表示される内容 |
|---|---|
| サイト管理者・社内の人 | 正常なページ |
| 検索エンジンのクローラー | スパムページ |
| 検索結果から来た初回訪問者 | スパムページ・別サイトへ転送 |
つまり、社内の誰がどれだけサイトを見ても、異常はまったく再現しません。 「Googleで検索したら知らないページが出てきた」と外部から指摘されて初めて発覚する、というケースが大半です。取引先や顧客からの連絡で知ることになるわけで、その時点で信用の毀損はすでに始まっています。
5. 第3段階：ビジネスへの実害
技術的な被害より、こちらのほうが回復コストが高くつきます。特に集客をWebに依存している企業ほど打撃が大きくなります。
| 影響先 | 具体的に起きること |
|---|---|
| Google検索 | Safe Browsingによるブラウザ警告（赤い全画面警告）。サーチコンソールに手動対策が適用され、順位下落またはインデックス削除 |
| Google広告 | 「望ましくないソフトウェア」等のポリシー違反でアカウント停止。広告配信が即座に止まる |
| メール | ドメイン・IPがスパムリストに登録され、見積書や請求書が相手に届かなくなる |
| サーバー | レンタルサーバー側が規約違反としてアカウントを緊急停止。サイトもメールも同時に止まる |
| 取引先・顧客 | 「サイトを開いたら警告が出た」という連絡。信頼の毀損 |
| 法務 | 顧客情報の漏えいが確認された場合、個人情報保護委員会への報告と本人通知の義務が生じ得る |
最悪の組み合わせ
6. 第4段階：復旧の現実
侵害が確定した場合、作業は「更新」ではなく「再構築」に近くなります。
復旧の基本手順
- サイトを一時停止し、被害の拡大を止める
- 侵害前のバックアップから復元
- 使えない場合は本体・テーマ・プラグインをすべて公式配布物で置き換え
- 全ユーザーのパスワード変更、不正アカウント削除、ソルトキー再発行
- FTP・データベースのパスワードも変更
- サーチコンソールへ再審査リクエスト、広告アカウントの再審査申請
- 再発防止策の実装
バックアップが運命を決める
注意すべきは、侵害後のバックアップには裏口が含まれているという点です。感染に気づかないまま復元すると、裏口ごと復活させることになります。 つまり必要なのは「最新のバックアップ」ではなく、「侵害される前のバックアップ」です。 ここで発見の遅れが効いてきます。
| 発見までの期間 | 状況 |
|---|---|
| 数日 | 侵害前のバックアップが残っている可能性が高い。比較的短時間で復旧可能 |
| 数週間 | 世代管理の保持期間を超えている可能性。判断が難しくなる |
| 数か月 | クリーンなバックアップが存在しない。手作業での駆除か、サイトの作り直し |
前章のクローキングを思い出してください。気づくのが遅れる設計になっている以上、「異常に気づいてから対処する」という運用は、そもそも成立しにくいのです。
費用の目安
専門業者に駆除を依頼した場合、規模と被害状況によりますが数万円?数十万円が一般的な水準です。そこに停止期間中の機会損失、検索順位が回復するまでの流入減、広告停止期間の損失、取引先への説明対応の工数が加わります。
7. ケーススタディ：wp2shellが示したこと
2026年7月に公表されたWordPressコアの脆弱性「wp2shell」は、放置のリスクを具体的に示した事例です。 この脆弱性は、REST APIのバッチ処理におけるルート混同（CVE-2026-63030、CVSS 9.8）とSQLインジェクション（CVE-2026-60137、CVSS 7.5）を連鎖させることで、未認証のまま任意のPHPコードをサーバー上で実行できるというものでした。
なぜ特に悪質だったのか
- プラグインもテーマも関係ない：素のWordPressでも成立するため「プラグインを厳選しているから安全」が効かない
- 未認証で成立：管理画面URLの変更も、ログイン試行制限も、二段階認証もすり抜ける
- 旧バージョンにも影響：修正は旧ブランチにもバックポートされた＝古いまま止めていたサイトも対象
- 修正版公開の翌日にはPoCが流通：実証コードが出回り、無差別攻撃に移行
攻撃側の「待ち時間」はもう無い
この脆弱性は、セキュリティ研究者がLLMエージェントに最新のWordPressソースコードを監査させ、約10時間・モデル利用料およそ25ドルで発見されたものでした。 さらにPatchstackの年次レポートによれば、深刻度の高い脆弱性が公表されてから大規模な悪用が観測されるまでの加重中央値は5時間です。
8. 放置しないために：最低限やるべき4つ
長々と被害の話をしましたが、防ぐ側でやることはシンプルです。
この4つで大半は防げます
- セキュリティリリースの自動更新をONにする
- バックアップを自動化し、復元できることを確認する
- WAFを有効にする
- ファイル改ざんを検知できるようにする
1. セキュリティリリースの自動更新をONにする
WordPress本体のマイナーリリース（セキュリティ更新）は自動適用に設定します。人間の確認を待つ数日のほうが、自動更新の不具合リスクより大きいというのが現在の力関係です。
2. バックアップを自動化し、復元テストをする
自動更新の前提条件です。加えて、一度は実際に復元テストをしてください。取れているつもりのバックアップが壊れていた、というのは珍しい話ではありません。
3. WAFを有効にする
公式パッチが出るまでの数時間を凌ぐ層です。多くのレンタルサーバーが標準で提供しているので、まず有効化されているか確認してください。セキュリティプラグインによる仮想パッチも選択肢です。
4. ファイル改ざんを検知できるようにする
侵害に「気づける」仕組みです。クローキングで隠蔽されても、ファイルの変更は検知できます。wp-config.phpに管理画面からのコード編集を禁止する設定を追加しておくのも有効です。
9. よくある質問
小規模なサイトでも本当に狙われますか？
狙われます。攻撃はボットによる無差別スキャンで行われるため、サイトの規模や知名度は判定基準に入っていません。むしろ管理体制が手薄な小規模サイトのほうが、成立しやすい対象になります。
更新すれば、すでに入られていても大丈夫ですか？
いいえ。更新で塞がるのは入口だけで、すでに設置されたバックドアは残ります。侵害の疑いがある場合は、更新とは別に駆除作業が必要です。
侵害されているかどうか、自分で確認できますか？
ある程度は可能です。サイト名で検索して身に覚えのないページが出ていないか、サーチコンソールにセキュリティの問題が出ていないか、管理者ユーザーが増えていないかを確認してください。ただしクローキングされている場合は表面上わからないため、確実性を求めるなら専用のスキャンが必要です。
WordPress以外のCMSなら安全ですか？
シェアが小さいぶん無差別攻撃の対象量は減りますが、脆弱性を放置すれば同じことが起きます。CMSの選択より、更新とバックアップの運用体制のほうが結果を左右します。
10. まとめ
まとめ
- 侵入は自動化されたボットが行う??規模も業種も関係なく機械的に処理される
- 最初に設置されるのは裏口??この時点を過ぎると更新だけでは解決しない
- 被害は隠蔽される??社内の誰が見ても異常が再現しないよう作られている
- 実害は集客に出る??ブラウザ警告、順位消滅、広告停止が同時に来る
- 復旧可否はバックアップが決める??発見が遅れるほど使えるバックアップが消える
参考リンク
- Sucuri：2023 Hacked Website & Malware Threat Report
- Patchstack：State of WordPress Security in 2026
- Searchlight Cyber：wp2shell 研究記事
- CyberInsider：wp2shell の悪用状況
- The Register：wp2shell を狙った攻撃の観測
- WordPress.org：公式リリース情報
- WordPress公式：サイトヘルス画面の解説
- Security NEXT：セキュリティ関連ニュース
※本記事内の統計数値は上記出典に基づく調査データです。Sucuriのデータは同社顧客およびSiteCheckスキャンに基づく母集団であり、WordPress全体の母集団とは異なります。駆除費用の目安は一般的な相場感であり、実際の金額は被害状況・サイト規模・依頼先によって変動します。個人情報保護法上の報告義務については、対象となる事態の範囲や報告期限に条件があるため、実際の判断は個人情報保護委員会のガイドラインをご確認ください。CVE情報およびバージョン番号は執筆時点のものです。