Core Web Vitals(ページの表示速度・応答性・レイアウトの安定性を測るGoogleの指標)の監視に使われるRUM(Real User Monitoring=実際の訪問者のブラウザから計測データを集める仕組み)ツール「DebugBear」で、セキュリティインシデントが起きたとSearch Engine Journalが報じています。表示速度の改善のために入れた計測タグが、そのままセキュリティ上の入口になり得ることを示す事例です。
🔎 何が起きたのか
報道によると、攻撃者はドメインレジストラ経由でDebugBearのDNSレコードを不正に操作し、同社のスクリプト配信先から悪意あるJavaScriptが配信されました。10月29日にセキュリティ企業のHudson Rockが、暗号資産の予測市場Polymarketが読み込むDebugBearのスクリプトURLに不審なコードがあるのを発見。Polymarketは10月30日のインシデント報告で、一部ユーザーのウォレットから資金移動などが行われたことを認めています。
このコードは、ログイン中のブラウザがすでに持っている権限を悪用するもので、パスワードを盗む必要がない点が厄介です。DebugBearの初期調査では、狙われたのは1つの顧客サイトで、同社の内部システム侵害の兆候はないとされています。ほかの顧客に悪意あるコードが配信されたかどうかは、現時点では明確になっていません。
🧩 なぜ速度改善の担当者にも関係があるのか
RUMツールやアナリティクス、タグマネージャーなどの外部スクリプトは、ページ上で自サイトと同じ権限で動作します。つまり配信元が乗っ取られると、管理画面にログイン中の管理者のブラウザでも悪意あるコードが実行され得ます。速度計測のために入れたタグが、実はサイト全体の信頼の前提になっているということです。
✅ WordPress運営者がやるべきこと
- DebugBearを使っている場合は、埋め込みタグを直ちに外す。形式は
https://cdn.debugbear.com/スクリプトID.jsで、テーマのヘッダー、プラグイン、Googleタグマネージャーなどを確認します。ページキャッシュも削除し、実際に読み込まれなくなったことをブラウザの開発者ツールで確認してください。 - 管理者など権限の高いユーザーのセッションを無効化し、パスワードを再設定する。パスワード変更だけでは既存セッションが残る場合があるため、旧セッションが拒否されることも確かめます。
- 不審な変更がないか点検する。新規ユーザー、権限変更、タグマネージャーの変更履歴、テーマ・プラグインのファイルなどを確認します。
- DebugBearを使っていなくても、棚卸しをする。サイトが読み込む外部スクリプトの一覧を作り、不要なものを削除し、重要なものは配信元を限定することを検討しましょう。不要なスクリプトを減らすことはLCPやINPの改善にも直結します。
タグを外しても、すでに実行された不正な操作が取り消されるわけではありません。被害が疑われる場合は、メンテナンス表示(HTTPステータス503)に切り替えたうえで、クリーンなバックアップからの復元や専門家による調査を行ってください。
📌 まとめ
計測・分析系の外部スクリプトは便利ですが、配信元のDNSやアカウントが侵害されれば自サイトの安全性にも影響します。「入れっぱなしのタグ」をこの機会に見直しておくのがおすすめです。
出典: Search Engine Journal「Hackers Hijacked DebugBear's DNS To Serve Malicious JavaScript」
