WordPressの脆弱性によるリスクとは?チェック方法と対策

WordPressはオープンソース型のCMSであり、自由度が高くカスタマイズ性に優れているのが特徴です。世界でもっとも利用されているCMSで、多様なWebサイトを設計できます。
しかしオープンソース型は構成システムが公開されているため、悪意のある攻撃者にも狙われやすく、過去には脆弱性が原因によるネット攻撃の事例もあります。
そこで本記事では、WordPressの脆弱性について詳しく解説し、Webマーケティングの担当者でも始められるセキュリティ対策方法を解説します。
■毎週の自動脆弱性診断と迅速なアップデートで安心のセキュリティ!WordPressから乗り換えも多数
>ferret Oneサービス紹介資料のダウンロード【無料】はこちら
目次[非表示]
- 1.WordPressの脆弱性によるリスク
- 2.【2026年7月最新】WordPress本体の脆弱性「wp2shell」とは
- 3.なぜWordPressは脆弱性が狙われやすいのか
- 4.WordPressの脆弱性を突く代表的な攻撃
- 5.WordPressサイトに脆弱性がないか調べる方法
- 6.WordPressの脆弱性から守る11つの対策
- 7.WordPressサイトが攻撃を受けた場合の対処法
- 8.WordPressのセキュリティ運用が不安なら、クラウド型CMSも選択肢
- 9.WordPressのセキュリティ懸念からの乗り換えも多数のCMS「ferret CMS」
- 10.まとめ|WordPressの安全な運用には、継続的な保守体制が欠かせない
WordPressの脆弱性によるリスク

世界で最も利用されているCMSであるWordPressは、その普及率ゆえに常にサイバー攻撃の標的となっています。
独立行政法人情報処理推進機構(IPA)が2026年1月に発表した「情報セキュリティ10大脅威 2026」においても、「システムの脆弱性を突いた攻撃」は組織にとって回避できない重大な脅威として上位にランクインし続けています。
特に近年では、以下のような「攻撃の高度化・高速化」が顕著です。
ゼロデイ攻撃の増加:修正プログラムが公開される前の隙を突く攻撃が常態化しています。
AIによる攻撃の自動化:2026年版で新たにランクインした「AIの利用をめぐるサイバーリスク」に関連し、脆弱性を探す作業や攻撃メールの作成にAIが使われ、攻撃の頻度と精度が飛躍的に高まっています。
攻撃までのタイムラグ短縮:脆弱性が公表されてから攻撃が始まるまでの時間は、いまや「数日」ではなく「数時間」単位になっています。
企業サイトが一度でも不正アクセスを受ければ、サイト改ざんによるウイルス配布や個人情報の漏洩を招き、信用の失墜だけでなく多額の損害賠償に発展する恐れがあります。「うちは大丈夫」という過信を捨て、最新の脅威に基づいた「攻めの防御」を行うことが、現代のWeb担当者には求められています。
WordPressのセキュリティ対策については「WordPressのセキュリティ対策と脆弱性への対処法」で詳しく紹介しています。
【2026年7月最新】WordPress本体の脆弱性「wp2shell」とは

※本章は2026年7月22日時点の情報をもとに作成しています。脆弱性に関する情報は随時更新されるため、WordPress公式の最新情報もあわせてご確認ください。
2026年7月17日、WordPress本体に存在する重大な脆弱性を修正したセキュリティアップデートが公開されました。問題となったのは「CVE-2026-63030」と「CVE-2026-60137」の2つで、これらを組み合わせた攻撃は「wp2shell」と呼ばれています。
wp2shellが悪用されると、WordPressにログインしていない第三者でも、遠隔からサーバー上で不正なプログラムを実行できる可能性があります。プラグインやテーマではなく、WordPress本体に存在する脆弱性であることも、影響の大きさにつながっています。
WordPress公式は、問題の重大性を踏まえて、影響を受けるサイトへの強制的な自動アップデートを有効化しました。あわせて、管理者に対して修正版への速やかなアップデートを呼びかけています。
wp2shellは2つの脆弱性を組み合わせた攻撃

