WordPressはセキュリティ的に危険？狙われる理由と、小さな会社・お店のサイトでやっておきたい対策

「WordPressはセキュリティ的に危ないって聞いたけど、本当？」

ホームページのご相談を受けていると、こうした質問をよくいただきます。特に10月は、PHPの脆弱性「PHP2Shell」や、バックアップ系プラグインの連携機能を悪用した攻撃など、WordPressに関わるニュースが続いたため、不安に感じている方も多いと思います。

結論からいうと、WordPressそのものが特別に危険というわけではありません。ただし、使い方や管理のしかたによっては、被害にあいやすくなるのも事実です。

この記事では、小さな会社やお店でWordPressのサイトを運営している方に向けて、「なぜWordPressは危ないと言われるのか」「実際に被害が起きる原因は何か」「何をしておけば安心なのか」を、公式の情報やデータをもとに整理します。

この記事は2026年10月26日時点の公開情報をもとに作成しています。数値や推奨バージョンは今後変わる可能性があります。最新情報は記事末尾の参考情報（WordPress公式のガイドなど）もあわせてご確認ください。

まず結論

1. WordPress本体は、セキュリティの専門チームが守っている。本体の小さな更新（セキュリティ修正）は、初期設定で自動的に適用される
2. 被害の原因の多くは、プラグイン・テーマ、更新されない運用、弱いパスワード、古いPHPやサーバーにある
3. 世界中で使われているぶん、攻撃者に狙われやすい。脆弱性が公表されてから攻撃が始まるまでの時間も短い
4. つまり危険かどうかは「WordPressかどうか」より、「誰が・どれくらい管理しているか」で決まる
5. 更新する人がいないサイトなら、WordPressを使わない（静的サイトにする）という選択肢もある

なぜ「WordPressは危険」と言われるのか

世界中で使われているから、狙われやすい

Webの技術の利用状況を調査しているW3Techsによると、2026年10月25日時点で、WordPressは全Webサイトの39.6%で使われています。CMS（ホームページを更新するためのシステム）を使っているサイトの中では、58.3%がWordPressです。

これだけ多くのサイトで使われていると、攻撃者にとっては「一つの弱点を見つければ、たくさんのサイトを一度に狙える」ことになります。WordPressが危ないのではなく、数が多いから狙われやすい、というのが実態に近いです。

脆弱性の大半は「プラグイン」と「テーマ」

WordPressのセキュリティ企業Patchstackが毎年公開しているレポート「State of WordPress Security in 2026」によると、2025年にWordPressの関連ソフト全体で見つかった新しい脆弱性は11,334件で、前の年より42%増えました。

その内訳は次のとおりです。

つまり、WordPress本体の脆弱性はごくわずかで、ほとんどは後から追加するプラグインやテーマで見つかっています。

公表から攻撃までが早い

同じレポートでは、脆弱性が公表されてから最初の攻撃が確認されるまでの時間（重みづけをした中央値）は5時間、影響の大きい脆弱性の約半分は24時間以内に悪用されていると報告されています。

また、46%の脆弱性は、公表の時点で開発者による修正が間に合っていなかったとされています。「更新が出たら入れる」だけでは防ぎきれない場面もある、ということです。

実際に被害が起きる原因

WordPress公式のセキュリティのページによると、WordPressには50人以上の専門家からなるセキュリティチームがあり、重要な修正は古いバージョンにも反映して、自動更新で届くようにしています。本体については、かなり手厚く守られているといえます。

それでも被害が起きるのは、多くの場合、次のような原因です。

10月のPHP2Shellのように、WordPressの外側（PHPやサーバー）の問題でサイトが危険になることもあります。詳しくは「PHPの重大な脆弱性「PHP2Shell」とは？」で解説しています。

WordPressを使うならやっておきたいこと

ここからは、WordPress公式の「Hardening WordPress（WordPressの強化）」のガイドや、IPA（情報処理推進機構）の「安全なウェブサイトの運用管理に向けての20ヶ条」も参考にしながら、やっておきたい対策をまとめます。

1. 本体・プラグイン・テーマを更新する

いちばん大切なのは、更新し続けることです。

• 本体の小さな更新（7.1.3のようなもの）は、セキュリティの修正が中心です。WordPress 3.7以降、初期設定で自動的に更新されるようになっているので、自動更新はオンのままにしておきましょう
• 大きな更新（7.2のようなもの）は、表示が変わることもあるため、バックアップを取り、できればテスト環境で確認してから更新するのが安全です
• プラグインの自動更新は、プラグインごとに設定できます。よく使われていて、更新が安定しているものは自動に、フォームや決済などサイトの重要な部分に関わるものは手動で確認してから、というように分けるのも一つの方法です

大きな更新の進め方は「WordPress 7.2で何が変わる？」で詳しく解説しています。

2. 使わないプラグイン・テーマは削除する

「停止」しているだけのプラグインも、ファイルはサーバーに残っています。WordPress公式のガイドでも、使っていないプラグインは削除するよう案内されています。テーマも、使っているもの（と、その親テーマ）以外は削除しておきましょう。

