セキュリティ対策のプラグインを入れれば、その後の更新は不要なのでしょうか。2024年11月14日にWordfenceが公表したReally Simple Securityの事例は、守るための部品も保守対象であることを示しています。この記事は過去の修正済み問題を振り返るもので、現在の最新版にも同じ問題が残っていると主張するものではありません。
対象は特定の版と二要素認証の設定
識別番号はCVE-2024-10924です。対象はReally Simple Securityの無料版、Pro版、Pro Multisite版の9.0.0から9.1.1.1までで、当該問題の完全修正版は9.1.2です。プラグインの二要素認証を有効にしていることが成立条件でした。この設定は当時、初期状態では無効と説明されています。
本人確認に失敗した際のエラー処理が適切でなく、認証していない攻撃者が既存の管理者を含む利用者としてログインできる問題でした。正しいパスワードでログインしなくても本人確認をすり抜ける「認証回避」です。ただし、対象の版や機能を利用していないサイトまで、一律に同じ影響があると説明するのは正確ではありません。
二要素認証そのものが不要という話ではない
二要素認証は、パスワード以外の確認を組み合わせて本人確認を強める方法です。今回の問題は、その方法の考え方ではなく、特定の製品・版での実装にありました。したがって、この事例を理由に、すべてのサイトで二要素認証をやめるべきだという結論にはなりません。
大切なのは、信頼している対策であっても更新情報を確認することです。製品の役割がセキュリティ対策であることと、その製品に将来も不具合が見つからないことは別です。パスワードを強くする、権限を絞る、更新する、ログを確認するなど、複数の備えを組み合わせて考えます。
自動更新がある場合も結果を確かめる
当時は開発元とWordPress.org側で強制的なセキュリティ更新が進められました。それでも、管理者が確認しなくてよいという意味ではありません。Wordfenceは有料版についても更新結果の確認を求め、ライセンスの状態で自動更新が機能しない可能性に触れています。
企業の担当者は、無料版か有料版か、現在の版、ライセンスを管理する人、設定している認証方法を確認します。9.1.2は2024年の当該問題の修正版であり、現在の最新版ではありません。今から作業する場合には、配布元の現行の更新案内と対応環境を確認し、当時の記事だけを頼りに古い版へ固定しないことが重要です。
ログインに関わる更新は復旧経路も準備する
ログイン保護の設定を変えるときは、管理者が入れなくなった場合の正規の復旧手段を確認しておきます。WordPressの管理者、サーバー契約者、保守担当者が別の場合、誰に連絡すれば復旧できるかを整理します。パスワードや回復情報は公開の共有資料へ置かず、権限を限定した方法で保管します。
更新後は、普段使う認証方法でログインできるか、必要な通知が届くか、管理者権限が意図した利用者だけに付いているかを点検します。見覚えのないユーザーや変更が見つかった場合は、更新したからもう大丈夫とは判断せず、ログを保全して調査を相談します。
安心を買い切るのではなく、確認を続ける
ホームページ保守は、特定のプラグインを入れた瞬間に終わる作業ではありません。製品の更新と設定、利用者、復旧手順を継続して確認する取り組みです。日頃から管理情報をそろえておけば、緊急の告知が出たときに対象かどうかを調べやすくなります。安全を完全に保証することはできなくても、放置による確認の遅れを減らすことはできます。