OVERVIEW
2026年8月中旬、Broken Link Checker 脆弱性(CVE-2026-18937)が公開されました。対象はWordPress用リンク監視プラグイン「Broken Link Checker」です。
この問題では、ログイン不要でサーバー上のコードが実行される恐れがあります。
深刻度は CVSS 9.0(Critical:致命的) です。WordPress.org 上で50万以上のサイトに入っています。
そのため、2.4.11以下を使っている場合は早めの更新を推奨します(修正版は 2.4.12 以降)。
ただし、悪用にはパーマリンクが「基本」形式であることなど、追加の前提があります。多くの本番サイトは該当しにくいです。
一方で、プラグイン未更新のまま放置する理由にはなりません。詳しくは後述します。
本記事では、Broken Link Checker 脆弱性(CVE-2026-18937)の内容と、自サイトでの確認ポイントを解説します。
Broken Link Checkerとは
Broken Link Checker(WPMU DEV)は、投稿や固定ページ内のリンク切れを自動検出する定番プラグインです。メール通知や管理画面からの修正機能もあり、SEO・UX の維持に使われてきました。
なぜ注目されたのか
2026年8月、2.4.12 でセキュリティ修正が入りました(報告: Jakub Herman)。公式 changelog には詳細はありません。
ただし、公開情報では次のように説明されています。
パーマリンクが基本形式のサイトでは、URL パラメータの受け取り方に問題があります。その結果、最悪コード実行につながる恐れがある、とのことです。
Broken Link Checker 脆弱性の詳細(CVE-2026-18937)
- CVE:CVE-2026-18937
- 分類:クエリ変数注入(CWE-94)。リモートコード実行まで到達し得る
- 影響範囲:Broken Link Checker < 2.4.12
- CVSS:9.0(Critical)。攻撃自体に前提条件あり(複雑さ High)
- 修正状況:2.4.12 で修正済み(最新版は 2.4.14 系)
- 公開日:2026年8月17日頃(WPScan)/8月19日(NVD)
何が問題か
平たく言うと、URL の ?以降 に付けたパラメータを、プラグインが無制限に WordPress 内部へ渡してしまう状態でした。
本来は決められたパラメータだけを受け取るべきところ、攻撃者が自由に名前を付けられます。その結果、「どのページを表示するか」の内部情報を上書きできてしまいます。
2.4.12 では、この「なんでも受け取る」処理が削除され、必要なパラメータだけを見る形に直されています。
攻撃の流れ(イメージ)
悪用手順の詳細は本記事では扱いません。公開情報から整理すると、次のような流れです。
- 対象サイトに Broken Link Checker 2.4.11以下がある。加えて、パーマリンクが「基本」形式で、テーマがクラシックタイプ(後述)である。
- 攻撃者が、細工した
?以降付きの URL にログインなしでアクセスする。 - プラグインが URL パラメータを WordPress 内部へ流し込み、ページ表示の制御情報が上書きされる。
- PHP でページを組み立てるタイプのテーマでは、最悪サーバー上で任意のコードが実行される恐れがある。これは公開情報上の説明です。
2つの前提条件(ここが重要)
「認証不要で Critical」と聞くと、全サイトが即危険に聞こえます。しかし、公開情報では次の2点がそろうと特に危険とされています。
どちらか一方でも「いいえ」なら、悪用は難しくなります。なお、条件を満たさなくても更新は必須です。
① パーマリンクは「基本」か
WordPress の「設定 > パーマリンク」で、URL が https://example.com/?p=123 のようになっているかどうかです。
この「基本」形式のときだけ、今回の問題のコードが動くとされています。
一方、https://example.com/記事名/ のような「投稿名」形式は、制作現場の本番サイトでよく見る設定です。
この場合、今回の経路自体が動きにくいと説明されています。
たとえば、プラグインが入っていても、パーマリンクが投稿名なら条件の1つはクリアしている可能性が高いです。
② 「クラシックテーマ」とは(旧式という意味ではない)
先に重要な点:ここで言う「クラシック」は、記事を書くエディター(ブロックエディター/クラシックエディター)の話ではありません。
「外観 > テーマ」で選んでいるサイト全体のテーマの種類の話です。したがって、エディターをどれにしているかは、今回の脆弱性の条件に含まれません。
CVE 説明の「クラシックテーマ」は、古いから危ないという意味でもありません。
WordPress の公式な呼び方で、header.php や single.php など PHP ファイルでサイトの見た目を組み立てるテーマを指します。
制作会社がオリジナルで作ったテーマや市販の有料テーマの大半がこれに当たります。
一方、WordPress 標準の Twenty Twenty-Four のように、サイト全体をブロックだけで組む専用テーマ(ブロックテーマ)だけが、公開情報上は別扱いとされています。
また、制作会社制作のサイトはだいたいクラシックテーマです。
名称に「クラシック」と付くクラシックエディター(投稿画面を旧UIにするプラグイン)は、今回とは無関係です。
同様に、一部の固定ページだけ旧エディターで書いているかどうかも条件には含まれません。混同しないでください。
自サイトのチェックリスト
次の3つがすべて「はい」に近い場合、特に注意が必要です。
- Broken Link Checker が 2.4.11以下のまま有効か
- パーマリンクが「基本」(
?p=123形式)か - 有効テーマが PHP ベースのクラシックタイプか(制作オリジナル含む)
多くの商用・制作サイトは「投稿名パーマリンク+PHP テーマ」です。そのため、深刻度は Critical でも実際の悪用は起きにくい条件に当たることがあります。
それでも未更新なら、2.4.12 以上へ更新してください。
Broken Link Checker 脆弱性の影響とリスク
この Broken Link Checker 脆弱性で想定される主なリスクは次のとおりです。
- 任意コード実行:前提が揃った場合、サーバー上で PHP コードが実行されます。その結果、バックドア設置や管理者追加、データ窃取などに至る恐れがあります
- 認証不要:ログインや管理者権限がなくても HTTP リクエストだけで試行できます。ただし、パーマリンク・テーマの条件があります
- リンク監視サイトへの波及:制作会社が複数クライアントで同バージョンを使い回していると、影響確認の対象が広がる
- スキャナー上の Critical 表示:条件を満たさなくても、脆弱バージョンのままだとセキュリティ監査やホスティングの警告対象になり続ける
Broken Link Checker 脆弱性への対処方法
Broken Link Checker 脆弱性(CVE-2026-18937)への対応として、次を推奨します。
- Broken Link Checker を 2.4.12 以上へ更新する(最優先。可能なら 2.4.14 など最新版)
- 更新後、ダッシュボードでバージョン表示を確認する
- 見覚えのない管理者ユーザーがいないか確認する
wp-content配下の不審な PHP ファイル、テーマファイルの想定外変更がないか確認する- すぐ更新できない場合:プラグインの無効化、またはパーマリンクを「投稿名」へ変更(URL が変わるため要確認)。なお、根本対策はバージョン更新です
- 使っていないサイトは、更新後に無効化・削除も検討
まとめ
本記事で整理した Broken Link Checker 脆弱性は、2.4.11以下でログイン不要のコード実行につながる恐れがあります。2.4.12 以上へ更新してください。
悪用には「パーマリンクが基本形式」「PHP ベースのクラシックテーマ(制作オリジナル含む)」という前提があります。いずれもエディターの種類とは無関係です。
一方、投稿名パーマリンクの本番サイトは該当しにくい面もあります。未更新なら、まずバージョン確認と更新から始めてください。
WordPressのセキュリティは「一度設定すれば終わり」ではありません。継続的な監視と更新が必要です。加えて、適切な保守管理によって初めて安全なサイト運営が実現できます。
参考
- WPScan - Broken Link Checker < 2.4.12 - Unauthenticated RCE via Query Variable Injection(CVE-2026-18937)
- NVD - CVE-2026-18937
- WordPress.org - Broken Link Checker(changelog 2.4.12)
- Patchstack - Broken Link Checker < 2.4.12 RCE
- WordPress Developer - wp_is_block_theme()(ブロックテーマ判定)
弊社では、WordPressサイトの定期的な保守サービスを提供しています。
今回のような重大な脆弱性への迅速な対応、プラグインやテーマの定期アップデート、バックアップ、ウイルススキャンなどを、専門のエンジニアが手動で実施いたします。
自動化ではなく手動対応にこだわることで、状況に応じた柔軟な判断と、問題の即時発見・修復が可能になります。
そのため、サイト運営者様が長期間チェックをしなくても、常に最新で最適なセキュリティ状態を維持できるよう、全力でサポートいたします。
また、不正ログインや外部からの攻撃に対しては、独自設定のファイアウォールにより24時間サイトを監視・防御します。攻撃の増加や異常を検知した際には、エンジニアが即座に対応いたします。
WordPressのセキュリティに不安を感じている方、プラグイン更新の管理に手が回らない方は、ぜひ弊社の保守サービスをご検討ください。
▼ WordPressサイトのセキュリティ保守サービスはこちら ▼