新しくプラグインを入れるときは、次の点を確認すると安心です。

• 最近も更新されているか（配布ページの「最終更新」）
• 今のWordPressのバージョンで動作確認されているか
• 利用者が多く、質問への対応が続いているか
• WordPress.orgなど、信頼できる配布元から入手しているか

何年も更新が止まっているプラグインは、脆弱性が見つかっても修正されないおそれがあります。代わりのプラグインを探すか、本当に必要かを見直しましょう。

3. 管理者アカウントを守る

• ログインIDに「admin」を使わない。公式のガイドでも、adminという名前は使わないよう案内されています
• 長く、使い回していないパスワードにする。パスワード管理ソフトを使うと楽です
• 二段階認証（2FA）を設定する。WordPress本体には入っていないため、プラグインなどで追加します
• 権限は必要な分だけにする。記事を書くだけの人は「投稿者」や「編集者」にして、管理者は最小限にします
• 退職した人や、作業が終わった外部の人のアカウントは削除する

10月のUpdraftCentralの件では、攻撃者が作ったアカウントが「編集者」として表示されることがあったと報告されています。ときどきユーザー一覧を見て、見覚えのないアカウントがないか確認しましょう。

4. ログイン画面への攻撃を減らす

ログイン画面には、パスワードを片っ端から試す攻撃（ブルートフォース攻撃）が日常的に来ています。

• ログインの試行回数を制限する。サーバー会社の機能や、セキュリティプラグインで設定できます
• 管理画面にアクセスできる場所を会社のIPアドレスだけに限定する、ログイン画面にもう一段階のパスワード（Basic認証）をかける、といった方法もあります
• ログインURLを変更する方法もありますが、これは攻撃の数を減らすための補助的な対策と考えましょう

制作者向けの補足として、公式のガイドでは、ログインの回数制限はできればWAF・CDNやWebサーバー側で行うほうがよい（プラグインだと大量の攻撃でPHPの負荷がかかる）とされています。また、/wp-admin/ 全体にBasic認証をかけると、Ajaxを使うプラグインが動かなくなることがあるため、wp-login.php に絞るなど範囲に注意が必要です。

5. PHPとサーバーのバージョンを確認する

WordPress公式が推奨しているのは、PHP 8.3以上、MySQL 8.0以上またはMariaDB 10.11以上です。PHP 7.4以上でも動きますが、公式は「サポートが終了したバージョンで、脆弱性にさらされるおそれがある」としています。

PHPの公式サポート期限は次のとおりです。

PHPのバージョンは、管理画面の「ツール → サイトヘルス → 情報 → サーバー」で確認できます。PHP 8.2以前の場合は、年内に8.3以降への移行を計画しましょう。

6. 常時SSL（https）にする

サイト全体を「https://」で表示できるようにしておきます。公式のガイドでも、管理画面の通信は暗号化するよう案内されています。最近は多くのレンタルサーバーで無料のSSLが使えます。

7. バックアップを取り、戻せるか試しておく

バックアップは、被害にあったときの最後の命綱です。

• ファイルとデータベースの両方を、定期的に保存する
• サーバーの外（別のクラウドストレージなど）にも保存する。サーバーごと被害にあうと、同じサーバー内のバックアップも使えなくなることがあります
• 何日分さかのぼれるかを確認する。改ざんに気づくのが遅れると、直近のバックアップがすでに改ざん後のものということもあります
• 年に一度くらいは、実際に元に戻せるか（復元テスト）を試しておく

8. WAF・セキュリティプラグインは「入れれば安心」ではない

WAF（Webアプリケーションファイアウォール）は、怪しい通信をサイトに届く前に止める仕組みです。サーバー会社が提供していることも多く、有効にしておく価値はあります。

ただし、Patchstackのレポートでは、一般的なホスティング会社の防御を調べた調査で、WordPress特有の脆弱性を狙った攻撃のうち、従来の防御で止められたのは12%だけだったと報告されています（別の調査では全体の26%）。

セキュリティプラグインも同じで、更新やパスワード管理の代わりにはなりません。「入れたから大丈夫」ではなく、更新を続けたうえでの追加の守りと考えましょう。

9. ファイルの権限と wp-config.php（制作者向け）

ここは制作者や保守担当者向けの内容です。公式のガイドでは、次のような設定が案内されています。

• ディレクトリは 755、ファイルは 644 を基本にする
• 設定ファイル wp-config.php は 400または440 にする
• wp-config.php に define( 'DISALLOW_FILE_EDIT', true ); を追加して、管理画面からPHPファイルを編集する機能をオフにする（アップロードされた不正なファイルは防げませんが、一部の攻撃を防げる場合があります）
• データベースのテーブル名の接頭辞を、初期値の wp_ から変更する

10. 使わない機能は止める（XML-RPCなど）

xmlrpc.php は、スマホアプリや外部サービスからWordPressを操作するための仕組みです。公式のガイドでは、使っていなければ無効にする、使う場合（Jetpackやスマホアプリなど）はWAFで制限し、アクセス回数を厳しく制限するよう案内されています。止める前に、使っている機能がないかを確認しましょう。

