WordPressの脆弱性とは—公表情報から自分のサイトへの影響を判断する方法

WordPressの脆弱性とは、WordPress本体やプラグイン、テーマなどに存在するセキュリティ上の弱点です。脆弱性が公表されてから修正版を自分のサイトへ適用するまでの間は、その弱点が残った状態になります。「脆弱性が見つかりました」という知らせを受け取っても、それが自分のサイトに関係あるのか、どれくらい急ぐべきなのか、判断がつかない方は少なくありません。「WordPressは脆弱性が多くて危ないのでは」という不安から調べ始めた方もいるでしょう。

この記事では、脆弱性とは何か、公表された情報を自分のサイトに当てはめて読む方法、修正版が出てからどれくらい急ぐべきかを判断する軸、そして「最新に保つ」という対策がどこまでで、どこから先は別の判断が必要になるのかを扱います。対策の一覧や、すでに被害が出た後の復旧の手順は、この記事では扱いません。

この記事を読めば、公表された脆弱性情報を自分のサイトに当てはめ、対応が必要か、どの程度急ぐべきかを判断するための見方が分かります。

脆弱性はソフトウェアの弱点です。サイト管理者にとって重要なのは、修正版が公開された後、自分のサイトへその修正を適用するまでの期間です。

脆弱性とは、ソフトウェアの内部に存在する弱点そのものを指す言葉です。脆弱性が存在していても、必ず被害が発生するわけではありません。ただし、修正版が公開されても、自分のサイトに適用していなければ脆弱性は残ります。

弱点が見つかる → 開発者が修正する → 修正版が公開される → 利用者が自分のサイトへ適用する、という流れで対応が進みます。修正版を適用するまでは、その脆弱性がサイトに残った状態です。

WordPressは、本体・プラグイン・テーマという複数の部品を組み合わせて動くソフトウェアです。弱点がどの部品で見つかるかによって、直す人も、修正版が配布される仕組みも変わってきます。この違いについては後ほど扱いますが、この記事で重視するのは、どの部品に脆弱性があるかだけでなく、公表された修正版を自分のサイトへいつ適用するかという判断です。

修正版が公開されると、利用者はその脆弱性を修正できるようになります。しかし、一方で、修正版の公開には別の側面もあります。修正版が公開されるということは、同時に「ここに弱点があった」という事実そのものが外部に知られることでもあります。修正の前後でソースコードのどこが変わったかを比較すれば、修正された箇所から脆弱性の内容をある程度推測することができてしまいます。

つまり、修正版が公開されたからといって、自分のサイトが自動的に修正済みになるわけではありません。修正版が公開されたら、自分のサイトへ適用されているかを確認する必要があります。公表後は脆弱性の情報が広く知られる可能性があるため、未更新の状態を長く続けないことが重要です。

公表後にどの程度急いで対応すべきかについては、この先で具体的に扱います。ここでは、修正版の公開が「対応完了」ではなく「適用確認の開始」である、という捉え方だけを押さえておいてください。

WordPressだけに脆弱性が存在するわけではありません。見つかる脆弱性の多くは、本体ではなく、利用者が追加で入れたプラグインの側にあります。重要なのは、WordPressを使っていること自体ではなく、導入している本体・プラグイン・テーマを把握し、必要な更新を継続しているかどうかです。

WordPressは、本体だけで完結するソフトウェアではなく、多くのプラグインやテーマを組み合わせて動いています。セキュリティ関連の事業者が発行している年次のレポートによれば、新しく見つかる脆弱性の多くは、本体そのものよりも、後から追加するプラグインやテーマの側で見つかっているとされています。こうしたレポートは公的機関による統計ではなく、セキュリティ事業者による民間の調査であることには注意が必要です。

この偏りは、本体とプラグインとで「直す人」も「配布の仕組み」も異なることの裏返しでもあります。WordPress本体はコミュニティが一括して開発・配布していますが、プラグインは開発者ごとに更新の頻度も体制もばらばらです。開発が活発なものもあれば、ほとんど手が入らないものもあります。つまり、自分のサイトに関係する脆弱性情報の量は、WordPressそのものの問題というより、何を追加で入れているかによって変わってくる、ということです。

