【危険】WordPressの脆弱性とは。リスクをなくすためにWordPressを使わないAIを活用したHP制作・運用も解説

自社サイトを守るため、WordPressの脆弱性に対しては初動の迅速さが何よりも重要です。被害を防ぐために、まずは以下の3つの対応を最優先で実施してください。

・WordPress本体やプラグインのバージョンと更新状況の確認 ・アップデートを実施する前の、確実なバックアップデータ取得 ・サイトに異変を感じた場合の速やかな専門家への相談

これら3つの初期対応を確実に行うことで、致命的なトラブルを未然に防ぎ、冷静な対処が可能になります。

WordPressの脆弱性が心配な場合、まず出すべき結論は「自社サイトのバージョンと更新状況の確認」です。2026年7月に公表された「wp2shell（CVE-2026-60137 等）」のニュースを見て、自社は大丈夫かと不安を感じているWeb担当者様も多いでしょう。実際に、米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、2026年7月21日にこの脆弱性をKEV（悪用が確認済みの脆弱性）カタログへ追加しており、すでに現実のサイバー攻撃に悪用されている深刻な脅威となっています。

しかし、WordPressというシステム自体が一律に危険なわけではありません。真のリスクは「更新されないまま放置された状態」や「保守体制が不明確なこと」にあります。

本記事では、脆弱性の確認方法と基本対策に加え、継続運用の判断基準から「Notion×AI駆動型HP」への移行という第三の選択肢までを分かりやすく解説します。

まず確認：WordPressの脆弱性が心配なら、バージョンと更新状況を確認する

【結論】自社サイトが脆弱性の影響を受けるかを判断するためには、現在のバージョンを正確に把握し、適切な手順で更新を行うことが第一歩となります。特に新たな脆弱性が公表された直後は不安になりがちですが、焦って無計画な操作を行うのはかえってリスクを伴います。「自動更新を有効にしているから大丈夫」と過信せず、まずは冷静に管理画面へログインして実際の更新状況を目視で確認することから始めましょう。

2026年7月公表の「wp2shell」で影響を受けるバージョン

2026年7月に公表され話題となった脆弱性「wp2shell」において、影響を受けるとされるWordPress本体のバージョンと、それぞれアップデートすべき修正版は以下の通りです。

• 6.9.0 〜 6.9.4 （2件の脆弱性の連鎖による影響を受けます）

→ 【修正版：6.9.5】へ更新してください

• 7.0.0 〜 7.0.1 （2件の脆弱性の連鎖による影響を受けます）

→ 【修正版：7.0.2】へ更新してください

• 6.8.0 〜 6.8.5 （CVE-2026-60137のみの影響を受けます）

→ 【修正版：6.8.6】へ更新してください

• WordPress6.8以前のバージョン

→ 今回の「wp2shell」の影響は受けませんが、過去の重大な脆弱性が残存しているため最新版への更新が必要です

もし自社サイトがこれらのバージョンに該当する場合は、速やかに最新版へのアップデートなどの対策を検討する必要があります。

なお、公式発表では「6.8より前のバージョンは今回の影響を受けない」とされていますが、これはあくまで今回公表された2件の脆弱性に限った話であり、決して「古いバージョンなら安全である」という意味ではありません。

古いバージョンには過去に発見された別の重大な脆弱性が残存している可能性が高いため、常に最新のセキュリティ状態を保つことが基本となります。

自動更新を過信せず、管理画面で更新結果を確認する

WordPressにはマイナーアップデートを自動で行う機能が備わっていますが、これを過信するのは禁物です。サーバーの環境や設定によっては自動更新が失敗しているケースも珍しくありません。

制作会社へ保守を委託している場合も含め、まずはWordPressの管理画面（ダッシュボード）にログインし、「更新」メニューから現在のバージョンと未更新の項目がないかを目視で確認しましょう。

また、実際に本番環境のアップデートを行う際は、万が一の不具合に備えて、必ず事前に完全なバックアップを取得できているかを確認してから実行することが鉄則です。

制作会社へ保守を任せきりの場合、契約にセキュリティ更新が含まれていないこともあるため、早急に保守担当者へ状況を問い合わせることを推奨します。

WordPressの脆弱性とは、攻撃に悪用され得るソフトウェアや設定の弱点