11. 改ざんに気づける仕組みを作る

• ファイルが変更されていないかを検知するツールや、サーバー会社の改ざん検知サービスを使う
• アクセスログ・エラーログを保存し、ときどき確認する
• 自分のサイトをときどき見て回る。見覚えのないページや、別のサイトに飛ばされるといった異常がないか確認します

被害の痕跡のチェック方法は「PHP2Shellは「更新して終わり」ではない」でも紹介しています。

12. 保守の担当を決める

意外と多いのが、「誰が更新するのか決まっていない」というケースです。

• WordPress・プラグイン・PHPの更新を誰が、どれくらいの頻度で行うか
• 脆弱性のニュースが出たとき、誰が確認するか
• サーバーやドメインの契約情報・ログイン情報がどこにあるか

社内で担当できる人がいない場合は、保守を外部に任せることも検討しましょう。

チェックリスト

WordPressが向かないケースもある

WordPressは、ブログやお知らせを自分たちでこまめに更新したいサイトには、とても便利な仕組みです。

一方で、次のようなサイトでは、WordPressの「管理し続けないといけない」という負担のほうが大きくなりがちです。

• 会社案内やお店の紹介など、内容をほとんど変えない
• 更新は年に数回で、更新する担当者もいない
• 保守にかける予算や時間をとりにくい

こうしたサイトでは、静的サイト（HTMLなどで作る、データベースやPHPを使わないサイト）という選択肢があります。ログイン画面やプラグインがないため、攻撃される入り口が少なく、更新の手間もほとんどかかりません。その代わり、内容の変更は制作者に依頼する形になることが多いです。

どちらが正解ということではなく、「誰が、どれくらい更新するか」で選ぶのがおすすめです。

C-TechLabにできること

C-TechLabでは、WordPressサイトと静的サイトのどちらも制作・保守しています。

• セキュリティの状況確認：WordPress・プラグイン・テーマ・PHPのバージョン、不要なアカウントやプラグインがないかを確認し、優先して対応すべきことをお伝えします
• 月額の運用保守：本体・プラグインの更新、バックアップ、改ざんのチェックを継続して行い、脆弱性のニュースが出たときもすばやく対応します
• PHPバージョンアップ対応：PHP 8.2以前のサイトを、事前の確認とバックアップを行ったうえで8.3以降へ切り替えます
• ホームページ制作：更新の頻度や体制に合わせて、WordPressか静的サイトかをご提案します。「今のWordPressサイトを、保守の手間が少ない静的サイトに作り直したい」というご相談もお受けしています

「WordPressのままでいいのか迷っている」という段階でも大丈夫です。代表エンジニアが直接、状況を伺います。詳しくはホームページ運用保守とホームページ制作のページもご覧ください。

よくある質問

WordPressはセキュリティ的に危険ですか？

いいえ、WordPressそのものが特別に危険というわけではありません。ただし、世界中で使われているぶん攻撃者に狙われやすく、使い方や管理のしかたによっては被害にあいやすくなるため、危険かどうかはWordPressかどうかより、誰がどれくらい管理しているかで決まります。

WordPressのサイトが被害にあう主な原因は何ですか？

被害の原因の多くは、プラグイン・テーマ、更新されない運用、弱いパスワード、古いPHPやサーバーです。Patchstackのレポート「State of WordPress Security in 2026」によると、2025年に見つかったWordPress関連の新しい脆弱性11,334件のうち約91%がプラグイン、約9%がテーマで、WordPress本体は6件でした。

セキュリティプラグインやWAFを入れれば安心ですか？

いいえ。WAFは有効にしておく価値がありますが、WAFやセキュリティプラグインは更新やパスワード管理の代わりにはなりません。Patchstackのレポートでは、一般的なホスティング会社の防御を調べた調査で、WordPress特有の脆弱性を狙った攻撃のうち従来の防御で止められたのは12%だけだったと報告されています。

WordPressで最低限やっておくべきセキュリティ対策は何ですか？

いちばん大切なのは、WordPress本体・プラグイン・テーマを更新し続けることです。あわせて、使わないプラグインやテーマの削除、ログインIDにadminを使わない・長く使い回していないパスワード・二段階認証といった管理者アカウントの保護、PHP 8.3以上への移行、サーバーの外にも保存するバックアップを行っておくと安心です。

更新する担当者がいなくても、WordPressを使い続けるべきですか？

内容をほとんど変えず、更新する担当者もいないサイトであれば、WordPressを使わずに静的サイトにするという選択肢があります。静的サイトはログイン画面やプラグインがないため攻撃される入り口が少なく、更新の手間もほとんどかかりませんが、内容の変更は制作者に依頼する形になることが多いです。

参考情報

• W3Techs「Usage Statistics and Market Share of Content Management Systems」（2026年10月25日時点）
• Patchstack「State of WordPress Security in 2026」
• WordPress.org「Security」
• WordPress.org「Requirements」
• WordPress Developer Resources「Hardening WordPress」
• WordPress Developer Resources「Brute Force Attacks」
• WordPress Developer Resources「Upgrading WordPress」
• PHP「Supported Versions」
• IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」