だからといって「本体は安全だから気にしなくてよい」という結論にはなりません。本体でも重大な脆弱性が見つかることはあります。その実例はこの先で扱います。また、WordPressを支えるPHPやサーバーといった土台の部分にも別の弱点がありえますが、これは本記事では扱いません。

実務上まず重要なのは、脆弱性の種類を暗記することではなく、自分のサイトでどのプラグインやテーマを使用しているかを把握することです。使用中の部品を把握して初めて、公表された脆弱性の知らせが自分のサイトに関係するかどうかを、当てはめて考えられるようになります。

脆弱性は、WordPressに限らず、あらゆるソフトウェアで見つかります。国内の脆弱性対策情報のデータベースにも、WordPress以外のソフトウェアの脆弱性が継続的に登録されており、これはWordPressだけの現象ではありません。

つまり、使うCMSやシステムを別のものに乗り換えたとしても、弱点が見つかり、修正版が出て、それを反映するという一連の出来事から離れられるわけではありません。どのソフトウェアを選んでも、脆弱性への対応は必要です。問われているのは、どの仕組みを選ぶかではなく、見つかった脆弱性に修正版を適用する運用が、自分のサイトで実際に回っているかどうかです。

ここまで見てきたとおり、脆弱性そのものはWordPressに限らず存在し、見つかる場所の多くは追加した部品の側にあります。ここから導かれるのは、危ないかどうかを分けるのはWordPressを使っているかどうかではなく、使っていないプラグインが残っていないか、修正版が出たときにそれをきちんと反映する流れがあるか、という運用状況です。

保守の現場でも、特別なことをするというより、標準的な対応を継続することが、サイトをある程度守ることにつながると捉えられています。特別な工夫よりも、当たり前の対応を積み重ねているかどうかが問われる、という感覚です。対策そのものが不要というわけではなく、何を放置しないかという中身の方が問われている、ということです。

なお、そもそも対策は必要かという問いへの答えは、ここまでで出ています。対策は必要です。問題は、その対策のうち何を放置しないかという中身の方にあります。ここから先は、脆弱性の情報をどう読み、どれくらい急ぐべきか、そして「最新に保つ」だけで足りない場面はどこにあるのかを見ていきます。

脆弱性の情報を受け取ったら、まず「影響するバージョン」「悪用の条件」「修正されたバージョン」の3つを見て、自分のサイトで使用中のバージョンと突き合わせます。修正版が出ていても、自分のサイトへ適用されたかどうかは別に確かめる必要があります。

脆弱性の情報が公表されたとき、内容を隅々まで読み込む必要はありません。見るべきなのは次の3点です。

2026年7月、WordPress本体に脆弱性が見つかり、7.0.2として修正版が配布されました（WordPress.org「WordPress 7.0.2 Release」・2026年7月17日公開／2026年9月19日確認）。これを受けて、情報処理推進機構（IPA）も同月、該当する脆弱性（CVE-2026-60137、CVE-2026-63030）について注意喚起を公表しています（IPA「WordPressの脆弱性対策について」・2026年7月22日公開／2026年9月19日確認）。この注意喚起では、影響を受けるバージョンの範囲、悪用に必要な条件、修正されたバージョンが示されており、公表された情報をどう読むかの手本になります。

3つのうち、特に見落とされやすいのが「悪用の条件」です。同じ「脆弱性」という言葉でも、管理者としてログインした状態でなければ悪用できないものと、ログインすらしていない誰でも実行できてしまうものとでは、急ぐ度合いがまったく異なります。英語の条件表記をそのまま訳そうとする必要はありません。「ログインが要るかどうか」という一点で読み替えれば十分です。

逆に、影響するバージョンに、自分のサイトで使用中のバージョンが含まれていなければ、その知らせについては急ぐ必要はありません。公表された情報のすべてに反応する必要はなく、まず自分のサイトが該当するかどうかを見極めることが先決です。

公表された情報の「影響するバージョン」を確認したら、次は自分のサイトで実際に使用している本体・プラグイン・テーマのバージョンを突き合わせます。バージョンは、管理画面の「更新」の画面や、プラグイン一覧の各項目の表示から確認できます。ここで見るのは、影響を受ける範囲に自分のサイトで使用中のバージョンが入っているかどうかだけであり、脆弱性を探す方法そのものを網羅的に調べる必要はありません。