【結論】脆弱性とは、プログラムの設計ミスや予期せぬ不具合などから生じる「システムのセキュリティ的な弱点」を指します。WordPressを利用する上で注意すべきなのは、この弱点がWordPress本体（コア）だけに限らないという点です。あとから追加した拡張機能（プラグインやテーマ）や、基盤となるサーバー環境、さらには運用上の設定に至るまで、Webサイトを取り巻く環境全体に潜むリスクとして理解する必要があります。

WordPress本体の脆弱性

WordPressはプログラムで構成されたソフトウェアである以上、設計上のミスや予期せぬ不具合（バグ）を完全にゼロにすることは困難です。本体の脆弱性とは、WordPressそのもののソースコードに潜むセキュリティ上の弱点を指します。開発チームによって日々改修が行われ、脆弱性が発見された際には修正版がリリースされます。

プラグイン・テーマの脆弱性

実際のWebサイト運営において、より注意すべきなのがプラグイン（拡張機能）やテーマ（デザインテンプレート）の脆弱性です。これらは世界中の様々な開発者によって作られており、品質やセキュリティ基準もまばらです。更新が長期間ストップしているプラグインを使い続けることは、攻撃者に隙を与える大きな要因となります。

サーバー・PHP・アカウント・運用上の弱点

プログラムのコードが持つ脆弱性と、運用上の不備を混同しないことも重要です。たとえWordPressを最新に保っていても、基盤となるサーバーOSやPHPのバージョンが古ければリスクが生じます。また、推測されやすい単純なパスワードの使用、退職者のアカウントの放置といった「人的・運用上の弱点」も、悪意ある第三者に付け込まれる典型的な経路となります。

WordPressは脆弱性が多く危険？危険なのは更新されない運用

【結論】WordPress自体が極端に危険なわけではなく、真の脅威は「セキュリティ更新が滞ったまま運用を放置すること」にあります。

利用サイトと拡張機能が多く、攻撃者の標的になりやすい

WordPressは全世界のWebサイトで広く利用されているCMSの一つです。その普及率の高さゆえに、攻撃者にとって「ひとつの脆弱性を見つければ、世界中の多くのサイトを効率よく狙える」という格好の標的になりやすい側面があります。脆弱性の報告数が多いのは、それだけ監視の目が向けられ、広く使われていることの裏返しでもあります。

オープンソースであること自体が危険なのではない

WordPressはソースコードが無料で公開されている「オープンソース」です。「ソースコードが見えるから攻撃されやすいのでは」と誤解されがちですが、オープンソースであること自体が危険なわけではありません。世界中のエンジニアがコードを監査し、問題があれば即座に修正パッチが提供されるため、むしろ透明性は高いと言えます。問題なのは、その修正パッチ（アップデート）を適用せずに放置することです。

CMSを変えてもセキュリティ運用はなくならない

「WordPressは危険だから別のCMSに変えれば安全で保守も不要になる」という極端な考え方には注意が必要です。どのようなシステムやCMSを採用したとしても、インターネット上に公開し続ける限り、形を変えてセキュリティ対策や運用保守は必ず求められます。WordPressを一律に避けるのではなく、自社の体制で「継続的な保守運用が可能かどうか」を冷静に判断することが重要です。

WordPressの脆弱性を放置すると、改ざん・情報漏えい・停止につながる

【結論】脆弱性の放置は、自社サイトの被害に留まらず、顧客や取引先を巻き込む深刻なビジネスリスクに直結します。単にWebサイトが見られなくなるだけでなく、機密情報の漏えいや意図しない加害行為への加担など、企業の信用問題にまで発展するケースも少なくありません。最悪の事態を防ぐためにも、具体的にどのような被害が起こり得るのかを事前に知り、対策の優先度を上げておく必要があります。

管理画面への不正アクセス・サイト乗っ取り

脆弱性を突かれると、管理者権限を奪取される恐れがあります。攻撃者にパスワードを勝手に変更されてしまうと、正規の管理者が一切ログインできなくなり、サイトを完全にコントロールされる「乗っ取り」へと発展します。一度乗っ取られると、悪意のあるコンテンツの配信などに悪用される危険性が高いため、不審な管理者アカウントの追加などがないか、早期発見に努めることが非常に重要です。

サイト改ざん・マルウェア設置・攻撃の踏み台化

ページの内容を書き換えられるだけでなく、訪問者を気付かないうちにスパムサイトへ誘導（リダイレクト）したり、マルウェア（悪意あるプログラム）を仕込まれたりします。さらに深刻なのは、乗っ取られた自社のサーバーが、他社へ大量のスパムメールを送信するなどの「サイバー攻撃の踏み台」として悪用されるケースです。これにより、自社が知らず知らずのうちに「加害者」となってしまい、取引先や顧客からの損害賠償請求に発展するリスクも少なくありません。

