2026年版WordPressセキュリティ完全ガイド｜AI時代の攻撃手法と防御策

WordPressは世界中で広く使われているCMSだからこそ、攻撃者に狙われやすいのも事実です。ただし、2026年の現状を踏まえて正しく運用すれば、必要以上に怖がる必要はありません。

• 2026年時点でWordPressサイトを狙う主な攻撃手法
• AI時代に増えた攻撃の考え方と、管理者が優先して行うべき防御策
• WordPress 6.8以降のbcryptや、脆弱性情報の定期チェック方法

本記事では、WordPress セキュリティ対策の基本から、2026年に意識したいAI時代の攻撃手法、WordPress 6.8以降のbcrypt、脆弱性情報のチェック方法までをわかりやすく解説します。（専門知識は不要です！）

注：この記事は、WordPressの公式ドキュメントや各サービスの公式情報をもとに、個人サイト運営者・中小企業Web担当者向けに整理した内容です。脆弱性や攻撃手法は日々更新されるため、重要な判断を行う際は必ず公式情報も併せて確認してください。

2026年にWordPressサイトを狙う主な攻撃手法

2026年も中心は、既知の脆弱性悪用と認証の弱さを突く攻撃です。

まず押さえておきたいのは、WordPressが危険なのではなく、利用者が多く攻撃対象として効率がよいという点です。WordPress公式のSecurityやHardening WordPressでも、セキュリティは一度設定して終わりではなく、継続的な監視と保守が必要だと案内されています。

狙われやすいのはWordPress本体よりプラグイン・テーマの脆弱性

実際の侵入口として多いのは、WordPress本体そのものより、更新されていないプラグインやテーマです。Patchstackの脆弱性データベースやWordfence Intelligence、WPScan APIでは、WordPress本体だけでなくプラグイン・テーマの脆弱性情報が継続的に更新されています。

特に注意したいのは、使っていないのに残したままのプラグインや、長期間更新されていないテーマです。無効化しただけでは、将来的に管理上の見落としにつながることがあります。不要なものは停止だけでなく削除まで行うのが基本です。

ブルートフォース・認証情報の使い回し・不正ログイン

管理画面へのログインを狙う攻撃は、2026年でも基本中の基本です。単純な総当たりだけでなく、別サービスから流出したメールアドレスとパスワードの組み合わせを試す「認証情報の使い回し」も現実的なリスクです。

このタイプの攻撃は、サイト側に大きな脆弱性がなくても起きます。そのため、強いパスワードの使用、管理者アカウント数の最小化、ログイン試行制限、2段階認証が重要になります。

改ざん・マルウェア設置・不審ボット巡回

侵入後に行われやすいのは、ファイル改ざん、悪意あるスクリプトの埋め込み、管理者アカウントの追加、リダイレクト設定の悪用などです。また、侵入前の段階でも不審なボットが大量のURLを探り、存在しないページや古い管理パスを試すことがあります。

こうした兆候は、アクセスログや404の増加として先に現れることがあります。ボット系アクセスの見え方については、内部記事の404bot対策の具体例も参考になります。

AI時代の攻撃は何が変わったのか

AIで攻撃の種類が一変したというより、既存の攻撃が速く自然になったと考えると理解しやすいです。

「AIを使った攻撃」と聞くと、まったく別物に感じるかもしれません。しかし実務上は、既存の攻撃がより自然に、より大量に、より素早くなったと考えると理解しやすいです。

AIはフィッシング文面となりすましを高度化しやすい

AIの影響がわかりやすいのは、管理者をだましてログイン情報を入力させるフィッシングです。日本語の不自然さが減り、相手の業種や立場に合わせた文面を短時間で作りやすくなっています。WordPress自体に脆弱性がなくても、管理者の認証情報が奪われれば侵入される可能性があります。

そのため、2026年のWordPress対策では「サイトに穴を作らない」だけでなく、「管理者の認証情報を守る」視点がより重要です。可能であれば2段階認証を必須にし、状況に応じてフィッシング耐性の高い認証方式も検討したいところです。

AI連携プラグインやエージェント機能が新しい攻撃面になる

もう1つの変化は、AI連携機能そのものが新しい攻撃面になりうる点です。たとえば、MCP（AIと外部ツールをつなぐ仕組み）を扱う機能では、権限設定の不備が重大な被害につながることがあります。実際に、AI EngineプラグインのMCP関連脆弱性については、Wordfenceの解説ページでも権限昇格や情報露出のリスクが案内されています。