wp2shellは、1つの脆弱性の名称ではなく、以下の2つの脆弱性を組み合わせて悪用する攻撃チェーンです。
脆弱性 | 問題の概要 | 関係する攻撃手法 |
|---|---|---|
CVE-2026-63030 | REST APIのバッチ処理における経路の判定不備 | 認証回避につながる処理の悪用 |
CVE-2026-60137 | データベースへの問い合わせ処理における不備 | SQLインジェクション |
2つを組み合わせた場合 | 管理者権限の取得や不正なコードの実行につながる | 権限昇格・リモートコード実行 |
攻撃者は、まずREST APIの処理上の不備を利用し、本来は認証が必要な処理へ不正な入力を到達させます。続いてSQLインジェクションの脆弱性を悪用し、データベースから情報を取得したり、不正なデータを書き込んだりします。
この2つを組み合わせることで、攻撃者が不正な管理者権限を取得し、悪意のあるプラグインやWebシェルを設置して、サーバー上で任意のコードを実行できる可能性があります。
発見者のSearchlight Cyberは、標準的なWordPress環境に対し、プラグインやテーマ、事前のログインを必要とせず攻撃が成立する可能性があると報告しています。
参照:「wp2shell: Pre Authentication RCE in WordPress Core」
wp2shellが悪用された場合に想定される被害
wp2shellによってリモートコード実行が成立すると、攻撃者がWordPressだけでなく、その稼働環境まで操作できる可能性があります。
想定される主な被害は以下のとおりです。
- Webサイトの内容やデザインを改ざんされる
- 不正な管理者アカウントを作成される
- 顧客情報や会員情報を窃取される
- パスワードハッシュなどの認証情報を窃取される
- 悪意のあるプラグインやWebシェルを設置される
- マルウェアや不正広告を埋め込まれる
- フィッシングサイトや詐欺サイトへ転送される
- サーバーをほかのサイトへの攻撃の踏み台にされる
サイトを改ざんされれば、企業の信用を損なうだけでなく、検索エンジンから危険なサイトと判定され、検索結果に警告が表示されたり、流入が減少したりする可能性もあります。
また、攻撃者が一時的に作成した管理者アカウントや不正なプログラムを削除し、侵入の痕跡を隠すことも考えられます。
そのため、Webサイトの表示に異常がないからといって、被害を受けていないとは限りません。
wp2shellの影響を受けるWordPressのバージョン
影響を受けるバージョンと、脆弱性を修正したバージョンは以下のとおりです。
WordPressのバージョン | 主な影響 | 修正版 |
|---|---|---|
6.8.0~6.8.5 | SQLインジェクションの影響 | 6.8.6 |
6.9.0~6.9.4 | wp2shellによる一連の攻撃が成立する可能性 | 6.9.5 |
7.0.0~7.0.1 | wp2shellによる一連の攻撃が成立する可能性 | 7.0.2 |
7.1 Beta 1 | wp2shellによる一連の攻撃が成立する可能性 | 7.1 Beta 2 |
6.8より前 | 今回の2つの脆弱性による影響なし | 対象外 |
WordPress 6.8系はSQLインジェクションの脆弱性の影響を受けますが、2つの脆弱性を組み合わせたリモートコード実行は、主に6.9.0~6.9.4と7.0.0~7.0.1が対象です。
自動アップデートが有効になっているサイトでも、更新に失敗している可能性は0ではありません。念のため、管理画面や保守会社を通じて、実際に修正版へ更新されているか確認しましょう。
WordPress利用企業に求められる対応
影響を受けるバージョンを利用している場合は、WordPress本体を修正版へ速やかにアップデートしてください。
ただし、アップデートだけで対応を終わらせるのは十分ではありません。
修正版へ更新しても、更新前に侵入され、Webシェルや不正なプログラムを設置されていた場合、それらが自動的に削除されるとは限らないためです。
次の手順で対応しましょう。
- 利用中のWordPressのバージョンを確認する
- 6.8.6、6.9.5、7.0.2以降の修正版へ更新する
- 自動更新された場合も、実際のバージョンを確認する
- 身に覚えのない管理者アカウントがないか確認する
- 不審なプラグイン、ファイル、投稿、設定変更がないか調査する
- サーバーやWordPressのアクセスログを確認する
- 侵害の可能性がある場合は、管理者を優先してパスワードを変更する
- 同じパスワードを使っている他サービスも変更する
- 必要に応じてセキュリティ専門会社へ調査を依頼する
すぐにアップデートできない場合は、WAFなどを使い、攻撃に利用される通信を一時的に遮断する方法もあります。ただし、これは修正版を適用するまでの暫定的な対策であり、設定によってはサイトの機能に影響する可能性があります。自社で判断せず、サーバー会社や保守会社へ相談したうえで実施し、できるだけ早く修正版へアップデートしてください。
また、顧客情報や個人情報を扱うサイトで侵害が疑われる場合は、被害範囲を特定したうえで、社内のセキュリティ部門や法務部門とも連携する必要があります。
wp2shellから分かる、WordPress運用上の注意点
WordPressの脆弱性というと、プラグインやテーマの問題が注目されがちです。
しかし、wp2shellはWordPress本体で発見された脆弱性です。プラグインを厳選していても、WordPress本体のアップデートを止めていれば、重大な攻撃を受ける可能性があることを示しています。
また、今回の脆弱性では、修正版が公開されてから短期間で実証コードが出回り、実際の悪用も報告されました。
生成AIの普及により、修正内容の分析や攻撃コードの作成が効率化し、脆弱性の公表から攻撃開始までの時間がさらに短くなる可能性があります。
そのため、脆弱性が公表されてから対応方法を検討するのではなく、平常時から次のような体制を整えておくことが重要です。
- WordPress本体・プラグイン・テーマの保守担当者を決める
- 緊急アップデートの判断基準と手順を決める
- 本番反映前に確認できる検証環境を用意する
- 復旧可能なバックアップを定期的に取得する
- 管理者アカウントや権限を定期的に見直す
- ログやファイルの変更を継続的に監視する
- 侵害発生時の連絡・調査・復旧手順を用意する
- 制作会社と自社の保守範囲を明確にする
WordPressの脆弱性を完全になくすことは困難ですし、AIの普及で攻撃も増えていくことが予想される中、安全に使い続けることの難易度は上がっています。安全に使い続けるためには、脆弱性を早期に把握し、速やかにアップデートと侵害確認を行える運用体制が求められます。
なぜWordPressは脆弱性が狙われやすいのか
WordPressは世界中で広く利用されている一方、サイバー攻撃の標的になりやすいCMSでもあります。
ただし、「WordPressそのものが危険」というわけではありません。
利用者の多さや拡張性の高さに加えて、アップデートやセキュリティ対策が利用者側に委ねられていることから、適切に管理されていないサイトが狙われやすいのです。
ここでは、WordPressの脆弱性が狙われやすい主な理由を解説します。
- 世界中で利用されており、攻撃の費用対効果が高い
- オープンソースで、システムの構造を把握されやすいため
- ログイン画面や使用している構成を推測されやすいため
- プラグインやテーマの追加によって攻撃対象が増えやすいため
- 開発元によってセキュリティ品質に差がある
- 導入しやすい一方、適切な運用には専門知識が求められるため
- AIによって攻撃の探索・自動化がさらに容易になっている
- アップデートが利用企業側に委ねられている
世界中で利用されており、攻撃の費用対効果が高い
WordPressは、世界のWebサイトの約4割以上、国内に限れば8割ものシェアを占めるCMSです。この圧倒的な普及率こそ、攻撃者に狙われる最大の理由といえます。
攻撃を仕掛ける側にとって、利用者が多いプラットフォームを標的にすることは、効率よく脆弱性のあるサイトを見つけ出し、被害を拡大できることを意味します。一度の攻撃手法の開発で、膨大な数のサイトを攻略できる可能性があるため、攻撃者にとってWordPressは投資に対する成果を得やすい対象です。
常に主要なターゲットとして監視されていることを認識し、適切に管理されていないサイトは格好の標的になるリスクを理解しておく必要があります。
オープンソースで、システムの構造を把握されやすいため
WordPressは、プログラムのソースコードが公開されているオープンソースソフトウェアです。誰でも仕組みを確認できるため、開発者が問題を発見・修正しやすい一方、攻撃者もシステムの構造や変更内容を調査できます。
脆弱性とその修正内容が公開されると、攻撃者が情報を分析し、修正前のバージョンを使用しているサイトを狙うことがあります。そのため、修正版の公開後もアップデートしていないサイトは、攻撃を受けるリスクが高まります。
オープンソースであること自体が、脆弱性の多さや危険性を意味するわけではありません。
問題となるのは、発見された脆弱性を放置したまま運用を続けることです。
ログイン画面や使用している構成を推測されやすいため
WordPressには、管理画面のURLやファイルの配置など、サイト間で共通する構成があります。
そのため、外部からWordPressを利用していることや、使用中のテーマ・プラグインなどを推測される場合があります。
攻撃者は、こうした情報をもとに、管理画面への総当たり攻撃や、漏えいしたID・パスワードによるログイン、既知の脆弱性を狙ったスキャンなどを自動的に行います。
管理画面のURLを変更したり、WordPressのバージョン情報を隠したりするだけでは、十分な対策になりません。多要素認証やアクセス制限、WAF、ログ監視など、複数の対策を組み合わせる必要があります。
プラグインやテーマの追加によって攻撃対象が増えやすいため
WordPressは、プラグインやテーマを追加することで、問い合わせフォームやSEO、アクセス解析などの機能を手軽に拡張できます。一方、追加するプログラムが増えるほど、脆弱性が入り込む可能性のある箇所も増えていきます。
特に注意が必要なのが、使用していないプラグインや、更新されていないテーマの放置です。プラグインを無効化していても、ファイルがサーバーに残っていれば、脆弱性を悪用される可能性があります。
また、公開を終了した旧サイトやテスト環境が残り、管理されないまま攻撃の入口になるケースもあります。
利用していないプラグインやテーマは無効化するだけでなく削除し、不要なサイトや環境も定期的に整理しましょう。
開発元によってセキュリティ品質に差がある
WordPress本体と、追加するプラグイン・テーマは、必ずしも同じ組織によって開発されているわけではありません。個人から企業までさまざまな開発元が提供しており、セキュリティ対策や保守体制にも差があります。
例えば、脆弱性が発見された際に速やかに修正版を公開する開発元がある一方、長期間更新されていないものや、すでにサポートが終了しているものもあります。
プラグインやテーマを選ぶ際は、機能やデザインだけでなく、最終更新日、更新頻度、利用者数、サポート状況なども確認しましょう。
継続的に保守されているかどうかが、安全に利用するうえで重要な判断基準になります。
導入しやすい一方、適切な運用には専門知識が求められるため
WordPressは、専門的なプログラミング知識がなくても、比較的簡単にWebサイトを開設・更新できます。しかし、サイトを安全に運用し続けるには、一定の専門知識が必要です。
具体的には、WordPress本体やプラグインの更新だけでなく、サーバー設定、アクセス権限、アカウント管理、バックアップ、ログ監視、障害発生時の復旧などにも対応しなければなりません。
導入のしやすさと、安全に運用できることは別の問題です。
担当者が記事やページを更新できても、セキュリティ面まで適切に管理できるとは限りません。
社内に知識を持つ担当者がいない場合は、保守会社などの専門家に管理を依頼する必要があります。
AIによって攻撃の探索・自動化がさらに容易になっている
生成AIの普及により、攻撃者は脆弱性情報の分析、攻撃コードの作成補助、サイトの探索、フィッシング文面の生成などを以前より短時間で行いやすくなっています。
WordPress公式も2026年6月、AIによるセキュリティ環境の変化に言及しています。
※参照:「Protect The Shire」
ただし、「AIが新しい脆弱性を次々に生み出している」と断定するのは正確ではありません。
現時点では、既知の弱点を見つけて悪用するまでの速度や規模が高まり、守る側に迅速な検知と対応が求められている、と説明するのが適切です。
また、AIで生成したプラグインや独自コードを十分にレビューせず導入することも、新たなリスクになりますので、注意しましょう。
アップデートが利用企業側に委ねられている
WordPressでは、WordPress本体だけでなく、プラグイン、テーマ、PHP、Webサーバーなど、複数の要素を継続的に管理する必要があります。
脆弱性を修正したバージョンが公開されても、自社でアップデートしなければ問題は解消されません。
しかし実際の運用現場では、次のような理由から更新が遅れることがあります。
アップデートによる表示崩れや不具合が心配
検証環境がなく、事前に動作を確認できない
制作会社に依頼しなければ更新できない
社内と制作会社のどちらが保守するのか決まっていない
サイトを構築した担当者が退職している
このような状況では、脆弱性が判明しても修正版をすぐに適用できず、危険な状態が長期間残ってしまいます。安全に運用するには、アップデートの担当者や確認手順、実施頻度、不具合発生時の復旧方法まで、あらかじめ決めておくことが重要です。
WordPressの脆弱性を突く代表的な攻撃
WordPressサイトへの攻撃には、管理画面への不正ログインを試みるものや、プラグインなどの脆弱性を悪用するものがあります。
攻撃を受けると、Webサイトの改ざんや情報漏えいだけでなく、マルウェアの設置、別のサイトを攻撃するための踏み台化などにつながる可能性があります。代表的な攻撃の仕組みと、想定される被害を確認しておきましょう。
攻撃手法 | 悪用されるもの | 主な被害 |
|---|---|---|
ブルートフォース攻撃・パスワードリスト攻撃 | 推測しやすいパスワードなど | 不正ログイン |
SQLインジェクション | データベース処理の不備 | 情報漏えい、データ改ざん |
クロスサイトスクリプティング(XSS) | 入出力処理の不備 | 情報窃取、偽サイトへの誘導 |
クロスサイトリクエストフォージェリ(CSRF) | 操作元を確認する処理の不備 | 管理者が意図しない操作 |
ファイルアップロードの脆弱性を突いた攻撃 | ファイル検証の不備 | マルウェア設置、サーバー乗っ取り |
認証回避・権限昇格 | 認証・権限確認の不備 | 管理者権限の取得 |
パストラバーサル・ファイルインクルージョン | ファイル参照処理の不備 | 設定情報の窃取、コード実行 |
ブルートフォース攻撃・パスワードリスト攻撃|不正ログイン
ブルートフォース攻撃とは、考えられるすべてのパスワードの組み合わせを総当たりで入力し、不正にログインを突破しようとする攻撃手法です。
また、似た攻撃にパスワードリスト攻撃があります。
これは、ほかのサービスから流出したIDとパスワードの組み合わせを使って、ログインを試みる方法です。複数のサービスで同じパスワードを使い回していると、不正ログインされる危険性が高まります。
WordPressは管理画面の構成を推測されやすく、利用者も多いため、こうした自動攻撃の標的になりやすい傾向があります。
不正ログインを防ぐには、強固で固有のパスワードを設定するだけでなく、多要素認証やログイン試行回数の制限、不要な管理者アカウントの削除などが必要です。
SQLインジェクション|情報漏えい、データ改ざん
SQLインジェクションは、検索窓やお問い合わせフォームなどに、不正なデータベースへの命令文を注入する攻撃手法です。
プラグインやテーマ、独自に開発したプログラムに入力値の処理不備があると、不正な命令を実行される可能性があります。
攻撃を受けた場合、次のような被害が考えられます。
顧客情報や会員情報の流出
管理者情報の取得
データの書き換えや削除
不正な管理者アカウントの追加
Webサイトの改ざん
WordPress本体にはSQLインジェクションを防ぐための機能が用意されていますが、プラグインや独自プログラムが適切に実装されていなければ、脆弱性が生じます
クロスサイトスクリプティング(XSS)|情報窃取、偽サイトへの誘導
クロスサイトスクリプティング(XSS)とは、Webページに不正なスクリプトを埋め込み、そのページを閲覧したユーザーのブラウザ上で実行させる攻撃です。
例えば、メント欄、問い合わせフォーム、検索フォーム、管理画面など、ユーザーが入力した内容を表示する機能に不備があると、攻撃を受ける可能性があります。
不正なスクリプトが実行されると、管理者のログイン情報やセッション情報を盗まれたり、偽サイトへ誘導されたりするおそれがあります。管理者が攻撃対象のページを閲覧したことをきっかけに、より大きな被害へ発展する場合もあります。
クロスサイトリクエストフォージェリ(CSRF)|管理者が意図しない操作
クロスサイトリクエストフォージェリ(CSRF)とは、WordPressにログインしている管理者を不正なWebページやリンクへ誘導し、本人の意図しない操作を実行させる攻撃です。
例えば、管理者がログインした状態で攻撃用のリンクを開くと、次のような操作が勝手に行われる可能性があります。
管理者アカウントの追加
設定情報の変更
記事の公開や削除
プラグインの設定変更
外部サイトへの不正な転送設定
なおCSRFは、管理者のIDやパスワードを直接盗まなくても攻撃が成立する場合があります。WordPressには、リクエストが正規の操作によるものかを確認する「nonce」と呼ばれる仕組みがありますが、プラグインやテーマ側で適切に実装されていなければ、脆弱性が生じます。
ファイルアップロードの脆弱性を突いた攻撃|マルウェア設置、サーバー乗っ取り
画像や文書などをアップロードする機能に不備があると、攻撃者によって不正なプログラムをサーバーへ置かれる可能性があります。
本来許可されていないPHPファイルなどのアップロードを許してしまうと、サーバー上で不正なコードを実行されるおそれがあります。このような攻撃は、問い合わせフォーム、会員機能、ファイル管理プラグインなどの脆弱性を通じて行われます。
例えば、不正なファイルを設置されると、次のような被害につながります。
Webサイトの改ざん
個人情報や機密情報の窃取
マルウェアや不正広告の設置
サーバーの乗っ取り
ほかのシステムへの侵入
攻撃の踏み台としての悪用
過去には、WordPressのファイル管理プラグインの脆弱性を利用し、認証されていない第三者がファイルをアップロードできる問題も確認されています。
認証回避・権限昇格|管理者権限の取得
認証回避とは、本来必要なログイン手続きを通らずに、管理機能や保護された情報へアクセスする攻撃です。
権限昇格とは、投稿者や一般会員などの権限しか持たない利用者が、脆弱性を悪用して管理者相当の権限を取得する攻撃を指します。
プラグインやテーマに、ログイン状態やユーザー権限を適切に確認していない処理があると、次のような被害につながる可能性があります。
不正な管理者アカウントの作成
サイト設定の変更
記事やページの改ざん
プラグインの追加・変更
顧客情報や会員情報の閲覧
不正なプログラムの設置
管理者権限を奪われると、Webサイトのほぼすべての機能を操作される可能性があります。
被害が表面化するまで時間がかかることもあるため、管理者アカウントや権限設定を定期的に確認することが重要です。
パストラバーサル・ファイルインクルージョン|設定情報の窃取、コード実行
パストラバーサルとは、ファイルを読み込む機能の不備を悪用し、本来アクセスできないサーバー内のファイルを閲覧する攻撃です。
ファイルインクルージョンは、不正なファイルや外部のプログラムを読み込ませる攻撃です。
プラグインやテーマが外部から指定されたファイル名や保存場所を適切に検証していない場合に発生することがあります。
これらの攻撃を受けると、WordPressの設定ファイルや認証情報を取得されたり、不正なコードを実行されたりする可能性があります。データベースへの接続情報などが記載された設定ファイルを盗まれると、情報漏えいやサイトの乗っ取りに発展するおそれがあるため注意が必要です。
WordPressサイトに脆弱性がないか調べる方法