個人情報・問い合わせ情報の漏えい

データベースに侵入されれば、お問い合わせフォームから送信された顧客の氏名やメールアドレス、取引先情報などの機密データが外部に流出する重大な事故を引き起こします。このような個人情報の漏えいは、企業の社会的信用を根底から失墜させるだけでなく、法的な対応や損害賠償に発展する危険性も孕んでいます。万が一の被害を最小限に抑えるためにも、平時から自社サイトのシステム内に「どのような情報（保持データ）」が「どれくらいの期間（保存期間）」蓄積されているのかを正確に把握し、不要なデータは定期的に削除する運用が不可欠です。

サイト停止・復旧費用・信用低下

被害を受けた場合、原因究明と復旧のために長期間サイトを閉鎖せざるを得ず、その間の営業機会を大きく損失することになります。また、専門業者への高額な復旧費用の支払いに加え、関係各所への謝罪や説明対応といった目に見えないコストも重くのしかかります。結果として、企業としての社会的信用の失墜という、日々の更新作業の負担とは比較にならないほど取り返しのつかないダメージを受けることになります。

自社のWordPressに脆弱性がないか確認する4つの方法

【結論】ダッシュボードでの定期的な自己点検と公式情報の収集、そしてサイトの重要度に応じた専門家への相談を組み合わせることが確実な対策です。

1. 管理画面で本体・プラグイン・テーマのバージョンを確認する

まずは自社サイトのダッシュボードへログインし、「更新」メニューを開きます。WordPress本体、導入しているプラグイン、およびテーマに新しいバージョンがリリースされていないかを確認します。アップデートの通知が溜まっている場合は、脆弱性を抱えた古いバージョンを使用している可能性が高いと言えます。

2. 「ツール」→「サイトヘルス」で重要項目を確認する

WordPress標準機能である「サイトヘルス」も有効な点検ツールです。左側メニューの「ツール」から「サイトヘルス」を選択すると、セキュリティに関する致命的な問題や改善すべき推奨項目が可視化されます。不要なプラグインの削除や、使用しているPHPバージョンの古さなどをここで一目で把握できます。ただし、ここで問題が検出されなかったとしても、それが「サイトの脆弱性がゼロである」「まだ侵害されていない（未侵害）」という証明にはならない点には注意が必要です。

3. IPA・JVN iPedia・WordPress.org・ホスティング会社の情報を照合する

自社で使用しているプラグイン等の名前に「脆弱性」というキーワードを加えて、定期的に情報を検索する習慣をつけましょう。IPA（情報処理推進機構）や脆弱性対策情報データベース（JVN iPedia）、WordPress公式サイト、利用中のレンタルサーバー会社の障害・メンテナンス情報を確認し、自社環境と照らし合わせて危険がないかを確認します。

4. 重要情報を扱うサイトは専門家の脆弱性診断を検討する

顧客情報や決済情報など、万が一にも漏えいが許されない重要なデータを扱っている場合は、自己点検だけでは不十分なケースがあります。その際は、セキュリティを専門とする企業の「脆弱性診断サービス」の利用を検討してください。プロの目線でシステム全体の弱点を網羅的に洗い出すことが可能です。なお、株式会社INFLUはセキュリティ専門会社ではないため同サービスは提供しておりませんが、一般的な対策の選択肢の一つとして専門機関の利用を推奨しています。

WordPressの脆弱性に備える7つの対策

脆弱性からサイトを守るためには、アップデートの徹底だけでなく、不要ファイルの削除からWAFの導入、運用体制の構築まで、システムとルールの両面で防御を固めることが不可欠です。

1. 復元できるバックアップを確認してから更新する

アップデート作業自体が原因で、サイトの表示崩れやシステムエラーを引き起こすリスクがあります。更新ボタンを押す前に、必ずサーバー全体とデータベースの完全なバックアップを取得し、「いざとなれば元の状態に復元できる」ことを確認してから作業を進めてください。

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

脆弱性対策の基本は、ソフトウェアを最新の安全な状態に保つことです。WordPress本体だけでなく、導入しているプラグイン、使用しているテーマ、そして基盤となるPHPのバージョンまで、全体を定期的にアップデートしていく必要があります。

3. 使っていないプラグイン・テーマ・アカウントを削除する

