2026 年 5 月、InfoQ が Attacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them を報じ、「攻撃者が休眠プラグインを Flippa で合法的に買収 → 自動更新でバックドアを配信」という衝撃的なサプライチェーン攻撃が公開されました。CVE 報告ベースで 国内導入数だけでも数万サイトに影響が及ぶ可能性があります。
弊社では、ホームページ制作・コーポレートサイト保守・EC 運用などで WordPress を扱う受託案件が多く、「使っているプラグインの所有者がいつのまにか変わっていた」事態に備える必要が出てきました。本記事では、Flippa 型サプライチェーン攻撃に対する受託の防御策を整理します。
何が起きたのか
攻撃の流れは、以下の 4 ステップでまとめられます。
| ステップ | 内容 | 検知の難易度 |
|---|---|---|
| 1. 物色 | 「メンテ放棄気味」「DL 数が多い」プラグインを Flippa で物色 | 公開情報のみで実行可能 |
| 2. 買収 | 数万〜数十万円で正規取得、所有権を移転 | プラグインディレクトリ上は正常な所有者交代 |
| 3. 仕込み | 数バージョン後の更新でバックドアコードを混入 | 単体ソースを読まないと分からない |
| 4. 配信 | WordPress 自動更新で全インストール済みサイトに展開 | ユーザーの同意は事実上取れない |
特に 「所有者交代がプラグインディレクトリ上は正常」な点が脅威で、従来の信頼ベース運用(評判の良いプラグインだから安全)が機能しないことを示しています。これは pnpm 11 のサプライチェーン対策 で扱った npm エコシステムの汚染と同じ構造で、「リポジトリの信頼」は静的なものではなく、所有者ごと汚染されうることを前提に運用すべきです。
受託で組む WordPress プラグイン監査の 4 階層
弊社では、受託で運用する WordPress サイトに対して以下の 4 階層で監査を実施しています。
[Tier 1: SBOM 生成]
├ wp-cli plugin list で全プラグイン一覧
├ バージョン・所有者・最終更新日
└ 顧客サイト ID と紐付けて保存
[Tier 2: 所有者変更検知]
├ 週次でプラグインメタを取得
├ 所有者・連絡先の差分を Slack 通知
└ 過去 12 ヶ月の更新頻度を可視化
[Tier 3: 差分監査]
├ 自動更新を「ステージングのみ ON」に変更
├ 差分を ESLint / phpcs / Snyk で機械チェック
└ 異常検知後に本番反映
[Tier 4: 緊急切り離し]
├ 30 分以内にプラグイン無効化できる手順書
├ 影響範囲特定のためのアクセスログ集約
└ 顧客への一次連絡テンプレート
特に Tier 3 の「自動更新をステージングのみ ON にする」運用は実装コストが低い割に効果が大きく、WordPress サイトに必ず入れてほしい設定です。
これは SCS(Supply Chain Security)評価ガイド や npm install の任意コード実行リスク で扱ったサプライチェーン対策と同方向で、WordPress も “依存パッケージマネージャ” として扱う発想転換が必要です。
「使っていいプラグイン」を判定する 6 軸
プラグインの採用判定では、以下の 6 軸を弊社で標準化しています。
| 評価軸 | 安全側の指標 | 危険信号 |
|---|---|---|
| 所有者 | 法人運営、過去 3 年所有者変更なし | 個人所有、最近 1 年で交代 |
| 更新頻度 | 月 1 回以上の更新 | 6 ヶ月以上停滞 |
| ソースコード公開 | GitHub で公開 + コミット履歴あり | 配布バイナリのみ |
| アクティブ数 | 1 万以上 | 数百〜数千 |
| レビュー | 直近 6 ヶ月で 4.0 以上 | 評価が突然急上昇 |
| 権限要求 | 必要最小限 | ”全権限” 要求 |
「アクティブ数が多い」だけでは安全でないことは今回の事件で明らかになりました。所有者の安定性が最重要評価軸として浮上しています。
受託契約に書く「プラグイン管理条項」のひな型
プラグインの選定・更新責任を曖昧にすると、攻撃発覚時の責任所在で揉めます。受託契約に明記すべきポイントは以下です。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| プラグイン採用権限 | 弊社の事前審査を経たもののみ採用 | 顧客が独自に追加した場合の責任範囲 |
| 自動更新方針 | 本番の自動更新は OFF、ステージング検証後 | 検証 SLA |
| SBOM 共有 | 月次で全プラグイン一覧を共有 | 共有頻度 |
| インシデント対応 | 緊急時の連絡経路と SLA | 営業時間外の対応可否 |
| 所有者変更通知 | 検知次第 24 時間以内に通知 | 通知方法 |
| 代替プラグイン提案 | 危険判定時の代替案提示と移行費用 | 費用負担の按分 |
特に **「顧客が独自にプラグインを追加した場合の責任範囲」は明文化必須です。「顧客が後から入れたものは弊社の管理外、ただし発覚次第無償で削除支援」**といった切り分けが落とし所になります。
価格モデル — WordPress 監査を含めた受託パッケージ
WordPress 監査運用を含めた受託パッケージは、以下のレンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| WP Lite 監査 | 20 万円 / 3 万円〜 | 既存サイト | SBOM + 月次レポート |
| WP Standard 監査 | 60 万円 / 8 万円〜 | 中小企業・店舗系 | Lite + 週次所有者監視 + ステージング検証 |
| WP Enterprise 監査 | 200 万円〜 / 25 万円〜 | EC・会員制 | Standard + 24h 監視 + 緊急切離 SLA |
特に WP Standard 監査 は 「サイト保守料月 3〜5 万円」と組み合わせて提案しやすいレンジで、中小企業の WordPress 案件で導入しやすい価格帯です。
ハマりやすい 5 つの落とし穴
最後に、WordPress 受託でサプライチェーン攻撃対策を組むときに踏みやすい落とし穴を共有します。
落とし穴 1: 自動更新を「全 ON」のまま放置
「セキュリティのため自動更新は ON が正解」という古い情報のまま運用すると、汚染プラグインが即座に本番に展開されます。自動更新は OFF + 弊社が週次でステージング検証 → 本番反映 が現代の正解です。
落とし穴 2: SBOM を作成しない
「WordPress 管理画面で見れば分かる」という運用では、所有者交代の履歴が残りません。毎週 wp-cli で SBOM を機械的に生成し、Git で履歴管理します。
落とし穴 3: プラグインを「足し算」しか考えない
新機能のたびにプラグインを足すと、監査対象が雪だるま式に増えて品質が落ちます。新規プラグイン採用時は既存の重複機能を必ず削減するルールを設けます。
落とし穴 4: 顧客が管理画面から自由に追加できる
顧客の管理者が直接プラグインを追加できる構成では、監査の前提が崩れます。プラグイン追加権限は弊社のみにする運用を契約で合意します。
落とし穴 5: 緊急切離手順を書類化しない
「いざとなれば対応します」という口頭合意では、深夜のインシデントで誰がどう動くかが曖昧になります。営業時間外の連絡先・代理人・SLAを書面化します。
まとめ — 「信頼の前提」を疑う運用へ
Flippa を経由したプラグイン乗っ取りは、「評判の良いプラグインだから安全」という前提を根本から崩しました。WordPress を扱う受託では、所有者の変化を継続的に監視し、自動更新を慎重に運用することが、これまで以上に重要になります。
弊社では WP Lite / Standard / Enterprise の 3 段階で WordPress プラグイン監査を組み込んだ受託パッケージを提供しています。「自社サイトのプラグインが安全か不安」「WordPress 保守を継続契約で見直したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。