WordPressサイトの脆弱性は、一つの機能やツールだけでは判断できません。WordPress本体に加えて、プラグイン、テーマ、PHP、サーバー、独自開発したプログラムなど、複数の対象を確認する必要があります。
また、「脆弱性が存在するか」と「すでに脆弱性を悪用されているか」も分けて調べる必要があります。
以下の方法を組み合わせて、サイトの状態を確認しましょう。
WordPress本体・プラグイン・テーマのバージョンを確認する
WordPressのサイトヘルス機能を使う
JVNなどで最新の脆弱性情報をキャッチアップする
脆弱性スキャンツールやセキュリティ機能を使う
Google Search Consoleやログで侵害の兆候を確認する
専門会社による脆弱性診断を受ける
一度の確認だけで「脆弱性がない」とは判断できない
WordPress本体・プラグイン・テーマのバージョンを確認する
最初に、WordPressサイトを構成するソフトウェアと、そのバージョンを確認します。
WordPressの管理画面から「ダッシュボード」→「更新」を開くと、WordPress本体、プラグイン、テーマに利用可能なアップデートがないか確認できます。
更新通知の有無だけでなく、長期間更新されていないものやサポートが終了したものにも注意が必要です。使用していないプラグインやテーマは、無効化するだけでなく削除しましょう。
WordPressのサイトヘルス機能を使う

