WordPress脆弱性アラートの判断基準｜更新か無効化か

この記事の目次

「脆弱性が見つかりました」の通知、どう判断していますか

WordPressにセキュリティ系のプラグインを入れていると、ある日こんな通知が届きます。

「インストール済みのプラグインに脆弱性が見つかりました」

通知の対象を見ると、別のセキュリティプラグインだったりします。セキュリティのために入れたプラグインが、セキュリティのために入れた別のプラグインを「危険」と判定している。この状況で「で、何をすればいいの？」と止まってしまう人は多いと思います。

私も数十社のサイトを保守する中で、この手の通知を毎週のように受け取ります。この記事では、脆弱性アラートが来たときに、慌てず・放置せず・必要なことだけやるための判断の仕方をまとめます。

セキュリティプラグインの脆弱性チェックは、公開されている脆弱性データベースと、サイトに入っているプラグインのバージョンを照合しています。「このプラグインのこのバージョンには、報告された脆弱性がある」という情報と一致したら、通知を出します。

ここで知っておきたいのは、次の2点です。

つまり、アラートが来た時点で必要なのは「何が・どのくらい危ないか」を読むことで、通知の数に反応することではありません。

アラートが来たら、私は次の3つを順に確認します。

通知に「修正バージョン」が書かれていれば、話は簡単です。そのプラグインを更新するだけで解決します。更新前にバックアップを取り、更新後にサイトの表示とフォームの動作を確認します。

修正版がまだ出ていない場合は、次の質問に進みます。

脆弱性情報には、だいたいCVSSという指標で深刻度のスコア（0〜10）が付いています。目安は次のとおりです。

通知に「ログインした攻撃者が」「管理者権限で」と書かれていたら、悪用の条件が厳しいので、実際のリスクは低めです。「認証不要で」「リモートから」と書かれていたら、条件なしで狙われるので急ぎます。

意外と多いのが、「入れたけど使っていないプラグイン」が脆弱性を指摘されるケースです。使っていないなら、更新ではなく削除が正解です。停止しただけではファイルが残るので、削除まで行います。

セキュリティプラグイン同士が互いを指摘し合う場合も同じで、機能が重複しているなら片方に絞ります。ログイン保護・WAF・改ざん検知を、それぞれ別のプラグインで二重に入れていると、競合や誤判定の原因になります。

脆弱性データベースの情報は、報告者の申告ベースで登録されることがあります。報告自体が誤っていたり、特定の設定でしか再現しなかったり、開発元が「これは仕様で、脆弱性ではない」と反論しているケースもあります。

通知に出てきた脆弱性の名前やID（CVE番号）で検索すると、開発元の見解や、他のユーザーの報告が見つかります。開発元が公式に否定しているなら、更新を待てばよいことがほとんどです。

ただし、「誤検知かもしれない」を理由に放置するのは避けたいところです。確認して判断した、という記録を残しておくと、クライアントへの説明もしやすくなります。

保守契約のあるサイトでアラートが出たとき、私はクライアントに次の形で報告しています。

専門用語を並べると不安を与えるだけなので、「対応済みです」か「様子を見ています」のどちらかで結論を先に伝えます。

アラートの数を減らすには、プラグインの数を減らすのが一番確実です。

セキュリティは「全部に完璧に対応する」より、「危ないものを見分けて、そこに時間を使う」方が続きます。通知が来るたびに止まらず、3つの質問で仕分けるところから始めてみてください。