WordPressは利用者が多く、攻撃の手口も広く共有されているため、規模の大小を問わず狙われやすいCMSです。実際にWP復旧本舗の復旧相談でも、企業サイト、店舗サイト、個人ブログを問わず、更新不足や認証管理の甘さを起点に感染しているケースが繰り返し見られます。

重要なのは、マルウェア感染の多くが特殊なゼロデイ攻撃ではなく、基本的な運用のほころびから起きるという点です。本記事では、復旧現場でよくある原因を整理し、感染を防ぐために優先して実施したい対策と、万一感染したときの初動をまとめます。

1. 信頼性の低いプラグインやテーマの使用

どこで感染につながるのか

非公式サイトで配布されているテーマやプラグイン、いわゆる nulled 版は典型的な感染経路です。見た目は正常でも、管理者権限を奪うためのバックドア、外部サイトへのリダイレクト、スパム配信の仕組みなどが埋め込まれていることがあります。

復旧現場では、「有料製品を無料で使える配布物を入れた」「制作時に入れた拡張機能の出所が追えない」「使っていない古いテーマが残っていた」といった状態から不正コードが見つかることが少なくありません。無効化しているだけではファイル自体は残るため、脆弱性や不正コードの温床になります。

対策

導入元は WordPress公式ディレクトリ、公式サイト、実績が確認できる開発元に限定します。あわせて、現在使っていないプラグインやテーマは停止ではなく削除まで行い、保守対象を減らしてください。

選定時は次の点を確認すると判断しやすくなります。

  • 最終更新日が極端に古くないか
  • 最新のWordPressで動作確認されているか
  • サポート状況やレビューに問題が出ていないか
  • 同じ機能の拡張機能を重複導入していないか
  • 開発元や配布元を社内で説明できるか

2. WordPress本体や拡張機能の更新不足

なぜ更新不足が危険なのか

WordPress本体、プラグイン、テーマには継続的に修正が入ります。攻撃者は、公開済みの脆弱性情報や更新差分をもとに古いバージョンを狙うため、更新を止めた状態はそれだけで攻撃面を広げます。

ここで重要なのは、特定の製品名やCVE番号を追いかけることではなく、脆弱性の種類を理解しておくことです。実際には次のような問題が感染や侵害の入口になります。

  • 権限昇格: 本来できない操作を一般ユーザーが実行できる
  • 任意ファイルアップロード: 悪意あるファイルをサーバーへ置かれる
  • SQLインジェクション: データベース情報を不正に参照・改ざんされる
  • クロスサイトリクエストフォージェリ（CSRF）: 管理者の操作を悪用される
  • 認証回避: ログインや権限チェックを迂回される

WP復旧本舗でも、感染後に調査すると「数か月以上アップデートされていなかった」「使っていない古いプラグインが残っていた」という状態はよく見つかります。更新の遅れは、それだけで復旧難易度を上げる要因です。

対策

更新通知を放置せず、WordPress本体と拡張機能を計画的に保守します。理想は、更新前にバックアップを取得し、可能であればステージング環境で表示と主要機能を確認してから本番へ反映する運用です。

小規模サイトでも、次の流れを定例化すると事故を減らせます。

  1. 変更前にファイルとデータベースをバックアップする
  2. 更新内容と互換性情報を確認する
  3. ステージング、またはアクセスが少ない時間帯で更新する
  4. フォーム、決済、会員機能など重要導線を確認する
  5. 不要な拡張機能を同時に棚卸しする

自動更新の設定例

// wp-config.php
define( 'WP_AUTO_UPDATE_CORE', true );

// wp-content/mu-plugins/auto-updates.php など、must-use plugin（mu-plugins）に配置する
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

これらのフィルタは functions.php でも書けますが、テーマやプラグインが読み込まれる前の早い段階で確実に効かせたい設定のため、WordPress公式は must-use plugin（wp-content/mu-plugins/）への配置を案内しています。functions.php や wp-config.php に直接書くと、実行タイミングや有効化中テーマへの依存が問題になることがあります。

自動更新は有効ですが、業務サイトでは「何を自動化し、何を手動確認するか」を決めておくことが重要です。更新そのものより、更新後の確認体制がないことのほうが実務上のリスクになりやすいからです。

3. 弱いパスワードと認証管理の甘さ

よくある侵入口