WordPress5.2以降に標準搭載されている機能です。管理画面の「ツール」>「サイトヘルス」からすぐに確認できます。
「致命的な問題」が表示されている場合は即座に対応が必要です。
特に「古いPHPバージョン」や「停止中のプラグイン」の指摘は、脆弱性に直結するため注意しましょう。
サイトヘルス機能を開くと、現在のWebサイトの状態が表示され、どのような改善を行うべきかを提案してくれます。状態が良好でも改善提案は表示されますので、可能であれば対応しておくのがおすすめです。
無料で簡単にチェックできるので、すぐに確認してみましょう。
JVNなどで最新の脆弱性情報をキャッチアップする
「JVN(Japan Vulnerability Notes)」とは、日本で利用されているソフトウェアやCMS、アプリケーションなどの脆弱性に関する情報と対策情報を提供しているポータルサイトです。
JVNは独立行政法人情報処理推進機構 (IPA)が共同で運営しており、信頼性の高い情報源と言えるので、WordPress含めたソフトウェアの脆弱性情報をチェックするのにおすすめです。
例えば以下の画像のように、WordPressのプラグインに脆弱性が発見されたなどの情報を得られます。
出典:JVN(Japan Vulnerability Notes)
脆弱性に対する知識や情報を常に最新の状態に保つためにも、こまめにJVNの情報を確認しておくといいでしょう。
脆弱性スキャンツールやセキュリティ機能を使う
WordPress向けのスキャンツールやセキュリティプラグインを使うと、既知の脆弱性やファイル改ざん、マルウェアなどを確認できます。
ただし、未知の脆弱性や独自開発部分の問題は検出できない場合があります。サーバーに負荷をかける可能性もあるため、制作会社やサーバー会社と調整して実施しましょう。
Google Search Consoleやログで侵害の兆候を確認する
Webマーケターにとって最も身近なツールである「GoogleSearchConsole」は、セキュリティチェックにも有効です。
管理画面の左メニューにある「セキュリティと手動による対策」>「セキュリティの問題」をクリックすると確認できます。
サイトがハッキングされたり、マルウェア(悪意のあるプログラム)が検出されたりした場合、Googleから直接警告が表示されます。あわせて、ログや管理画面から、不審なログイン、見覚えのない管理者・プラグイン・ファイル、意図しないページ変更がないかも調べましょう。
ただし、Search Consoleに警告がなくても安全とは限りませんので補助的な確認として活用しましょう。
専門会社による脆弱性診断を受ける
顧客情報を扱うサイトや、会員・決済機能、独自開発機能があるサイトは、専門会社による診断も検討しましょう。
依頼時は、本体・プラグイン・テーマ・サーバー・独自開発部分のうち、どこまでが対象かを確認します。問題の特定だけでなく、改修方法の提示や改修後の再診断に対応しているかも重要です。
WordPressの脆弱性から守る11つの対策

