WordPressサイトの脆弱性診断が必要だとわかっていても、「何をどこまでやればいいのか」が見えず手が止まっている担当者は少なくありません。本記事では、WordPress公式の「Hardening WordPress」ガイドとIPAの公開資料をもとに、自社サイトの対策状況を確認できる18項目のセルフチェックリストを掲載しています。
チェックリストで基本対策の現状を把握したうえで、自社対応だけではカバーしきれないケースの見極め方も整理しました。
専門的な診断が必要と判断された場合には、ユービーセキュアのWebアプリケーション診断への無料相談も次のステップとしてご活用ください。
※ 参照：WordPress の安全性を高める — WordPress.org日本語版 安全なウェブサイトの運用管理に向けての20ヶ条 — IPA
WordPressサイトが攻撃者に狙われやすい２つの理由
セルフチェックに入る前に、WordPressが攻撃対象として選ばれやすい構造的な背景を押さえておきましょう。理由を知っておくと、各チェック項目の優先度を判断しやすくなります。
世界シェアが高いオープンソースCMSであること
WordPressは世界のWebサイトの約43%で利用されており（W3Techs調査、2026年時点）、CMSとしては最大シェアを占めています。さらにオープンソースであるためソースコードが公開されており、攻撃者は1つの脆弱性を発見すれば膨大な数のサイトに同じ手口を適用できます。費用対効果の高さが、WordPressが標的になりやすい最大の理由です。
ここで注意したいのが、攻撃の多くは特定のサイトを狙い撃ちするのではなく、ボットによって機械的に行われている点です。攻撃者はクローラーで脆弱性のあるサイトを自動的に探し出し、条件に合致したサイトへ一斉に攻撃を仕掛けます。つまり、サイトの規模や知名度に関係なく、WordPressを使っているというだけで攻撃の候補リストに自動的に含まれてしまいます。「うちは小さいサイトだから狙われない」という前提は通用しないと考えるべきです。
ただしオープンソースであることは弱点ばかりではありません。世界中の開発者が脆弱性を発見・修正するサイクルが機能しているため、アップデートを適切に適用していればコード公開がそのまま弱点になるわけではない点は押さえておきたいポイントです。
プラグイン・テーマが主要な攻撃経路になっている
IPAの「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」によると、JVN iPediaに登録されたCMS関連の脆弱性は、本体よりも拡張機能（プラグイン）に起因するものがそのほとんどを占めると報告されています。WordPress公式ガイドでも、プラグインやテーマは公式リポジトリや信頼できる企業からのみ取得するよう明記されています。本体には自動更新の仕組みがありますが、プラグインやテーマの更新は各開発者の対応次第であり、メンテナンスが止まったまま放置されているケースが攻撃者の狙い目になっています。
さらに見落とされがちなのが、プラグインの「買収」によるリスクです。これまで信頼して使ってきたプラグインでも、開発者が変わったことを契機に悪意あるコードが仕込まれるケースが過去に報告されています。利用者から見れば同じ名前のプラグインを更新しているだけですが、その更新によって攻撃者に主導権を渡してしまう構造です。導入時の信頼性だけでなく、運用中も提供元の動向や更新内容を確認する姿勢が求められます。
※ 参照：CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント — IPA
WordPress脆弱性セルフチェックリスト18項目
WordPress公式「Hardening WordPress」とIPAの公開資料から、WordPress運用者が確認すべき項目を18個に整理しました。まずは一覧を見ながら、自社サイトで対応済みの項目を数えてみてください。
チェックリスト一覧
WordPress本体・更新管理
□ WordPress本体を最新バージョンに更新しているか
□ 自動更新機能を有効にしているか
□ PHPのバージョンがサポート対象か
□ プラグイン・テーマをすべて最新版に保っているか
アクセス制御・認証
□ 管理者アカウント名が「admin」「webmaster」のままになっていないか
□ 強固なパスワード＋二段階認証を導入しているか
□ 不要なユーザーアカウントを削除しているか
□ データベースユーザーの権限を必要最小限に絞っているか
ファイル・サーバー設定
□ wp-config.phpへの外部アクセスを遮断しているか
□ 管理画面からのファイル編集を無効化しているか
□ ファイルパーミッションを適切に設定しているか（ディレクトリ755／ファイル644）
□ FTP接続にSFTPを使用しているか
プラグイン・テーマ管理
□ 未使用のプラグイン・テーマを「無効化」ではなく「削除」しているか
□ 公式リポジトリまたは信頼できる提供元からのみ取得しているか
□ 脆弱性情報をJVN iPediaやWPScan DBで定期確認しているか
通信・監視・バックアップ
□ サイト全体をHTTPS化しているか
□ WAF（Web Application Firewall）を導入しているか
□ 定期的なバックアップを外部保存先に取得しているか
チェック結果の活かし方：未対応なら特に危険な項目を知る
すべての項目に一度に対応する必要はありませんが、未対応のまま放置すると被害に直結しやすい項目は存在します。以下は、WordPress公式ガイドやIPAの資料で具体的に危険性が指摘されている項目です。チェックリストと照らし合わせて、もし未対応であれば最優先で対処してください。なお、各項目の具体的な対策手順は次章の「カテゴリ別の対策ポイント解説」で詳しく取り上げます。
WordPress本体・プラグインが最新版でない
WordPress公式ガイドでは、古いバージョンにはセキュリティ更新が提供されず、脆弱性を悪用するための情報がほぼ確実に公開されると警告しています。特に、開発者によるサポートが終了（EOL：End of Life）したバージョンは、新たに発見された脆弱性に対して修正プログラムが今後も提供されません。動作しているからといって使い続けることは、修正されない欠陥を抱えたまま運用することと同義です。放置期間が長いほどリスクは増大します。
管理者アカウント名がadminのまま
ブルートフォース攻撃で最初に試行されるアカウント名であり、未対応のままだと侵入リスクが大きく上がります。変更の手間に対して効果が大きい対策なので、早期に対処すべき項目です。
wp-config.phpが外部からアクセス可能
データベースの接続情報が格納されたファイルのため、この1項目が未対応なだけで致命的な情報漏えいにつながりえます。
未使用プラグインを「無効化」のまま残している
無効化状態でもファイルがサーバー上に残るため、脆弱性が公表された際に攻撃対象になります。
なお、このチェックリストはあくまで基本対策の実施状況を確認するためのものです。IPAの「ウェブ健康診断仕様」でも、簡易診断で問題が見つからなかった場合でも安全宣言にはつながらないと明記されています。SQLインジェクションやクロスサイトスクリプティングといったアプリケーション層の脆弱性は、このチェックリストの範囲外であり、別途専門的な診断が必要です。
※ 参照：安全なウェブサイトの作り方（ウェブ健康診断仕様） — IPA
カテゴリ別の対策ポイント解説
チェックリストの各カテゴリについて、対応時に押さえておくべきポイントを補足します。
WordPress本体・更新管理
古いバージョンを放置すると、脆弱性の悪用情報が公開されたまま無防備になる状態が生まれます。本体・PHPの両方について、サポート対象のバージョンに保つことが基本方針です。具体的には次のポイントを押さえてください。
本体の自動更新は範囲を理解して使うWordPress 3.7以降では、セキュリティリリース（マイナーアップデート）の自動更新が標準で有効化されています。ただしメジャーアップデートやプラグイン・テーマの自動更新は別途設定が必要なため、管理画面から有効化しておくとパッチ適用漏れを抑えられます。
PHPのバージョン管理はサーバー側で対応するサポート切れのPHPは、脆弱性が放置されたままの状態を意味します。IPAの20ヶ条（第9条）でも言及されている通り、サーバー側のバージョンも棚卸しの対象です。バージョンアップは互換性への懸念から後回しにされがちですが、PHP 8系では7系と比較して処理速度の向上が公式に報告されており、セキュリティ強化と表示速度の改善を同時に達成できる施策として捉え直すと優先度を上げやすくなります。
アクセス制御・認証
不正ログインの侵入経路を塞ぐカテゴリです。WordPress公式ガイドでは、管理者アカウント名に「admin」や「webmaster」を使わないよう具体的に名指しで警告しています。これらはブルートフォース攻撃で真っ先に試行されるアカウント名であり、ユーザー名の変更だけでも攻撃成功率を大幅に下げられます。本体側の設定だけでなく、認証の多層化やデータベース権限まで含めて確認してください。
二段階認証＋ログイン試行回数制限を組み合わせるブルートフォース攻撃への有効な対策として、WordPress公式ガイドでは二段階認証の導入が推奨されています。二段階認証の導入が業務上難しい環境では、ログイン試行回数の制限が現実的な代替策になります。一定回数連続で認証に失敗したIPアドレスを一時的にブロックする仕組みで、専用プラグインの導入で比較的容易に実装できます。総当たりでパスワードを試す攻撃に対しては、回数制限だけでも攻撃の成立確率を大きく下げられるため、二段階認証と並んで優先度の高い対策です。
データベースユーザーの権限を絞る見落としがちなのがデータベースユーザーの権限です。公式ガイドでは、DROPやALTERなど通常運用に不要な権限を剥奪する方法まで解説されています。万が一WordPress経由で侵入された場合の被害範囲を限定するための重要な設定です。
ファイル・サーバー設定
wp-config.phpにはデータベース接続情報が含まれており、外部からアクセスできる状態は深刻なリスクです。WordPress公式ガイドでは.htaccessによるアクセス制限のコード例が示されているので、未対応の場合は最優先で適用してください。管理画面からのファイル編集についても、wp-config.phpにdefine('DISALLOW_FILE_EDIT', true);を追記して無効化することが推奨されています。ファイルパーミッションはディレクトリ755、ファイル644が一般的な推奨値とされていますが、共有サーバー環境ではより厳格な設定（ディレクトリ750、ファイル640など）が推奨されるケースもあるため、利用環境に応じて調整してください。
プラグイン・テーマ管理
WordPress公式ガイドでは、使用していないプラグインは「無効化」ではなく「削除」するよう求めています。無効化しただけではファイルがサーバー上に残り、脆弱性を突かれるリスクが消えないためです。IPAのCMS対策レポートでも拡張機能の定期的な見直しがポイントに挙げられており、JVN iPediaやWPScan Vulnerability Databaseでの情報収集を運用ルールに組み込むことが重要です。
通信・監視・バックアップ
HTTPS化はWordPress公式・IPAの双方で求められている基本対策です。WAFについて、WordPress公式ガイドではプラグイン型・サーバー型・クラウド型の3種類が紹介されており、自社の環境に合った方式を選択できます。バックアップの保存先はサーバーと同じ場所ではなくクラウドストレージなど外部に分離しておくことで、サーバー自体が侵害された際の復旧手段を確保できます。
セルフチェックだけでは見えないリスク：専門家に相談すべき4つのケース
セルフチェックで基本対策の現状は把握できますが、それだけではカバーしきれない領域があります。特に以下の4つのケースに該当する場合、セキュリティ専門家による脆弱性診断の実施を検討すべきです。
ECサイトや会員サイトなど個人情報を扱っている場合
経済産業省とIPAが2023年3月に共同公開した「ECサイト構築・運用セキュリティガイドライン」では、ECサイトの構築時・運用時の両方で脆弱性診断の実施が求められています。同ガイドラインの基となったIPA調査では、被害を受けたECサイトの75%がCMSやECサイト構築プログラムの脆弱性を放置していたことが報告されており、CMS環境のセキュリティ対策が不十分なまま個人情報を扱うリスクの大きさがうかがえます。クレジットカード情報や会員データを扱うサイトでは、漏えい時の損害賠償や個人情報保護法上の報告義務など、ビジネスインパクトが大きく、該当するサイトを運営している場合はセルフチェックに加えた専門診断の優先度が高いといえます。
※ 参照：ECサイト構築・運用セキュリティガイドライン — IPA
独自開発のプラグインやテーマを使用している場合
公式リポジトリ経由のプラグインであれば脆弱性情報がJVN iPediaやWPScan DBに掲載されますが、自社やベンダーが独自に開発したコードにはこの仕組みが機能しません。SQLインジェクションやクロスサイトスクリプティングが潜んでいないかは、コードレビューまたは脆弱性診断でしか確認できないため、開発ベンダーとは別の第三者の目で検証する意義があります。
セキュリティ専任担当者がいない場合
IPAのCMS対策レポートでは、アップデートや拡張機能の管理が「実施者不在」のまま放置されがちな実態が指摘されています。兼任担当者が脆弱性情報の収集から対処まで継続的に回すのは現実的に難しく、こうした状況では外部の定期診断サービスを活用する選択肢が有効です。ユービーセキュアのWebアプリケーション診断は、スポットの診断に留まらず、継続的な診断スキームや診断の内製化支援にも対応しており、中長期的な運用設計まで含めた相談が可能です。
過去にセキュリティインシデントが発生したことがある場合
WordPress公式ガイドのMonitoringセクションでも、侵害後のファイル改ざん痕跡の検知とフォレンジックの重要性が解説されています。一度攻撃を受けたサイトにはバックドアが設置されていたり、特定の条件で発動するマルウェアが巧妙に隠されているケースが多々あります。表面的なパスワード変更やファイル上書きだけでは対策として不十分です。専門的なフォレンジック調査で根本原因を特定し、再発防止策を講じることが不可欠です。
まとめ：公式情報をベースに自社の対策状況を棚卸しし、次のアクションを決める
WordPressの脆弱性対策は、本記事の18項目チェックリストで自社の現状を棚卸しし、未対応項目（特に公式ガイドで危険性が指摘されているもの）から優先的に着手するのが第一歩です。
一方で、チェックリストではカバーしきれないアプリケーション層の脆弱性もあります。ECサイトや独自開発コードを扱っている場合、専任担当者がいない環境では、外部の専門家による診断が現実的な選択肢です。ユービーセキュアのWebアプリケーション診断では、対象システムの特性を踏まえた診断プランを無料相談からご提案しています。
脆弱性を放置するコストと診断にかかるコストを比較すれば、早い段階で現状を把握しておくことが最もリスクを下げる判断になるはずです。