自分のサイトに脆弱性がないか手軽にチェックしたい場合や、自分でバージョンを照合するのが難しい場合は、サイトの状態を確かめる無料URLセキュリティ診断を利用する方法もあります。

なお、WordPress本体を支えているPHPという土台の部分にも、別のバージョン管理があります。この記事ではPHPのバージョンそのものは扱いませんが、サイトで使っているPHPのバージョンを確かめる方法で確認できます。

「修正版が出た」「自動で更新される設定になっている」ということと、「自分のサイトに実際に反映されている」ことは別の話です。IPAの注意喚起自体も、更新が適用されたかどうかを利用者自身が確認するよう求めています。ここで確かめるのは、先ほど見た自分のサイトで使用中のバージョンが、修正済みのバージョン以上になっているかどうか、という一点だけです。

もし、すでに表示や検索結果に異常が出ている場合は、脆弱性への該当確認より先に、状態の確認と復旧が必要な段階に入っています。手順や料金についてはこの記事では扱いませんが、すでに異常が出ている場合の緊急復旧サービスをご利用ください。

修正版（セキュリティパッチ）が出たら、攻撃条件が限定されていない脆弱性ほど、優先して修正版を適用します。修正版の公開から、注意喚起や実際の悪用の確認までは、日単位で進むことがあります。

2026年7月の実例で、修正版の公開から注意喚起までがどれくらい短期間で進みうるかを見てみます。WordPress本体の修正版（7.0.2）が配布されたのは2026年7月17日です（WordPress.org「WordPress 7.0.2 Release」）。これを受けて、情報処理推進機構（IPA）が該当する脆弱性について注意喚起を公表したのは同月22日でした。修正版の配布から国内の注意喚起までは、日単位、具体的には1週間に満たない期間で進んだことになります。

この注意喚起では、該当する脆弱性を実証するコードがすでに公開されていることにも触れられています。修正版が出た時点で、脆弱性を悪用する手がかりも同時に世に出ている、ということです。修正版の公開が「弱点があったことを知らせることでもある」と述べたことが、そのまま起きた形といえます。

なお、この実例はあくまで一つの参考です。すべての脆弱性がこの速さで進むわけではありませんし、バージョンごとの対応手順としてこの記事で扱うものでもありません。「公表から数日というスピード感がありうる」という感覚をつかむための一例として見てください。

修正版が出てから自分のサイトに反映するまでの時間は、脆弱性が未修正のまま残っている時間でもあります。したがって、急ぐかどうかは、先ほど見た悪用の条件（ログインが要らないものほど急ぐ）と、その部品が実際に自分のサイトで使われているかどうかの、掛け合わせで決まります。

近年の実例では、上で見たとおり、公表から注意喚起までが数日という近さで進むことがあります。すべての更新を同じ緊急度で扱う必要はありませんが、影響するバージョンに自分のサイトで使用中のバージョンが入っており、かつ攻撃条件が限定されていない場合は、次の定期的な更新作業まで先送りせず、優先して反映することが望まれます。

急かす言葉に反応するのではなく、悪用の条件と公表後の経過時間という2つの軸で機械的に判断できる、という点が重要です。この先、実際にどう更新するかという手順そのものについては、この記事では扱いません。ここまでで押さえておきたいのは、急ぐかどうかの判断が「悪用の条件」と「公表後の経過時間」の組み合わせで決まる、という軸です。

「最新に保つ」は対策の出発点ですが、自動更新が届かない部品、修正版がまだ無い弱点、修正版がもう出ない部品では、それだけでは対応できません。

WordPress本体には、小さな更新（マイナーアップデート）は自動で反映され、大きな更新（メジャーアップデート）は手動で行うという基本の仕組みがあります。この考え方は、サイト管理者が続けるセキュリティ対策ですでに説明されているとおりです。