現代の高度化したサイバー攻撃(AIによる自動攻撃や、修正プログラム公開前のゼロデイ攻撃など)からサイトを守るためには、従来の対策を一段階引き上げる必要があります。
以下の11の対策を、優先度の高い順に実施しましょう。
- WordPress本体・プラグイン・テーマを最新に保つ
- 不要なプラグイン・テーマを完全に削除する
- PHP・サーバー環境をサポート対象のバージョンに保つ
- 強固で固有のパスワードと2要素認証を使用する
- ユーザーアカウントと権限を適切に管理する
- ログイン画面への攻撃を制限する
- WAFとサーバー側のセキュリティ機能を利用する
- WordPressとサーバーの設定を見直する
- 復旧できるバックアップを定期的に取得する
- ログ・ファイル変更・脆弱性情報を継続的に監視する
- 侵害発生時の対応・復旧手順を決めておく
専門知識のないWebマーケターでも対応可能な基本的な対策もあるので、ぜひ参考にしてみてください。
①【最優先】WordPress本体・プラグイン・テーマを最新に保つ
脆弱性対策で最も重要なのは、WordPress本体、プラグイン、テーマを修正版へ速やかにアップデートすることです。
例えば「wp2shell」のように、ログインを必要とせず攻撃できる脆弱性は、パスワードの強化や2要素認証だけでは防げません。脆弱性を解消したバージョンへ更新することが、根本的な対策になります。
実際の運用では、次の点まで決めておく必要があります。
アップデート情報を確認する担当者
緊急アップデートを適用する判断基準
更新前のバックアップ方法
テスト環境での動作確認手順
不具合が発生した場合の復旧方法
制作会社と自社の対応範囲
自動更新を有効にしていても、更新の失敗や互換性の問題が発生する可能性があります。自動更新の結果まで確認できる体制を整えましょう。
②不要なプラグイン・テーマを完全に削除する
長期間使われていないテーマやプラグインは脆弱性を含んでいる場合が多く、格好のハッキングリスクとなります。
現在使用していないものは、無効化するだけでなく、サーバー上から完全に削除しましょう。
特に注意が必要なのは、次のようなものです。
長期間更新されていないプラグイン
開発やサポートが終了したプラグイン
用途が分からないプラグイン
使用していないテーマ
制作会社が独自に追加したプログラム
旧サイトやテスト環境に残っているプラグイン
必要なプラグインについても、定期的に「現在も必要か」「代替機能へ統合できないか」を見直すことが重要です。
③PHP・サーバー環境をサポート対象のバージョンに保つ
WordPress本体だけを更新しても、PHP、データベース、Webサーバーなどが古ければ、サイト全体のリスクは残ります。
WordPressを動かしているプログラミング言語「PHP」にもサポート期限があります。セキュリティサポートが提供されているバージョンを使用しましょう。なお、古いバージョン(7系以前など)はセキュリティ上の欠陥が放置されているため、サーバーの管理画面から最新の安定版(8.x系)へ切り替えてください。
レンタルサーバーを利用している場合は、以下を確認しましょう。
現在のPHPバージョン
利用中のバージョンのサポート期限
サーバー側で提供されるセキュリティ機能
PHPやデータベースの更新方法
サーバー会社によるバックアップの範囲
④強固で固有のパスワードと2要素認証を使用する
管理者アカウントには、ほかのサービスで使用していない、長く複雑なパスワードを設定します。複数のサービスで同じパスワードを使い回すと、ほかのサービスから認証情報が流出した際に、WordPressへ不正ログインされる可能性があります。
加えて、管理者や編集者など、重要な権限を持つアカウントには2要素認証を導入しましょう。パスワードが漏えいしても、認証アプリなどによる追加確認があることで、不正ログインのリスクを抑えられます。
ただし、2要素認証はログインを守る対策です。プラグインやWordPress本体の脆弱性を直接解消するものではないため、アップデートと組み合わせる必要があります。
⑤ユーザーアカウントと権限を適切に管理する
すべての利用者へ管理者権限を付与すると、アカウントが乗っ取られた際の被害が大きくなります。担当業務に必要な最小限の権限だけを付与しましょう。
例えば、記事の作成・更新だけを担当するユーザーには、管理者ではなく編集者や投稿者の権限を設定します。
また、以下を定期的に確認する必要があります。
退職者や異動者のアカウントが残っていないか
共有アカウントを使用していないか
不要な管理者権限が付与されていないか
身に覚えのないアカウントが作成されていないか
長期間使用されていないアカウントがないか
誰がどの操作を行ったか確認できるよう、アカウントは原則として個人ごとに発行しましょう。
「wp-config.php」の権限設定
WordPress内のデータベース情報を保有する「wp-config.php」というファイルが不正アクセスされると、WordPress全体を乗っ取られてしまう可能性があります。そのため、wp-config.phpファイルの権限を変更して、管理者以外のアクセスを禁止することでセキュリティ対策が可能です。
wp-config.phpファイルの権限変更の手順は以下の通りです。
- FTPソフトウェア(FFFTP or FileZilla)でWordPressにアクセス
- 「public_hrml」フォルダにある「wp-config.php」を選択
- サーバー属性を「現在の属性(FFFTP)」または「属性値を600(FileZilla)」に変更
またwp-config.phpと同じファイルにある「.htaccess」を編集してアクセス権限を変更する方法もあります。.htaccessファイルをダウンロードし、テキストエディタで以下のコードを記述します。
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from (固定IPアドレスを指定)
</Files>
注意点として、コードは必ず改行まで含めて記述してください。また、ネットワーク環境が固定IPアドレスでない場合は指定できないので、編集前に確認しておくようにしましょう。
⑥ログイン画面への攻撃を制限する
WordPressの管理画面には、ブルートフォース攻撃やパスワードリスト攻撃が繰り返し行われる可能性があります。
以下の対策を組み合わせて、ログイン画面への攻撃を制限しましょう。
ログイン試行回数を制限する
CAPTCHAやボット対策を導入する
管理画面へのアクセス元を制限する
不審なIPアドレスを遮断する
ログイン失敗を監視・通知する
使用していない認証機能を無効化する
社内や特定拠点からしか管理画面を利用しない場合は、IPアドレスによるアクセス制限も有効です。
ただし、テレワークや外出先から利用する場合は運用しにくいため、VPNやゼロトラスト型のアクセス制御も検討します。
ログインURLの変更は、自動攻撃の数を減らす効果は期待できますが、URLを特定されれば突破されます。単独のセキュリティ対策としては扱わず、補助的に利用しましょう。
⑦WAFとサーバー側のセキュリティ機能を利用する
WAFは、Webサイトへの通信を監視し、SQLインジェクションやクロスサイトスクリプティングなど、攻撃と判断される通信を遮断する仕組みです。
修正版をすぐに適用できない場合や、未知・既知の攻撃を受けた場合の被害軽減に役立ちます。ただし、WAFですべての攻撃を防げるわけではなく、アップデートの代わりにはなりません。
レンタルサーバーやCDNを利用している場合は、次の機能が提供されていないか確認しましょう。
WAF
DDoS対策
マルウェアスキャン
不正アクセスの遮断
ファイル改ざん検知
国・地域単位のアクセス制限
サーバーログの保存
機能が用意されていても、初期状態では無効になっている場合があります。契約内容と設定状況の両方を確認することが重要です。
⑧WordPressとサーバーの設定を見直す
WordPressやサーバーの設定不備によって、攻撃を受けた際の被害が拡大することがあります。代表的な確認項目は以下のとおりです。
wp-config.phpのファイル権限を必要最小限にする
ファイルやディレクトリへ過剰な書き込み権限を与えない
管理画面からのテーマ・プラグイン編集を無効化する
デバッグ情報を本番環境に表示しない
ディレクトリ一覧を外部へ公開しない
不要なAPIや機能を停止する
データベースや設定ファイルを外部から参照できないようにする
適切な設定は、利用しているサーバーやサイト構成によって異なります。インターネット上の設定例をそのまま適用せず、制作会社やサーバー会社へ確認したうえで変更しましょう。
常時SSL化も必須です。SSL/TLSは、ブラウザとサーバー間の通信を暗号化し、ログイン情報などの盗聴・改ざんを防ぎます。ただし、WordPress本体やプラグインに存在する脆弱性を修正するものではありません。
⑨復旧できるバックアップを定期的に取得する
バックアップは攻撃を防ぐ対策ではありませんが、改ざんやマルウェア感染、アップデート時の障害から復旧するために欠かせません。
次のデータを定期的に保存しましょう。
WordPressのファイル
データベース
アップロードした画像や資料
テーマや独自開発したプログラム
サーバーやDNSなどの設定情報
バックアップは、WordPressが稼働しているサーバーとは別の場所にも保管します。同じサーバー内だけに保存すると、サーバーを乗っ取られた際にバックアップも削除・改ざんされる可能性があります。
また、取得するだけでなく、実際に復元できるか定期的にテストすることが重要です。感染後に取得したバックアップへ戻しても、マルウェアが残る可能性があるため、複数世代を保管しましょう。
⑩ログ・ファイル変更・脆弱性情報を継続的に監視する
攻撃を完全に防ぐことは困難です。そのため、侵入や異常を早期に検知できる仕組みも必要です。
主に監視する項目は以下のとおりです。
管理画面へのログインと失敗回数
管理者アカウントの追加・変更
プラグインの追加や有効化
WordPressファイルの変更
不審な通信やアクセス急増
WordPress本体・プラグインの脆弱性情報
Google Search Consoleのセキュリティ警告
セキュリティプラグインは、ログイン制限、脆弱性情報の通知、マルウェアスキャン、改ざん検知などを補助する手段として利用できます。
ただし、導入するだけで安全になるわけではありません。通知を誰が確認し、異常を検知した際に誰が対応するかまで決めておきましょう。
また、セキュリティプラグイン自体に脆弱性が発見される可能性もあります。信頼性や更新状況を確認し、必要な機能に絞って導入することが大切です。
⑪侵害発生時の対応・復旧手順を決めておく
脆弱性が悪用された場合、初動対応の遅れによって被害が拡大します。平常時から、問題が発生した際の連絡先や対応手順を決めておきましょう。
少なくとも、以下を明確にしておく必要があります。
サイトを停止・遮断する判断者
制作会社やサーバー会社への連絡先
ログや証拠を保全する方法
被害範囲を調査する担当者
パスワードや認証情報の変更手順
安全なバックアップからの復旧方法
顧客や関係者への連絡基準
個人情報漏えい時の社内報告手順
侵害が疑われる場合、慌ててファイルを削除したり、バックアップで上書きしたりすると、調査に必要な証拠が失われる可能性があります。自社で判断できない場合は、セキュリティ専門会社へ相談しましょう。
WordPressサイトが攻撃を受けた場合の対処法
どれだけ入念に対策を講じていても、サイバー攻撃のリスクを完全に排除することはできません。
万が一、サイトの改ざんや不正アクセスなどの被害が疑われる場合は、焦らずに冷静に対処を進める必要があります。
具体的な対処手順をご紹介します。
サイトへのアクセスを制限し、被害の拡大を防ぐ
社内の関係者へ連絡し、対応責任者を決める
ログや不審なファイルなどの証拠を保全する
専門家や契約サーバー会社に相談する
侵入経路と被害範囲を調査する
脆弱性を修正し、不正なファイルやアカウントを排除する
安全なバックアップから復元する
安全性を確認してからサイトを再公開する
必要に応じて関係者への報告・公表を行う
1.サイトへのアクセスを制限し、被害の拡大を防ぐ
不正アクセスの兆候が確認された場合は、訪問者のマルウェア感染など二次被害を防ぐために、速やかにサイトを外部からアクセスできない状態にしましょう。
サーバーの管理パネルからメンテナンスモードに切り替えたり、FTPソフトを使ってトップページのファイル名を変更したりすることで、一時的なオフライン状態にできます。
被害の拡大を防ぐための最初の行動として非常に重要です。
2.社内の関係者へ連絡し、対応責任者を決める
サイトを停止・制限したら、社内のセキュリティ担当者、システム担当者、上長などへ速やかに報告します。
顧客情報や個人情報を扱うサイトの場合は、法務・広報・個人情報保護の担当部門にも連絡が必要です。被害の可能性がある段階でも情報を共有し、誰が判断と対応を行うのか明確にしましょう。
初動時には、少なくとも以下を記録します。
問題を発見した日時
発見者と発見の経緯
確認された改ざんや不審な動作
対象となるサイトやサーバー
実施したアクセス制限や設定変更
制作会社・サーバー会社への連絡状況
顧客情報や個人情報を扱っているか
対応中の変更も、実施者と日時を含めて記録しておくと、後の原因調査や報告に役立ちます。
3.ログや不審なファイルなどの証拠を保全する
アクセスログ、操作ログ、データベース、WordPressのファイル、不審なアカウントなど、証拠となるデータを保存します。
不審なファイルを見つけても、すぐに削除してはいけません。作成日時や内容が、侵入経路を特定する手がかりになるためです。発見日時、確認した被害、実施した操作も記録し、安全な場所に保管しましょう。
CISAもインシデント対応において、調査前に関連するログやデータなどを収集・保全することを推奨しています。
参照:「Technical Approaches to Uncovering and Remediating Malicious Activity」
なお、調査目的で保存したデータには、マルウェアや個人情報が含まれる可能性があります。安全な場所に隔離し、アクセスできる担当者を限定しましょう。
4.専門家や契約サーバー会社に相談する
自社だけで原因の特定や復旧が難しい場合は、速やかに専門家に相談することが重要です。
証拠を保全しながら、WordPressの制作・保守会社、契約しているサーバー会社、セキュリティ専門会社へ相談します。
特に、以下に該当する場合は、自社だけで復旧しようとせず、早い段階で専門家へ依頼しましょう。
管理画面へログインできない
不審なファイルを削除しても再び作成される
顧客情報や個人情報が漏えいした可能性がある
複数のサイトやサーバーに被害が及んでいる
不正な管理者アカウントが作成されている
Webシェルやマルウェアが設置されている
侵入経路や被害を受けた時期が分からない
バックアップが安全か判断できない
サーバー会社には、同じサーバーやネットワークで異常が確認されていないか、利用できるログやバックアップがあるか、アカウントに不正アクセスがなかったかを確認します。
WordPress公式も、共有ホスティングを使用している場合は、被害が一つのサイトだけに限定されない可能性があるため、ホスティング会社へ確認することを推奨しています。
参照:「FAQ My site was hacked」
5.侵入経路と被害範囲を調査する
サイトを安全に復旧するには、何が原因で侵入され、どこまで被害が及んだのかを特定する必要があります。
主に以下の項目を調査します。
悪用された脆弱性
侵入を受けた日時
攻撃元のIPアドレスや通信
不正ログインされたアカウント
追加・改ざんされたファイル
不正に追加されたプラグイン
作成された管理者アカウント
データベースの変更
外部へ送信された可能性のある情報
同じサーバー上にあるほかのサイトへの影響
攻撃者が継続してアクセスするための仕組み
見つかった不正ファイルを一つ削除しただけでは、別の場所に侵入経路やバックドアが残っている可能性があります。WordPressのファイルだけでなく、データベース、サーバー、管理用端末、FTP・SSHアカウントなども含めて確認する必要があります。
6.脆弱性を修正し、不正なファイルやアカウントを排除する
原因となったWordPress本体やプラグイン、テーマを修正版へ更新し、不正なファイルやアカウントを削除します。
あわせて、WordPress、サーバー、データベース、FTP・SSHなどのパスワードを変更しましょう。
外部サービスのAPIキーなどが保存されていた場合は、それらも漏えいした可能性を考え、再発行を検討します。
7.安全なバックアップから復元する
被害を受ける前の正常な状態のバックアップデータが残っている場合は、それを利用してサイトを復元することも有効な手段です。
ただし、復元を行う前に、なぜ攻撃を受けたのか原因を特定し、同じ脆弱性が残ったままにならないように注意することが重要です。
復元後も必ずパスワードの変更や不要なファイルの削除といった対策を実施し、再発防止を徹底しましょう。
侵入経路を塞いだ後、攻撃を受ける前の安全なバックアップから復元します。
バックアップ内に不正なプログラムが含まれていないか確認し、復元後はWordPress本体やプラグインを安全なバージョンへ更新してください。
バックアップの安全性を判断できない場合は、新しい環境を構築し、確認済みのデータだけを移行します。
8.安全性を確認してからサイトを再公開する
再公開前に、不正なファイルやアカウントが残っていないか、マルウェアや不審な転送がないかを確認します。
再開後も、ログイン履歴やファイル変更、外部通信を重点的に監視しましょう。個人情報の漏えいが疑われる場合は、法務や専門家と連携し、利用者や関係機関への報告が必要か判断します。
9.必要に応じて関係者への報告・公表を行う
顧客情報や個人情報の漏えい、不正利用などが確認・疑われる場合は、社内の法務・個人情報保護・広報担当者や外部専門家と連携し、必要な対応を判断します。
被害の内容によっては、以下への報告や連絡が必要になる場合があります。
顧客やサイト利用者
取引先
個人情報保護委員会などの関係機関
警察
IPAやJPCERT/CC
決済会社や外部サービスの提供会社
サイバー保険の保険会社
報告の要否や期限は、漏えいした情報や被害状況、適用される法令・契約によって異なります。自社だけで判断せず、法務担当者や専門家に確認してください。
外部への説明では、確認できた事実と調査中の事項を分け、発生日時、影響範囲、実施した対策、利用者に求める対応などを明確に伝えることが重要です。
WordPressのセキュリティ運用が不安なら、クラウド型CMSも選択肢
WordPressを安全に運用するには、本体・プラグイン・PHP・サーバーなどを継続的に管理し、脆弱性が見つかった際に迅速に対応できる体制が必要です。
社内に専門知識を持つ担当者がいない場合、外部へ保守を委託する方法もありますが、対応に時間やコミュニケーションコストがかかることもあります。
セキュリティ対応の負担を抑えながら、自社でサイトを更新・改善したい場合は、システムの保守をベンダーに任せられるクラウド型CMSへの移行も検討しましょう。
WordPressのセキュリティ懸念からの乗り換えも多数のCMS「ferret CMS」

