「自社サイトはWordPressで運用しているが、セキュリティ対策は制作会社任せで実態がわからない」——Web担当者からよく聞く悩みです。WordPressは世界で最も使われているCMSである一方、その普及率の高さゆえに攻撃者から最も狙われるプラットフォームでもあります。本記事では、WordPressに潜むセキュリティリスクの正体、放置した場合に起こる被害、主な攻撃手法、自社サイトの脆弱性を確認する方法、そして具体的な対策までを体系的に整理します。
WordPressのセキュリティリスクとは何か
WordPressのセキュリティリスクとは、WordPressで構築されたWebサイトが不正アクセス・改ざん・情報漏えいなどの被害を受ける可能性のことを指します。その根本にあるのが「脆弱性（ぜいじゃくせい）」です。
脆弱性とは、プログラムの設計ミスや実装上の不具合によって生じるセキュリティ上の欠陥のことです。攻撃者はこの欠陥を突いて、本来許されていない操作——管理者権限の奪取、データベースの読み出し、サーバー上でのプログラム実行など——を実現します。
重要なのは、脆弱性は「あるかないか」ではなく「いつ見つかるか」の問題だという点です。どれだけ丁寧に作られたソフトウェアでも、後から欠陥が発見されるのは避けられません。だからこそ、脆弱性が公表されたときにどれだけ早く対処できるかが、Webサイト運用の実力を分けます。
WordPress本体・プラグイン・テーマそれぞれに潜む脆弱性
WordPressの脆弱性は、大きく4つの層に分けて理解すると整理しやすくなります。
| 層 | 内容 | 特徴 |
|---|---|---|
| WordPress本体（コア） | WordPress公式が開発するCMS本体 | 開発体制が整っており件数は少ないが、影響範囲が全世界規模 |
| プラグイン | 機能拡張のための追加プログラム | 開発者の質・保守体制がバラバラで、脆弱性の大半を占める |
| テーマ | サイトのデザインを司るテンプレート | 更新が止まった配布終了テーマが放置されがち |
| サーバー・ミドルウェア | PHP、MySQL、Webサーバー、SSL関連 | WordPress側の対策だけでは守れない領域 |
セキュリティベンダーPatchstackが公開した「State of WordPress Security in 2026」では、2025年に発見されたWordPress関連の脆弱性は11,334件にのぼり、そのうち91%がプラグイン、9%がテーマに起因し、WordPress本体（コア）の報告はごくわずかだったとされています。つまり、WordPressそのものが脆弱というより、「後から追加した拡張機能が弱点になっている」というのが実態に近い構図です。
さらに同レポートでは、公表された脆弱性のうち約46%が公表時点で開発者による修正パッチが提供されていなかったこと、有料・フリーミアム製品の脆弱性報告も全体の約29%を占めていたことが指摘されています。「有料プラグインだから安全」「有名プラグインだから安心」とは言い切れないわけです。
ただし、本体（コア）にリスクがないわけではありません。2026年7月には、WordPressコアの認証不要リモートコード実行の脆弱性（通称「wp2shell」、CVE-2026-63030／CVE-2026-60137）が公表され、実際に悪用が確認されたと複数のセキュリティベンダーが報告しています。プラグインを一切入れていない標準構成でも影響を受け得る内容だったため、WordPress側は強制自動更新で対応しました。本体・拡張機能のどちらも監視対象から外せない、ということです。
なぜWordPressは攻撃者に狙われやすいのか
WordPressが集中的に狙われる理由は3つあります。
1. 圧倒的なシェア
W3Techsの統計をもとにした各種調査では、2026年時点でWordPressは全Webサイトの約41〜42%、CMSを使用しているサイトに限れば約59〜60%を占めるとされています（数値は調査時点で変動します）。攻撃者にとって、1つの脆弱性を見つければ数百万〜数千万サイトに使い回せる、極めて「費用対効果の高い」標的なのです。
2. オープンソースでソースコードが公開されている
WordPressはオープンソースソフトウェアであり、誰でもソースコードを閲覧できます。これは開発者コミュニティによる健全な改善を促す一方で、攻撃者にとっても脆弱性を探す材料が公開されていることを意味します。
3. 専門知識がなくても構築・運用できてしまう
WordPressは非エンジニアでもサイトを立ち上げられる手軽さが魅力です。しかしその裏返しとして、セキュリティ知識のないまま運用され、更新が止まったまま放置される「野良サイト」が大量に生まれます。攻撃者はこうした管理の緩いサイトを自動巡回で探し出します。
Patchstackのレポートでは、脆弱性の公表から最初の攻撃観測までの中央値がわずか約5時間、約半数が24時間以内に攻撃されたと報告されています。「来週の定例メンテナンスで更新しよう」では間に合わない速度で攻撃が始まっている、という認識が必要です。
WordPressの脆弱性を放置するとどうなるか
脆弱性を放置した結果として起こる被害は、単に「サイトが見られなくなる」だけでは済みません。BtoB企業の場合、事業そのものへのダメージに直結します。
不正アクセス・Webサイト改ざん
最も典型的なのが、管理画面への不正ログインやサーバーへの侵入によるコンテンツの改ざんです。
改ざんの手口は年々巧妙化しています。トップページを攻撃者のメッセージに書き換えるような「見てすぐわかる」改ざんは減り、代わりに次のような気づきにくい改ざんが主流になっています。
- 検索エンジンからの流入時だけ、無関係な外部サイトへリダイレクトさせる
- 一般訪問者には正常に見えるが、ページ内に隠しリンク（スパムリンク）が大量に埋め込まれる
- 管理者としてログイン中のブラウザからは変化が見えないよう分岐処理を仕込む
このタイプの改ざんは、社内の誰も異常に気づかないまま数か月放置されることも珍しくありません。
マルウェア感染・踏み台化（他サイトへの攻撃加担）
侵入に成功した攻撃者は、再侵入用の裏口（バックドア）やWebシェルと呼ばれるプログラムを仕込みます。wp2shellの事例でも、攻撃者が永続的なWebシェルを設置していたことが確認されています。
バックドアを設置されたサイトは、次のような用途に「利用」されます。
| 悪用のされ方 | 内容 |
|---|---|
| マルウェア配布拠点 | 訪問者のPCにウイルスをダウンロードさせる |
| フィッシングサイト設置 | 自社ドメイン配下に偽の銀行・ECログイン画面を設置される |
| スパムメール送信の踏み台 | 自社サーバーから大量の迷惑メールが送信される |
| 他サイトへの攻撃の中継 | DDoS攻撃やブルートフォース攻撃の発信元にされる |
| 仮想通貨の不正マイニング | サーバーリソースを勝手に消費される |
ここで深刻なのは、自社が「被害者」であると同時に「加害者」になってしまう点です。取引先や第三者に実害が及べば、責任問題は避けられません。
情報漏えい・信頼失墜・金銭的被害
問い合わせフォームの送信内容、会員情報、EC機能を持つサイトであれば購入履歴や決済情報まで——WordPressのデータベースには顧客の個人情報が蓄積されています。これらが流出した場合の影響は次のように広がります。
- 個人情報保護委員会への報告および本人への通知義務の発生
- 顧客・取引先への謝罪対応と問い合わせ窓口の設置
- 原因調査（フォレンジック調査）と再構築の費用
- サイト停止期間中の商談機会・広告費の損失
- Googleによる「このサイトは第三者に危害を及ぼす可能性があります」警告表示
- 検索結果からの除外（インデックス削除）による自然流入の消失
特にBtoBサイトでは、リード獲得の入口であるWebサイトが数週間止まるだけで、営業パイプラインに穴が空きます。復旧コストより、機会損失と信用毀損のほうが大きいというのが実務上の感覚です。
WordPressを狙う主な攻撃手法
対策を考える前に、攻撃側が何をしているかを知っておくと優先順位が決めやすくなります。代表的な3つを押さえておきましょう。
ブルートフォース攻撃（総当たり攻撃）
ログイン画面に対して、ユーザー名とパスワードの組み合わせを機械的に試し続ける手法です。WordPressのログインURLは標準で /wp-login.php または /wp-admin/ と決まっているため、攻撃ボットは対象サイトを見つけ次第この場所を叩きに来ます。
派生形として、他社サービスから流出したID・パスワードの一覧を使い回すパスワードリスト型攻撃があります。総当たりより効率が良いため、こちらのほうが成功率は高いとされています。「他のサービスと同じパスワードを使い回している」状態が最も危険です。
なお、WordPressの初期ユーザー名は admin が使われがちで、これは攻撃者が真っ先に試す文字列です。ユーザー名が推測できる時点で、攻撃者の作業量は半分になります。
クロスサイトスクリプティング（XSS）
入力値の処理に不備があるページに悪意のあるスクリプトを埋め込み、サイトの訪問者のブラウザ上でそのスクリプトを実行させる攻撃です。攻撃の矛先が「サイト訪問者」に向く点が特徴で、セッション情報（ログインCookie）の窃取、偽の入力フォーム表示によるフィッシング、意図しないサイトへの誘導などに使われます。
WordPressの脆弱性報告の中でも、XSSはプラグイン由来のものとして非常に多く登録されている類型です。IPAの脆弱性届出状況でも、Webサイトに関する届出のうちXSSが最多を占める傾向が続いています。
SQLインジェクション
データベースへの問い合わせ文（SQL文）を組み立てる処理に不備がある場合、入力欄に特殊な文字列を送り込むことでデータベースを不正に操作する攻撃です。IPAの「安全なウェブサイトの作り方」でも、利用者からの入力をもとにSQL文を組み立てる際の実装不備が原因であると解説されています。
WordPressはコンテンツも会員情報も設定値もすべてデータベース（MySQL/MariaDB）に格納しているため、SQLインジェクションが成立すると、記事の書き換えから管理者アカウントの追加、個人情報の一括抽出まで一気に可能になります。前述のwp2shellも、REST APIの処理不備とWP_QueryにおけるSQLインジェクションを組み合わせた攻撃連鎖でした。
3つの攻撃手法の比較
| 攻撃手法 | 主な標的 | 攻撃の入口 | 成立時の被害 | 主な防御策 |
|---|---|---|---|---|
| ブルートフォース攻撃 | 管理者アカウント | ログイン画面 | 管理権限の乗っ取り | 強固なパスワード、ログインURL変更、回数制限、二段階認証 |
| XSS | サイト訪問者 | 入力フォーム・URLパラメータ | Cookie窃取、フィッシング、マルウェア誘導 | プラグイン/テーマの更新、WAF |
| SQLインジェクション | データベース | 入力フォーム・API | 情報の大量流出、データ改ざん | 本体/プラグインの更新、WAF |
表からわかるとおり、ブルートフォース対策は「運用ルール」で、XSS・SQLインジェクション対策は「更新とWAF」で守るという役割分担になります。どちらか片方だけでは不十分です。
実際にどんな被害が起きているか
抽象的な話に留めず、実際に起きているパターンを見ておきましょう。
パターン1：更新が止まったプラグイン経由の改ざん
数年前にキャンペーン用として導入したまま使っていないプラグインが有効化された状態で残り、そこに公表済みの脆弱性があった——という侵入経路は非常に多く報告されています。使っていない機能でも、有効化されている限り攻撃対象です。
パターン2：放置された「野良サイト」からの侵入
事業部が独自に立ち上げた製品サイト、終了したキャンペーンのランディングページ、旧コーポレートサイトなど、情報システム部門が把握していないWordPressサイトが侵入口になるケースです。同一サーバー内に複数サイトを同居させている場合、1つが侵入されると他のサイトにも被害が波及します。国内のセキュリティイベントでも、こうした管理外サイトを狙う傾向の強まりが指摘されています。
パターン3：ECサイトの決済ページ改ざんによるカード情報窃取
決済フォームに不正なスクリプトを仕込み、利用者が入力したクレジットカード情報をリアルタイムで窃取する手口です。国内でも2025年にECサイトの決済システム改ざんによるカード情報流出が公表された事例があり、この手口は改ざんが目立たないぶん発覚が遅れやすいという特徴があります。
パターン4：コア脆弱性の公表直後の大規模スキャン
2026年7月のwp2shellでは、脆弱性の公表と実証コードの公開を受けて、インターネット全体を対象とした大規模スキャンと自動攻撃が短期間で拡大したと報告されています。「うちは小さいサイトだから狙われない」は成立しません。攻撃はサイトの規模ではなく、脆弱かどうかだけを見て自動的に実行されます。
自社サイトの脆弱性を確認する方法
「うちは大丈夫か」を確かめる手段は、無料でできるものから専門業者に依頼するものまで段階があります。
WordPress標準の「サイトヘルス」機能
WordPress管理画面の「ツール」→「サイトヘルス」から利用できる標準機能です。追加インストールは不要で、次の2つのタブで構成されています。
- ステータス：検出された問題を「致命的な問題」「おすすめの改善」「合格したテスト」に分類して表示
- 情報：WordPressバージョン、PHPバージョン、有効なプラグイン数、データベース情報などの環境情報を一覧表示
サイトヘルスは、古いPHPバージョンの使用、更新されていないプラグイン・テーマの存在、HTTPS未対応、自動更新の無効化といった項目を検出します。ただし、サイトヘルスは「既知の脆弱性が自社サイトにあるか」を照合する機能ではありません。あくまで構成上の推奨事項チェックであり、これが「良好」でも安全が保証されるわけではない点は理解しておく必要があります。
脆弱性情報データベースで既知の脆弱性を照合する
自社が使っているプラグインやテーマに脆弱性が報告されていないかは、公開データベースで確認できます。
| データベース | 提供元 | 特徴 |
|---|---|---|
| WPScan Vulnerability Database | WPScan（Automattic傘下） | WordPress本体・プラグイン・テーマに特化。数万件規模の情報を蓄積。無料APIは1日あたりのリクエスト数に上限あり |
| Patchstack Database | Patchstack | WordPressエコシステムの脆弱性を網羅。年次レポートも公開 |
| JVN iPedia | IPA・JPCERT/CC | 日本語で脆弱性の詳細と対処法を確認できる。国内外の情報を幅広く収録 |
| CVE / NVD | MITRE・NIST | 脆弱性の国際的な採番体系。CVE番号で一意に情報を追える |
運用としては、「使用中のプラグイン一覧を棚卸しし、月1回はこれらのデータベースで名前を検索する」だけでも効果があります。加えて、JVNやセキュリティ系メディアのWordPress脆弱性まとめ記事をRSSやメールで購読しておくと、公表当日に気づける確率が上がります。
脆弱性診断ツール・診断サービスの活用
より踏み込んだ確認をしたい場合は、診断ツールやサービスを使います。
- WPScan：WordPress専用のスキャナ。コマンドライン版と管理画面から使えるプラグイン版があり、テーマ・プラグイン・本体のバージョンを脆弱性データベースと突き合わせます
- セキュリティプラグインのスキャン機能：Wordfence等はマルウェアスキャンやファイル改ざん検知を備えます
- 外部の脆弱性診断サービス：専門事業者による診断。ツールでは検出できない設定不備やロジックの問題まで確認でき、報告書として提出できるため、取引先へのセキュリティ説明資料としても使えます
注意点として、診断ツールを他社が管理するサイトに向けて実行してはいけません。許可なく実施すると攻撃とみなされる可能性があります。必ず自社が管理権限を持つサイトに限定してください。
WordPressのセキュリティリスクを下げる10の対策
ここからは具体的な対策です。優先度の高い順に整理します。
1. WordPress本体・プラグイン・テーマを常に最新化する
最も効果が高く、最も基本的な対策です。前述のとおり、脆弱性公表から攻撃開始までの時間は数時間単位まで短縮されています。マイナーバージョンの自動更新を有効にし、プラグイン・テーマも自動更新を基本としたうえで、業務影響が大きいものだけ手動運用にするのが現実的です。
更新によるレイアウト崩れや機能停止が心配な場合は、本番環境と同構成のステージング環境を用意し、そこで検証してから適用する運用にします。多くのレンタルサーバーがステージング機能を標準提供しています。
2. 使っていないプラグイン・テーマは削除する
「停止（無効化）」ではなく「削除」まで行うのが原則です。無効化してもファイルはサーバー上に残るため、ファイルに直接アクセスするタイプの攻撃には無防備なままです。使用中のテーマ以外は、公式のデフォルトテーマを1つだけ残して他は削除しておくとよいでしょう。
3. 推測されにくいユーザー名・パスワードを設定する
admin、administrator、会社名、ドメイン名などをユーザー名にするのは避けます。パスワードは英大文字・小文字・数字・記号を混ぜた12文字以上を推奨し、他サービスとの使い回しは絶対に避けてください。パスワード管理ツールを導入し、担当者ごとに個別アカウントを発行する運用が理想です。
また、投稿者アーカイブのURLからユーザー名が推測できてしまう場合があるため、表示名（ニックネーム）とログインIDは分けて設定します。
4. ログインページのURLを変更する
標準の /wp-login.php を別のURLに変更するだけで、自動巡回ボットからのアクセスを大幅に減らせます。「SiteGuard WP Plugin」などのプラグインで設定可能です。根本的な防御ではありませんが、無駄な攻撃トラフィックとサーバー負荷を減らす効果があります。
5. ログイン試行の制限・画像認証を導入する
一定回数ログインに失敗したIPを一時的にブロックする、ログイン画面に画像認証（CAPTCHA）を追加するといった対策で、ブルートフォース攻撃の成立を防ぎます。「Limit Login Attempts Reloaded」「SiteGuard WP Plugin」などが定番です。
6. 管理画面へのIPアドレス制限をかける
社内やVPNからのみ管理画面にアクセスできるようにIP制限をかける方法です。.htaccess での設定や、レンタルサーバーの管理画面アクセス制限機能で実現できます。リモートワークが多い組織ではVPN経由に統一するなど、運用ルールとセットで検討します。
7. 二段階認証（2FA）を有効にする
パスワードに加えて、認証アプリが生成するワンタイムパスワード（TOTP）などの第2の要素を要求する仕組みです。パスワードが漏えいしても、第2の要素がなければログインできないため、リスト型攻撃に対して非常に有効です。
WordPress公式ディレクトリの「Two Factor」プラグインが広く使われており、TOTP、メール送信、バックアップコードなどに対応します。パスキーやセキュリティキー（WebAuthn）を使いたい場合は、対応する拡張プラグインを追加する構成になります。Wordfenceのログインセキュリティ機能でも2FAを利用できます。
8. WAF（Web Application Firewall）を導入する
WAFは、Webアプリケーションへの通信を監視し、SQLインジェクションやXSSといった攻撃パターンに該当するリクエストを遮断する仕組みです。脆弱性そのものを修正するわけではありませんが、パッチ適用までの時間を稼ぐ「仮想パッチ」として機能する点が実務上の価値です。
WAFには主に次の形態があります。
| 形態 | 導入方法 | 特徴 |
|---|---|---|
| レンタルサーバー標準WAF | サーバー管理画面でONにする | 無料・即日利用可。誤検知時は個別に除外設定が必要 |
| クラウド型WAF | DNS設定を変更して通信を経由させる | 自社での機器管理が不要。防御ルールの更新が早い |
| プラグイン型WAF | WordPress管理画面からインストール | 導入が容易。PHPレベルで動作するため負荷に注意 |
| アプライアンス型 | 自社ネットワークに機器を設置 | 大規模環境向け。コストと運用負荷は高い |
まずは契約中のレンタルサーバーにWAF機能があるかを確認し、有効化されているかをチェックするのが第一歩です。多くのサーバーで標準提供されていますが、管理画面の更新時に誤検知が起きるため無効化したまま放置されている、というケースが少なくありません。
9. 定期的にバックアップを取得し、復元手順を確認しておく
どれだけ対策しても被害をゼロにはできません。だからこそ、確実に復旧できる体制が最後の砦になります。
- データベースとファイル（wp-content配下）の両方を取得する
- 世代管理を行い、最低でも数世代前まで遡れるようにする（改ざん検知が遅れた場合に備えるため）
- 保存先はWebサーバーとは別の場所（クラウドストレージ等）にする
- 実際に復元できるかを一度テストしておく
バックアップは「取っていること」ではなく「戻せること」に意味があります。BackWPupやUpdraftPlusなどのプラグイン、あるいはレンタルサーバーの自動バックアップ機能を利用します。
10. ユーザー権限の適切な管理とSSL化
WordPressには管理者・編集者・投稿者・寄稿者・購読者という権限グループがあります。記事を書くだけの担当者に管理者権限を渡さない、退職・異動時にアカウントを速やかに削除する、といった基本の徹底が重要です。管理者アカウントが多いほど、乗っ取られる入口が増えます。
またサイト全体のHTTPS化（SSL化）は、通信の盗聴・改ざんを防ぐ前提条件です。特にログイン情報や問い合わせフォームの送信内容を平文で流すのは論外であり、常時SSL化と、無料証明書を使っている場合の自動更新設定の確認まで行っておきます。
セキュリティプラグインの選び方
対策の一部はプラグインで実装できます。代表的なものを整理します。
| プラグイン | 主な機能 | 特徴 |
|---|---|---|
| SiteGuard WP Plugin | ログインURL変更、画像認証、ログインロック、更新通知 | 国産・日本語UI。国内レンタルサーバーに標準搭載されていることが多く初心者向け |
| Wordfence Security | ファイアウォール、マルウェアスキャン、ログイン保護、2FA | 高機能。無料版はファイアウォールルールの反映が有料版より遅れる仕様 |
| Akismet | コメント・フォームのスパム判定 | スパム対策に特化。商用利用は有料プランが必要 |
| Two Factor | 二段階認証（TOTP・メール等） | WordPress公式ディレクトリで配布。シンプルで軽量 |
| BackWPup / UpdraftPlus | バックアップの自動取得と外部保存 | 復旧の要。保存先を外部ストレージに設定して使う |
注意点として、セキュリティプラグインを何個も重ねて入れるのは逆効果です。機能が競合して管理画面が不安定になったり、サイトが重くなったりします。「ログイン防御系1つ＋バックアップ1つ＋（必要に応じて）スキャン系1つ」程度に絞り、サーバー側のWAFと役割を分担させるのが現実的な構成です。また、セキュリティプラグイン自体に脆弱性が見つかることもあるため、これらこそ最新版を維持する必要があります。
被害を受けてしまった場合の対処法
万一、改ざんや不正アクセスが疑われる場合、初動の順序を誤ると被害が拡大します。落ち着いて次の手順を踏みます。
Step 1：サイトを一時的に公開停止する
被害拡大を防ぐため、まずサイトをメンテナンスモードにするか、サーバー側でアクセスを遮断します。訪問者へのマルウェア感染や、スパム送信の継続を止めることが最優先です。
Step 2：証拠を保全する
いきなり上書き復元してしまうと、侵入経路の特定ができなくなります。アクセスログ、エラーログ、改ざんされたファイルの状態を、可能な範囲でコピーして保全します。
Step 3：全パスワードを変更する
WordPress管理者アカウント、FTP/SFTP、データベース、サーバーのコントロールパネル、関連する外部サービスのパスワードをすべて変更します。認証情報が窃取されている前提で動きます。
Step 4：クリーンなバックアップから復元する
改ざん前の時点のバックアップから復元します。ここで「いつから改ざんされていたか」の見極めが重要です。直近のバックアップにすでにバックドアが含まれている可能性があるため、複数世代のバックアップが役に立ちます。
Step 5：侵入原因を特定し、塞ぐ
原因となった脆弱性を修正しないまま復旧すると、同じ経路で再び侵入されます。プラグイン・テーマ・本体をすべて最新化し、不要なものは削除し、不審な管理者アカウントやファイルが追加されていないかを確認します。
Step 6：専門家・関係先へ報告する
自社だけで対応しきれない場合は、サーバー会社のサポート、制作会社、セキュリティ専門事業者に相談します。個人情報の漏えいが疑われる場合は、個人情報保護法にもとづく報告・通知の要否を法務担当と確認し、IPAやJPCERT/CCへの届出も検討します。
Step 7：Google Search Consoleで再審査を依頼する
マルウェア配布などでGoogleから警告表示や検索結果からの除外を受けている場合、駆除完了後にSearch Consoleの「セキュリティの問題」から再審査をリクエストします。
なお、これらの作業は復旧完了までに数日〜数週間かかることもあります。事前に「誰が」「どこに連絡して」「どう判断するか」を決めておくことが、実際の被害時の時間を大きく短縮します。
まとめ
WordPressのセキュリティリスクについて、本記事の要点を整理します。
- WordPressの脆弱性は本体・プラグイン・テーマ・サーバーの4層に分かれ、Patchstackの2026年レポートでは2025年に発見された脆弱性11,334件のうち91%がプラグイン由来だった
- 全Webサイトの約4割を占めるシェア、オープンソースであること、専門知識がなくても運用できることが、WordPressが集中的に狙われる理由
- 放置した場合のリスクは、改ざん・マルウェア感染・バックドア設置・情報漏えい・踏み台化・検索結果からの除外・信用失墜と多岐にわたり、被害者であると同時に加害者になり得る
- 主な攻撃手法はブルートフォース攻撃（管理者アカウントが標的）、XSS（訪問者が標的）、SQLインジェクション（データベースが標的）で、それぞれ有効な防御策が異なる
- 脆弱性公表から最初の攻撃観測までの中央値は約5時間とされ、更新の速度そのものがセキュリティ水準を左右する
- 自社サイトの状態は、標準の「サイトヘルス」機能、WPScan・JVN iPedia・CVEなどの脆弱性データベース、診断ツールや外部の診断サービスで確認できる
- 対策の柱は、最新化、不要なプラグイン・テーマの削除、強固な認証情報、ログインURL変更、ログイン試行制限、IP制限、二段階認証、WAF、バックアップ、権限管理とSSL化の10項目
- セキュリティプラグインは重ねすぎず、サーバー側のWAFと役割分担させる構成が現実的
- 被害時は「公開停止→証拠保全→パスワード変更→復元→原因除去→報告→再審査依頼」の順で動き、事前に連絡先と判断フローを決めておく
WordPressのセキュリティは、一度設定して終わりではなく、更新と監視を継続する「運用」です。まずは自社サイトで使用中のプラグイン一覧を棚卸しし、更新が止まっているものがないかを確認するところから始めるとよいでしょう。