「停止」しただけのプラグインやテーマにもコードは残るため、攻撃対象となるリスクがあります。使用していない拡張機能はサーバー上から「削除」するのが鉄則です。同様に、退職した担当者のアカウントや不要な管理者権限も速やかに削除しましょう。

4. 強固なパスワード、二要素認証、最小権限を設定する

パスワードの使い回しや「admin」などの推測されやすいIDは厳禁です。パスワードを強固なものにしたうえで、ログイン時の二要素認証（ワンタイムパスワード等）を導入します。また、更新作業のみを行うスタッフには「管理者」ではなく「編集者」「投稿者」などの最小権限を付与してください。

5. WAFやアクセス制限で防御層を追加する

サーバー側でWAF（Web Application Firewall）を有効にすることで、脆弱性を狙った不審な通信を遮断しやすくなります。ただし、WAFはあくまで外部からの攻撃を防御する「盾」であり、脆弱性そのものを直すわけではないため、アップデートの代わりにはなりません。同様に、定期的なバックアップも「万が一の際の事後復旧策」であり、侵入そのものを防ぐ対策ではない点に注意が必要です。

6. ログとファイル変更を監視する

万が一侵入された際にいち早く気づけるよう、誰がいつログインしたか、重要なファイルが書き換えられていないかを監視する仕組みを取り入れます。セキュリティプラグインを活用することで、不正な変更が行われた際に管理者へ通知を送ることが可能です。

7. 更新担当・頻度・緊急時の連絡先を決める

技術的な対策と同等に重要なのが「運用ルールの明確化」です。社内の誰が、どの頻度でアップデートを確認するのか。制作会社が保守を行う場合、どこまでをカバーしてくれるのか。そして異変が起きた際は誰に連絡するのかを取り決めておきましょう。

「WordPressの脆弱性が悪用されました」と表示されたら、更新だけで終わらせない

【結論】被害が疑われる場合、慌ててアップデートだけを行うのは危険です。まずは被害の拡大を防ぐために隔離と保全を行い、根本原因を排除してから復旧させます。

サイトを隔離し、ログや現状を保全する

改ざんや不正アクセスの警告を受けた場合、真っ先にサイトをメンテナンスモードに切り替えるか、特定のIPアドレス以外からのアクセスを制限し、サイトをネットワークから隔離します。被害状況の調査に不可欠なアクセスログや改ざんされたファイルは、消去せずに証拠として保全してください。

安全な端末から認証情報を変更する

パソコン自体がマルウェアに感染し、入力したパスワードを盗み取られている可能性も考慮すべきです。必ずセキュリティ対策が施された「安全な別の端末」を使用して、WordPressの管理者パスワードやFTP、データベースなどのあらゆる認証情報を直ちに変更します。

侵入経路を確認し、クリーンな状態から復旧する

攻撃を受けた状態で単にWordPressをアップデートしても、すでに仕込まれたバックドア（裏口）などの不正ファイルは残ったままです。アクセスログから侵入経路を特定し、感染前の安全なバックアップデータを用いてクリーンな状態に復元してから、脆弱性を塞ぐアップデートを実施する必要があります。

WordPressの脆弱性対策は、一度更新しても終わらない

【結論】WordPressは複数のパーツが組み合わさって動くシステムであり、運用を続ける限り、継続的なセキュリティ管理の責任から逃れることはできません。

WordPressは複数の構成要素を継続管理する仕組み

前述の通り、WordPressは本体（コア）、テーマ、数々のプラグイン、そしてPHPやデータベースといったサーバー環境など、多くの要素が連動して動いています。これらのうち、どれか一つでも古いまま放置されれば脆弱性となり得るため、常に全体の互換性を確認しながら継続的に管理していく必要があります。

機能追加が、管理対象と攻撃面の増加につながる

「便利だから」と安易にプラグインを追加していくことは、そのまま「管理しなければならない対象」を増やし、攻撃者に狙われる「攻撃面（アタックサーフェス）」を広げることを意味します。機能の利便性と引き換えに、セキュリティリスクも高まっている事実を認識しなければなりません。

保守を外注しても、責任範囲が見えなければ判断できない

制作会社と「保守契約」を結んでいても、その内容が「サーバー障害の対応のみ」で、WordPressのセキュリティ更新は対象外となっているケースが散見されます。外注しているから安全と思い込まず、契約上の責任範囲や具体的な作業内容が見えていなければ、自社のリスクを正しく判断することはできません。