弊社の提供する「ferret CMS」は、内部監査やパッチマネジメント、脆弱性診断を継続して行うBtoB企業向けのクラウド型CMSです。内部監査やパッチマネジメント、脆弱性診断を継続的に実施し、安心してサイトを運用できる環境づくりに取り組んでいます。
「WordPress」の脆弱性を課題とする企業様からのお乗り換え事例も多数ございます。
毎週の自動脆弱性診断と迅速なアップデート
専任のエンジニアチームが毎週、システム全体の脆弱性診断を実施。新たな脅威が見つかった際も、ユーザー側で作業することなくプラットフォーム側で一括アップデートが行われるため、常に最新の安全な環境を利用できます。WAF(ウェブアプリケーション・ファイアウォール)標準搭載
SQLインジェクションやクロスサイトスクリプティングなど、Webアプリケーションを狙った攻撃を水際で遮断。複雑なサーバー設定を自社で行う必要はありません。高度な認証機能(SAML認証・MFA)に対応
2026年の最新セキュリティ要件に対応し、SAML認証によるシングルサインオン(SSO)や多要素認証(MFA)が利用可能です。退職者のアカウント消し忘れによる不正アクセスや、ログイン情報の漏洩リスクを最小限に抑えます。
■毎週の自動脆弱性診断と迅速なアップデートで安心のセキュリティ!WordPressから乗り換えも多数
>ferret Oneサービス紹介資料のダウンロード【無料】はこちら
まとめ|WordPressの安全な運用には、継続的な保守体制が欠かせない
WordPressは、適切な対策を行えば安全に利用できるCMSです。
しかし、wp2shellのような重大な脆弱性に備えるには、本体・プラグイン・サーバーの更新や脆弱性情報の収集、監視、バックアップを継続し、問題発生時に迅速に対応できる体制が欠かせません。
自社でセキュリティ対策を続けることに不安がある場合は、管理をベンダーに任せられるクラウド型CMSも選択肢にいれてみてください。
「ferret CMS」では、内部監査やパッチマネジメント、脆弱性診断などを継続的に実施。高度な認証機能(SAML認証・MFA)に対応しています。
WordPressからの移行事例も多くございます。
セキュリティ運用の負担を軽減しながら、サイト改善も進められるferret CMSをぜひご検討ください。
>ferret Oneサービス紹介資料のダウンロード【無料】はこちら