WordPressの管理画面は、推測されやすいIDや使い回しパスワードが残っていると、不正ログインの対象になります。これは大規模サイトだけの話ではなく、一般公開されたログインURLに対して自動的に試行される攻撃が中心です。

復旧相談では、管理者名が初期状態のまま、複数人で同じアカウントを共有、退職者アカウントが残存、他サービスと同じパスワードを流用、といった運用上の問題が感染の背景にあることが珍しくありません。サイト自体ではなく、管理者PCのマルウェア感染やフィッシングを起点に認証情報が漏れることもあります。

対策

まず、管理者権限のアカウントを最小限にし、各担当者に個別アカウントを割り当てます。パスワードは長くランダムなものを使い、使い回しを避けてください。加えて、二要素認証を導入し、ログイン試行制限や通知機能を有効にすると防御層が厚くなります。

見直しポイントは次のとおりです。

  • admin など推測しやすいユーザー名を避ける
  • パスワードマネージャーで長いランダム文字列を管理する
  • 2FA を導入する
  • 不要アカウント、共有アカウントをなくす
  • FTP、サーバーパネル、データベースの認証情報も同じ基準で管理する

2FA導入の目安

WordPress標準だけで十分とは言えないため、認証強化はプラグインやホスティング側機能の利用を前提に考えるのが現実的です。導入後は、バックアップコードの保管場所と、担当者変更時の引き継ぎ方法まで決めておく必要があります。

4. ファイルアップロード機能の悪用

起きやすい問題

問い合わせフォーム、会員投稿、求人応募、画像投稿など、アップロード機能を持つページは侵入口になりえます。検証が甘いと、画像やPDFを装った不正ファイルを置かれ、そこからWebシェルを実行されることがあります。

アップロード機能を悪用した侵害では、拡張子の偽装、MIMEタイプの偽装、二重拡張子、公開ディレクトリへの直接配置など、複数の要因が重なります。単に「画像だけ許可しているつもり」では不十分で、実行させない設計まで含めて対策する必要があります。

対策

基本は、許可するファイル形式を必要最小限に絞り、サーバー側で検証し、アップロード先でスクリプトを実行させないことです。アップロード機能が本当に必要かを見直すことも有効です。

MIME制限の例

// functions.php
function restrict_mime_types( $mimes ) {
    return array(
        'jpg|jpeg|jpe' => 'image/jpeg',
        'png'          => 'image/png',
        'gif'          => 'image/gif',
        'pdf'          => 'application/pdf',
        'doc'          => 'application/msword',
        'docx'         => 'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
    );
}
add_filter( 'upload_mimes', 'restrict_mime_types', 1, 1 );

function sanitize_file_uploads( $filename ) {
    $filename = remove_accents( $filename );
    $filename = preg_replace( '/[^a-zA-Z0-9._-]/', '', $filename );
    return strtolower( $filename );
}
add_filter( 'sanitize_file_name', 'sanitize_file_uploads', 10 );

ただし upload_mimes による制限は「許可する拡張子とMIMEタイプの一覧を絞り込む」ものであり、これ単体では完全な検証になりません。拡張子と中身が一致しない偽装ファイルを防ぐには、WordPress の wp_check_filetype_and_ext() による実ファイル型の確認や、後述のようにアップロード先でスクリプトを実行させない設定と必ず併用してください。

.htaccess による実行防止

# /wp-content/uploads/.htaccess
<FilesMatch "\.(php|php3|php4|php5|phtml|phar|pl|py|jsp|asp|sh|cgi)$">
    Require all denied
</FilesMatch>

Options -ExecCGI

この .htaccess による制御は Apache 系サーバー向けで、しかも AllowOverride が有効な場合にのみ読み込まれます。Nginx などでは .htaccess 自体が使われないため無効で、サーバー設定（location ブロックでの拡張子拒否や実行禁止など）で等価の対策を行う必要があります。反映後はアップロード機能と画像表示が正常に動くかを必ず確認してください。

5. その他の基本対策

SSL化（HTTPS）

管理画面やフォームの通信を保護するため、常時SSLは前提と考えてください。未対応のまま運用すると、認証情報や入力データの保護という基本条件を欠きます。

ファイル権限の適正化

書き込み権限が広すぎると、侵害後の改ざん範囲が広がります。WordPress公式ドキュメントの考え方に沿って、必要以上の権限を与えないことが重要です。