AI連携を使うこと自体が危険という意味ではありません。ただし、チャットボット、AI生成、MCP、外部API接続のような機能を導入する場合は、通常のプラグイン以上に権限と公開範囲を確認する必要があります。

だからこそ認証強化と権限の最小化が重要になる

AI時代の攻撃を特別なものとして恐れるより、管理者権限を絞る、不要な機能を有効化しない、2段階認証を導入する、脆弱性情報を素早く把握する、といった基本を徹底する方が実用的です。AIは攻撃側の効率を上げますが、防御側に必要な原則そのものは大きく変わっていません。

まず実施したいWordPressの基本防御策

優先順位は、更新、強い認証、WAF、バックアップ、アクセス制御の順で考えると整理しやすくなります。

ここでは、被害を減らしやすい順に実務的な対策を整理します。すべてを一度に完璧にする必要はありませんが、次の項目は優先順位が高いです。

1. WordPress本体・テーマ・プラグインの更新状況を確認する
2. 管理者アカウントのパスワードと2段階認証を見直す
3. WAF・バックアップ・脆弱性通知を設定する

コア・テーマ・プラグインを止めずに更新する

もっとも重要なのは更新です。WordPress 6.8ではパスワードハッシュがbcryptに変更されるなど、コア側のセキュリティ改善も進んでいます。仕様の要点は、WordPress 6.8 Field Guideでまとめて確認できます。

更新時に不具合が不安な場合は、いきなり本番で適用するのではなく、バックアップを取得してから段階的に反映するのが安全です。また、使っていないプラグインやテーマは「無効化だけ」で残さないようにしましょう。

強固なパスワードと2段階認証を標準にする

強いパスワードは、長く、使い回しがなく、推測されにくいものが基本です。さらに、管理者アカウントには2段階認証を導入してください。パスワードが漏れた場合でも、2段階認証があるだけで突破されにくくなります。

WordPress専用の機能ではありませんが、認証の考え方としてはフィッシング耐性の高い方式が望ましいとされています。将来的にID連携やシングルサインオンを使う運用では、こうした考え方も参考になります。

WAF・バックアップ・サーバー設定で被害を広げない

WAFは、アプリケーションへの不正なリクエストを手前で遮断する仕組みです。サーバー側のWAFとプラグイン側のWAFは役割が少し異なります。サーバー側は広く基礎防御を担当し、プラグイン側はWordPressに近い場所で細かな制御やログ監視を補いやすい、という理解が実用的です。

また、バックアップは「最後の保険」です。毎日更新があるサイトなら日次、更新頻度が低くても定期的な自動バックアップを設定し、復元手順を事前に確認しておきましょう。あわせて、SSL/HTTPSを有効にして通信を暗号化し、管理画面を使うユーザーには必要最小限の権限だけを付与することも重要です。必要に応じて、管理画面へのアクセス元を絞る設定も検討してください。

WordPress 6.8以降のbcryptで何が変わったか

WordPress 6.8ではパスワード保存方式がbcryptに変わり、既存パスワードは次回正常ログイン時に再ハッシュされます。

2026年の記事として見逃せないのが、WordPress 6.8以降のパスワード保護の強化です。WordPress公式は、ユーザーパスワードの保存に使うハッシュアルゴリズムを、従来の方式からbcryptへ変更したと説明しています。

bcryptはパスワードハッシュを強化する仕組み

パスワードは通常、そのまま保存されるのではなく、ハッシュ化された状態で保存されます。bcryptは、そのハッシュ計算に十分なコストをかけることで、漏えい時の総当たり解読を難しくする仕組みです。WordPress公式でも、bcryptによりパスワード解読の計算コストが大きく上がると案内されています。

既存パスワードはすぐ無効にならず、次回ログイン時に再ハッシュされる

この変更で、今使っているパスワードが突然使えなくなるわけではありません。WordPress公式の説明では、既存のパスワードは引き続き有効で、ユーザーが正常にログインしたタイミングでbcryptに再ハッシュされます。

つまり、管理者が急いで全ユーザーにパスワード再設定を求める必要がある、という話ではありません。ただし、長期間ログインしていないアカウントがある場合は、アカウント棚卸しのよい機会になります。

bcrypt化しても2段階認証や更新作業は必要

ここは誤解しやすい点です。bcryptは、保存されたパスワードが漏れたときの耐性を高める改善であって、フィッシング、セッション乗っ取り、脆弱なプラグイン経由の侵入まで自動で防ぐものではありません。

