更新を当てることは、保守の基本だ。ただし、その 更新そのものが改ざんされる ケースが、WordPress の周辺でも報告されている。この記事では、サプライチェーン攻撃の仕組みを公開情報の範囲で確認し、「すぐ当てる」と「少し待つ」をどう両立させるか、外部から読み込むスクリプトをどう減らすかを整理する。煽るためではなく、落ち着いて運用を設計するための材料として書く。
サプライチェーン攻撃とは
自分のサイトを直接攻めるのではなく、自分のサイトが信頼している配布元 を狙う攻撃のことだ。WordPress のサイトでは、信頼している先が複数ある。
| 信頼している先 | 具体例 |
|---|---|
| 更新の配布経路 | プラグイン・テーマの更新サーバー、公式ディレクトリ、有償版の更新チャネル |
| 開発元そのもの | 開発者のアカウント、ビルド環境、開発元の持ち主 |
| 外部から読み込むファイル | CDN から配信される JavaScript、外部の解析タグ、フォント配信 |
サイト管理者が「更新があるから当てる」「このスクリプトは有名だから読み込む」と判断するとき、その信頼を逆手に取られる。通常の脆弱性と違い、更新を当てた結果として 問題が入ってくる点が特徴だ。
公開されている事例（2026-11-01 時点で確認）
事例は、仕組みの違いを見るために挙げる。特定の製品を責める意図はない。
外部 CDN の JavaScript が書き換わった例（2024 年）
人気の JavaScript ライブラリを配信していたドメインが、2024 年 2 月に別の会社に取得された。その後、そのドメインから配信されるスクリプトに、特定の端末の訪問者を別のサイトへ転送するコードが混ざったと、セキュリティ企業 Sansec が 2024-06-25 に報告している。このドメインを読み込んでいたサイトは 10 万以上とされる。
出典: Sansec, Polyfill supply chain attack
ここでの要点は、サイト側のコードは何も変わっていない のに、読み込み先の中身が変わったことだ。サイトを更新しても、プラグインを最新にしても、防げない。
開発元の持ち主が変わった例（2025〜2026 年）
Patchstack は 2026-04-15 付の記事で、あるプラグイン開発元が 2025 年に売却されたあと、新しい持ち主の最初期の変更に不正な仕組みが仕込まれていたと報告している。仕組みは数か月ほど動かないままで、2026 年 4 月ごろに有効化されたとされる。WordPress.org のプラグインレビューチームが 2026-04-07 に確認し、該当プラグインを公式ディレクトリで閉鎖したと書かれている。
出典: Patchstack, Critical supply chain compromise on 20+ plugins
影響を受けたプラグインの数は、同じ記事の中でも「20 以上」「25 以上」と記述が揺れている。ここでは件数を断定しない。要点は、開発元の持ち主が変わるだけで、同じプラグインの性質が変わりうる ことだ。
更新配布の経路が侵害された例（2026 年）
このほかに、有償版プラグインの更新配布の経路が侵害され、公式の更新として不正なコードが届いたとする報告が、2026 年に複数出ている（例: The Hacker News）。時期や範囲の記述は報道ごとに異なるため、ここでは詳細に踏み込まない。一次情報は各セキュリティ企業のアドバイザリで確認してほしい。
3 つの事例から分かること
- 更新の署名や公式の経路を通っていても、中身が安全とは限らない
- 問題が入ってから発覚するまでに、時間差がある（動かないまま数か月置かれる例もある）
- 脆弱性スキャナは「既知の悪い形」を探すため、正規の配布経路から来たもの は見つけにくい
「すぐ当てる」と「少し待つ」の両立
以前の記事（メジャー更新は少し待つ）では、機能追加を伴う更新は少し待つほうがよいと書いた。一方、前回の記事（公開から悪用までは数時間）では、セキュリティ修正は早く当てると書いた。サプライチェーン攻撃は、この 2 つに別の観点を足す。
| 更新の種類 | 基本の扱い | サプライチェーンの観点で足すこと |
|---|---|---|
| セキュリティ修正 | 早く確認して適用 | 配布元が普段どおりか（突然の持ち主変更・不自然な更新がないか）を横目で見る |
| 通常の小さな更新 | 週次の定例で適用 | 適用前にバックアップを取り、適用後に画面を確認する |
| メジャー更新 | 少し待って検証 | 待つ間に、同じ更新への報告（不具合・不審な点）が出ていないか見る |
つまり「すぐ当てる」と「少し待つ」は、更新の中身と配布元の状況を見て決める という 1 つの考え方にまとまる。待つ日数を決め打ちにするのではなく、待つ理由（互換性か、配布元の様子か）を意識する。
手元でできること
入れているものの出どころを把握する
# 入っているプラグインと状態の一覧
wp plugin list --fields=name,status,version,update
# 本体・プラグインのファイルが公式の配布物と一致するか
wp core verify-checksums
wp plugin verify-checksums --all
verify-checksums は、WordPress.org に登録されているプラグインについて、公式の配布物との差分を調べる。有償版や独自配布のプラグインは対象外 になる点に注意する。確認できないものがどれかを、一覧にしておくこと自体が価値になる。
開発元の変化を気にする
- 利用しているプラグインの開発元・連絡先が突然変わっていないか（プラグインのページや更新履歴）
- 更新が長期間止まっていたプラグインが、急に更新され始めていないか
- 使っていないプラグインは 無効化でなく削除 する（棚卸しの記事）
外部スクリプトを最小にする
外部から読み込むスクリプトは、サイトの外にあるコードに、サイトの中で実行する権限を渡すことと同じだ。
- いま読み込んでいる外部ドメインを一度洗い出す（ブラウザの開発者ツールのネットワーク欄、または
curlで取得した HTML の<script src>を確認） - 本当に必要なものだけ残す。古いブラウザ向けの補完のように、いまは不要になったものは外す
- 残すものは、自分のサーバーに置く（セルフホスト）ことを検討する。配布元が変わっても、手元のファイルは変わらない
- 外部のスクリプトに
integrity（ハッシュ）を付ける方法もある。ただし、中身が正当に更新されたときは、ハッシュの更新が必要になる
戻せる状態を保つ
どれだけ見ても、すべては防げない。問題に気づいたときに、入る前の状態へ戻せる ことが最後の備えになる。バックアップは、取ることではなく復元できることまでが保守だ。
疑わしいときの考え方
不審な更新に気づいたら、次の順で考える。
- 慌てて操作を重ねず、状況を記録する（更新のバージョン・時刻・画面）
- 該当プラグインの開発元や、セキュリティ企業のアドバイザリを確認する
- 必要なら一時的にサイトを保守モードにして、影響を広げない
- 復旧は、クリーンなバックアップ からを基本にする
「更新しただけで直った」と見えても、中身が入れ替わっていた場合、見た目だけでは分からないことがある。判断に迷う場合は、専門の窓口に相談するのがよい。
まとめ
- サプライチェーン攻撃は、サイトが 信頼している配布元 を狙う。更新を当てても、外部スクリプトを読み込んでいても、起こりうる
- 公開事例では、外部 CDN の書き換え・開発元の持ち主の変更・更新配布経路の侵害など、入り方はさまざまだ
- 「すぐ当てる」と「少し待つ」は、更新の中身と 配布元の様子 を見て決める 1 つの考え方にまとまる
- 外部スクリプトを減らし、残すものは自分のサーバーに置くことを検討する
- 戻せる状態を保つ。復元できることまでが保守だ
今日できる一手は、wp plugin verify-checksums --all を実行して、確認の対象外になったプラグインがどれか を一覧にすること。