# ディレクトリ
find /path/to/wordpress -type d -exec chmod 755 {} \;

# ファイル
find /path/to/wordpress -type f -exec chmod 644 {} \;

# 重要ファイル
chmod 400 wp-config.php   # 400 または 440 が公式寄り

上記の 755 / 644 は WordPress公式が示す一例で、最適な値はホスティング環境（実行ユーザーやグループ構成）によって変わる目安です。一律に適用すればよいわけではなく、サーバーの推奨値を優先してください。wp-config.php は公式マニュアルでも通常 400 または 440 が案内されています。.htaccess についてはパーマリンク変更時などに WordPress 側からの書き込みが必要になる場合があるため、固定の権限値を断定せず、自動リライトルール生成が必要なら書き込み可能であること（環境依存）に注意してください。

wp-content 配下を一律で書き込み可能に広げる運用は避け、必要な範囲だけを見直してください。ホスティング環境によって推奨値が異なるため、公式マニュアルも確認が必要です。

セキュリティプラグインとサーバー防御

セキュリティプラグインは有効ですが、入れれば安全になるわけではありません。WAF、マルウェアスキャン、ログイン保護、変更検知など、何を補いたいかを決めて最小限で構成するほうが安定します。サーバー側でWAFや不正アクセス対策が提供されている場合は、WordPress側と役割分担を明確にしてください。

バックアップ運用

感染対応では「バックアップがある」だけでは足りません。いつの時点のバックアップか、復元できるか、感染前の世代が残っているかまで確認できてはじめて意味があります。

最低限、次の運用をおすすめします。

  • データベースは高頻度で取得する
  • ファイル一式も定期取得する
  • 更新前に手動バックアップを追加で取る
  • 保存先をサーバー外にも持つ
  • 復元テストを定期的に実施する

マルウェア感染時の緊急対応手順

感染が疑われるときは、見た目だけを直して公開を続けるのが最も危険です。リダイレクト、スパムページ生成、不審な管理者追加、サーバー会社からの警告、Search Console のセキュリティ警告などが出た場合は、まず被害拡大を止める判断が必要です。

初動で優先すること

  1. サイト公開を一時停止し、これ以上の被害拡大を防ぐ
  2. WordPress、FTP、サーバーパネル、データベースの認証情報を変更する
  3. 直近のバックアップとログを保全する
  4. 感染範囲を調査し、改ざんファイルと不正ユーザーを確認する
  5. 原因を塞いでから復旧する

復旧時の注意点

復旧でよくある失敗は、改ざんファイルだけを削除して原因を残すことです。これでは数日後に再感染することがあります。テーマやプラグインの再設置、不要ユーザー削除、パスワード総入れ替え、脆弱な設定の是正まで実施して、はじめて復旧完了と判断できます。

自力対応が難しい場合は、早い段階で専門業者へ相談したほうが結果的に被害を抑えやすくなります。特にECサイト、会員サイト、問い合わせが事業に直結するサイトでは、初動の遅れが売上や信用の損失につながります。WP復旧本舗のマルウェア・改ざんの障害復旧サービスは ¥49,500・成果報酬制（復旧できなければ全額返金）で、感染ファイルの特定・駆除からGoogle警告の解除申請まで対応します。依頼時に伝える情報は復旧依頼テンプレートにまとめています。

なお、症状が「画面が真っ白」「このサイトで重大なエラーが発生しました」の形で出ている場合は、真っ白画面（WSOD）の対処法や「重大なエラー」の対処法もあわせて確認してください。

まとめ

WordPressのマルウェア感染は、派手な攻撃よりも、更新不足、認証管理の甘さ、出所不明の拡張機能、アップロード機能の不備といった基本要因から起こることがほとんどです。WP復旧本舗の復旧現場でも、この4点を丁寧に見直すだけで防げたと考えられるケースは少なくありません。

優先順位としては、まず更新管理、管理者認証、不要プラグインの削除、バックアップ運用の整備です。感染後の対応より、平時の運用を整えるほうがコストも影響も小さく済みます。少しでも不審な挙動があれば、そのまま運用を続けず、原因調査と復旧を先に行ってください。

参考資料：

  • Sucuri Website Threat Report
  • WordPress Developer Resources
  • WordPress.org Hardening WordPress
  • WPScan Vulnerability Database
  • OWASP Top 10