ただし、重大な脆弱性が見つかった場合には、この原則に対して例外的な措置が取られることもあります。2026年7月の7.0.2では、影響するバージョンに対して強制的な更新の仕組みが働きました。これは日頃の「マイナーは自動・メジャーは手動」という原則を覆すものではなく、重大な場合に限って取られる例外的な措置と理解してください。

なお、WordPress本体はその後も更新されており、2026年8月19日に公開された7.1は新しい機能を中心としたバージョン、2026年9月17日に公開された7.1.1はセキュリティ修正を含むバージョンです（WordPress.org 公式リリース情報・2026年9月19日確認）。バージョンの新しさそのものを安全の指標にせず、配布のたびに内容を確認する姿勢が必要です。

一方、プラグインやテーマは、それぞれの設定次第で自動更新の対象にならない部品が残ります。「自動更新を有効にした」ということは、「すべての部品のセキュリティアップデートが自動で反映されている」ことを意味しません。メジャーアップデートを自分で行う余裕がない場合は、WordPress 7.0アップデートを代行で依頼するという選択肢もあります。

脆弱性への向き合い方には、大きく2つの場面があります。

1つ目は、修正版がまだ用意されていない場合です。脆弱性が公表された時点で、その修正がまだ間に合っていないことは珍しくありません。この場合、「最新に保つ」という対策そのものがまだ機能しないため、その部品を使い続ける必要があるか、代わりが利くかを判断する段階に移ります。

2つ目は、修正版はすでに出ているものの、反映すると表示が崩れる、機能が動かなくなるといった心配があり、すぐには反映できない場合です。その間も、脆弱性が未修正の状態は続きます。更新後の不具合の確認や、自分でどこまで対応を続けられるかという話は本記事の範囲を超えますが、少なくとも、修正版の適用を先送りしている間は脆弱性が残った状態である、という自覚を持つことが必要です。

いずれの場合も、一時的な対処法を並べて選んでもらう、という形では答えません。まず自分がどちらの場面に当たっているのかを分けて考えることが、次の判断につながります。

「最新に保つ」という対策は、修正版が今後も配布され続けることを前提にしています。開発が止まったプラグインには、この前提が成り立ちません。修正版が出てこない部品では、公表された情報の読み方も、急ぐかどうかの判断も、適用できる修正版そのものが存在しないため、別の対応判断が必要になります。

WordPress本体でも、古いバージョン（4.1〜4.6など）へのセキュリティ更新の提供はすでに終了しています。本体でさえ、いつまでも修正版が出続けるわけではない、という実例です。

保守を引き継いだサイトでは、今も使われているのかどうか分からないプラグインやファイルが、そのまま残っていることがあります。使っているかどうか分からない部品ほど、修正版が出なくなっていることに気づきにくいものです。何年も更新されていないプラグインを削除するという考え方は、こうした「修正版がもう出てこない」部品を残さないための対策でもあります。特定の製品を名指しして良し悪しを判断する話ではなく、更新が止まっている部品を見つけたら整理する、という考え方の問題です。

この記事で扱ったのは、対策の1つ目である「最新に保つ」の中身だけです。残りは、次の3つの問いとして案内します。

対策の中身（ログインの守り方・バックアップ・検知の仕組みが何を見ているか）を知りたい方は、更新以外に確認したい基本対策と改ざん検知をご覧ください。

実際に乗っ取りがどう起き、なぜ基本の対策が抜け落ちるのかを知りたい方は、脆弱性の警告が届いたときに起きていることをご覧ください。

これらを自分で続けられるか、どこから任せるべきかを知りたい方は、修正版をすぐ適用できないときの保守の判断基準をご覧ください。

脆弱性とは、WordPress本体やプラグイン、テーマなどに存在するセキュリティ上の弱点です。公表された情報は、影響するバージョン・悪用の条件・修正済みのバージョンの3点で確認し、攻撃条件が限定されていないものほど優先して対応します。そして「最新に保つ」だけでは対応できない場面があることも押さえておく必要があります。

貴社のWordPressサイトについて、脆弱性への向き合い方も含めて保守体制全体を見直したい場合は、WordPress保守・セキュリティ対策の詳細を見るをご覧ください。

WordPress保守を担当するビークリエイトのチームの知見をもとに、本記事を構成しています。詳しくは会社概要をご覧ください。