そのため、bcryptが導入された今でも、更新、2段階認証、WAF、不要アカウント削除の重要性は変わりません。WordPress 6.8は前進ですが、それだけで「完全に安全」になるわけではない点は押さえておきましょう。

セキュリティプラグインはどう選ぶべきか

監視重視ならWordfence、ログイン保護重視ならSiteGuard、認証ルール管理ならSolid Securityが候補になります。

セキュリティプラグインは、名前だけで選ぶより「何を優先して守りたいか」で選ぶ方が失敗しにくいです。ここでは代表的な候補として、Wordfence・SiteGuard WP Plugin・Solid Securityを整理します。

Wordfenceが向くケース

Wordfenceは、WAF、ログイン保護、マルウェアスキャン、脆弱性通知などを幅広く扱いたい場合に向いています。特に、ログや検知情報まで見ながら運用したいサイトでは相性がよいです。脆弱性データベースや通知の仕組みも整っているため、「検知と監視」まで含めて考えたい人に向いています。

一方で、機能が多いぶん、最小限でよい小規模サイトには設定項目が多く感じることもあります。比較の補助として、内部記事のReally Simple SecurityとWordfenceの違いも参考になります。

SiteGuard WP Pluginが向くケース

SiteGuard WP Pluginは、ログイン保護に重点を置いたシンプルな導入を重視する人に向いています。ログインページ変更、画像認証、ログインロックなど、管理画面への攻撃を抑える機能が中心です。

ただし、ログインURL変更や認証機能の設定によっては、自分自身がログインできなくなるケースもあります。導入前に復旧手順を確認し、FTPやホスティングのファイルマネージャでプラグインを停止できる状態を確保しておくと安心です。

Solid Securityが向くケース

Solid Securityは、2段階認証やパスワード要件の強制、ログイン保護などをまとめて管理したい場合に向いています。利用者が複数いるサイトで、認証ルールを整理したいときに使いやすい構成です。

また、内部記事のReally Simple Securityの機能と注意点と併せて読むと、「認証重視で設計するか」「幅広い監視まで含めるか」の違いがつかみやすくなります。

なお、セキュリティプラグインは複数入れればよいわけではありません。ログイン保護やWAFなどの機能が重複すると、競合や誤作動の原因になることがあります。基本は役割を決めて最小構成にする方が管理しやすいです。

脆弱性情報を定期的にチェックする方法

通知を仕組み化し、最低でも週1回は更新状況と脆弱性情報を確認する運用が現実的です。

2026年のWordPress運用では、「プラグインを入れたから安心」では足りません。重要なのは、脆弱性情報を継続的に追い、影響のあるプラグインやテーマを早めに把握することです。

最低限見るべき情報源はWordfence・WPScan・Patchstack

定期チェックの情報源として使いやすいのは、Wordfence Intelligence、WPScan API、Patchstack Databaseです。

Wordfence IntelligenceはAPIやWebhook通知が使いやすく、WordPress向けの脆弱性通知を仕組み化しやすいのが特徴です。WPScanはWordPress本体・プラグイン・テーマの脆弱性データを扱っており、CLIやAPI活用とも相性があります。Patchstackは脆弱性データベースの網羅性が高く、公開済みか、緩和策があるか、といった状況も確認しやすいです。

手動チェックより通知の仕組み化が重要

毎日すべてを目視で確認するのは現実的ではありません。そこで、通知の仕組みを作っておくと見落としを減らせます。Webhook通知の設定例は、Wordfence IntelligenceのWebhook通知ガイドでも確認できます。

また、保守担当者が少ない場合は、「更新通知」「脆弱性通知」「バックアップ結果」の3つだけでも定期的に届く形にしておくと、運用がかなり安定します。重要サイトでは週1回に加えて、日次で通知を把握できる体制が望ましいです。

週1回のチェック項目をテンプレ化する

最低限、週1回は次の項目を確認したいところです。

1. WordPress本体・テーマ・プラグインに未更新がないか
2. 最近使っていないプラグインやテーマが残っていないか
3. 脆弱性データベースで、自サイトの利用プラグインに影響がないか
4. 管理者アカウントやログイン失敗の急増がないか
5. バックアップが正常に取得できているか

サイト数が増えてきたら、この確認を表やタスク管理ツールに落とし込み、属人化を避けるのがおすすめです。

よくある質問（FAQ）