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