WordPress管理を脱却するためのHP制作（Notion×AI駆動型HP）

更新が止まらない形へ移す考え方は、下記をご覧ください。

こちら

【結論】WordPressに機能と保守の負担を足し続ける運用から脱却し、社内情報の管理と公開サイトを切り離すのが「Notion×AI」という新たな運用構成です。

Notionでページ・記事・更新指示を一元管理する

WordPress上で直接コンテンツを編集するのではなく、クラウド型のワークスペース「Notion」を活用し、社内の情報管理とWebサイトの原稿を一元化します。「社内で確認・承認された最新の正しい情報（SSOT：Single Source of Truth）」が常にNotion上に集約されるため、情報更新の漏れやズレを防ぐことができます。

AIが制作・修正・改善案を支援し、人が確認する

Notionに蓄積された情報をもとに、AIがページのコーディング、文章の推敲、SEO対策の改善案などを強力にアシストします。人間はゼロから作るのではなく、AIが生成した内容を「確認・微調整」する役割に特化できるため、制作と運用のスピードが劇的に向上します。

公開サイトをWordPressから切り離し、管理対象を減らす

最大のメリットは、Notion上のデータをCloudflareなどを経由して「静的なWebサイト」として配信できる点です。これにより、公開サイト側からWordPressのような動的システムやデータベースを切り離すことができ、攻撃対象となる管理要素が激減します。※ただし、Notionアカウントや配信システムの権限管理は残るため「脆弱性が完全にゼロになる」わけではない点に留意し、適切なアカウント管理は引き続き必要です。

株式会社INFLUがWordPressからAI×Notion管理へ移した自社事例

https://www.youtube.com/watch?v=p1lbQg7v-l4

【結論】弊社代表の水戸亮太が実践した「HPをAI×Notion管理に移行」した事例では、煩雑なWordPress保守から解放され、運用コストの大幅削減とマーケティング速度の向上を両立しました。

ランコストが0

弊社の自社事例において、従来のWordPress運用で重荷になっていた「セキュリティアップデートの人件費」「専用サーバーの維持費」「保守代行の月額費用」がなくなり、弊社代表がX（旧Twitter）でも発信している通り、Webサイト維持のための「ランコストが0」になりました。

※これはあくまで株式会社INFLUの事例に限定した表現であり、独自ドメインの維持費用や、社内で利用するAIツール・Notionのプラン等の費用は引き続き発生します。しかし、WordPress特有の保守・システム運用費という観点では、劇的なコスト削減を実現しています。

※Cloudflare（サーバーの役割）→ほぼタダ（無料枠）（年10ドル）

ドメインのみ支払いがある

自社事例で明らかにする4項目

実際に株式会社INFLUが自社サイトを移行して明らかになった変化は以下の通りです。

• 移行前： 頻繁なWordPress本体やプラグインの更新、不具合時の原因切り分けに社内のリソースが奪われ、純粋なコンテンツ制作に集中しづらい状況でした。
• 移行後： Notion上でテキストと構成を更新するだけで、自動的かつ安全に静的サイトが更新される体制が整いました。
• コストの変化： 外部委託費とサーバー維持費が削減され、浮いた予算を新たなWebマーケティング施策に回せるようになりました。
• マーケティングの速さの変化： アイディアをNotionに書き込み、AIで形にするまでのリードタイムが短縮され、市場の変化に合わせたスピーディーなサイト改善（PDCA）が可能になりました。

まとめ：緊急更新の先に、WordPressを使い続ける前提も見直す

【結論】脆弱性の確認と対策は一度きりでは終わりません。継続的な保守が負担となっている場合は、次世代のWeb構築手法へ移行して運用主導権を取り戻す選択肢もご検討ください。

自社のWordPressのバージョンを確認し、安全にアップデートすることは目先の危機を回避する重要な第一歩です。しかし、そこから先も「終わりのない更新運用」は続いていきます。

もし、現在の保守負担に対して活用できている機能が見合っておらず、更新作業そのものが滞りがちなのであれば、リスクを抱えながらWordPressを使い続ける前提自体を見直す時期かもしれません。「Notion×AI駆動型HP」のように、公開側と管理側を分離する次世代の運用手法も比較検討のうえ、自社にとって最適なIT戦略を描いていきましょう。

WordPressをこのまま続けるべきか、Notion×AI駆動型HPへ作り直すべきか迷っている場合は、現在の保守内容と必要機能の棚卸しからご相談ください。