WordPress、プラグイン更新の自動セキュリティ審査を導入　高リスクなアップデートを配信前に自動遮断

要点

• WordPressが、WordPress.orgを通じて配布されるすべてのプラグイン更新を対象に、配信前の自動セキュリティレビューを導入した。

• 配信待機用の「クールダウン期間」（6時間）中にAIモデルとJetpack Scanでコード変更を解析し、高リスクな更新を自動的に遮断する。

• 2026年7月には約2万件のアクティブインストールを持つプラグインへのバックドア混入を検知し、ユーザーへの配布を未然に防いだ実績がある。

• 認可チェックの不備や安全でないSQLクエリ、難読化コードなどが検知対象となり、意図的な不正コードだけでなく不注意による脆弱性もスコアに反映される。

• 配信がブロックされた場合、開発者は指摘箇所を修正した新リリースを公開することで制限を解除できる。

• コンテンツ管理システム（CMS）のWordPressは、公式ディレクトリ（WordPress.org）のアップデートAPIを通じて配布されるすべてのプラグイン更新に対し、自動セキュリティレビューの運用を開始した。新規登録時だけでなく、その後に継続してリリースされるアップデートの安全性を配布前に検証し、セキュリティ被害を未然に防ぐ仕組みだ。

プラグイン更新に存在したセキュリティの空白

WordPressの公式ディレクトリでは、新規プラグインの初回登録時には審査が行われていたものの、その後のバージョンアップは自動的に配信される体制となっていた。WordPress公式プラグインリポジトリチームの共同リードを務めるデビッド・ペレス（David Perez）氏によると、リリースのコミットから下流ユーザーへの配布までの間に一貫したレビュー手順が存在しなかったため、安全だったプラグインであっても将来の更新で脆弱性や悪意あるコードが混入するリスクを抱えていたという。

この検証体制の有効性はすでに実証されている。2026年7月28日、約2万件のアクティブインストールを持つプラグインの更新においてバックドア（不正侵入用の抜け穴）の混入が自動レビューによって検出された。当該リリースが配信前の待機時間内にあったため、WordPress.orgのアップデートAPIを通じてエンドユーザーへ悪意あるバージョンが届く事態は回避された。セキュリティ企業Wordfenceからの通知を受け、プラグインチームは26分以内に該当プラグインのダウンロードを停止したという（プラグイン名は非公開）。

AIとJetpack Scanによる自動審査のプロセス

今回の審査体制は、2026年6月5日に導入されたセキュリティ施策「Protect The Shire」の枠組みを活用している。同施策では、悪意ある更新が即座にユーザーへ届かないよう、すべてのプラグインとテーマの自動更新前に「クールダウン期間」（公開から自動更新配信までに設ける待機時間。当初24時間から現在は6時間）が設定されている。

自動レビューは、この6時間のクールダウン期間中にWordPress.org上で実行される。具体的な処理の流れは以下の通りだ。

1. コード解析：各リリースの変更差分を、AIモデルと脆弱性スキャンツール「Jetpack Scan」によって解析する。
2. リスクスコアの算出：解析結果を相互検証し、潜在的なリスクの高さを示すセキュリティスコアを算出する。
3. 自動ブロック：スコアが高リスク閾値に達したリリースは、チームの手動介入を待たずに自動で配信が停止される。閾値未満のものは通常の配信フローへ進む。
4. 開発者への通知：リリースがブロックされた場合に限り、検出内容を記載したメールがコミッター（開発担当者）に送信される。

なお、高リスクスコアは意図的な不正コードだけでなく、開発者が不注意によって混入させたセキュリティ上の欠陥に対しても付与される仕様となっている。

スコア上昇を招く主な実装パターン

ペレス氏によると、自動レビューでは一般的なセキュリティ監査と同様の脆弱性を検査している。特にリスクスコアの上昇につながる主なパターンとして以下が挙げられている。

• 権限チェックのないエンドポイント：REST API、AJAX、admin-postのエンドポイントで適切な権限確認（capability check）がない実装。なお、リクエスト検証用のワンタイムトークンであるnonce（ノンス）のみでは認可として不十分とされる。
• 安全でないデータベースクエリ：SQLインジェクションを防ぐ関数 $wpdb->prepare() を用いずに構築されたクエリ。
• リクエスト値によるファイル操作：ユーザー入力を検証せずに利用したファイルパス生成、アップロード、削除、ファイル読み込み（include）。
• 危険なデシリアライズ：リクエストデータや外部応答に対し、文字列をPHPデータに復元する unserialize() を適用する処理。
• 不正な設定・メタ更新：購読者権限や未認証ユーザーからアクセス可能なエンドポイントによるオプション値やユーザーメタの変更。
• 実行時コード評価・難読化：実行時の外部コード取得や評価（eval）、難読化・圧縮されたコード。

開発者に求められる対応とブロック時の手順

ペレス氏は開発者に対し、WordPressの標準規約「WordPress Coding Standards」や構文チェックツール「PHP_CodeSniffer（PHPCS）」によるコード検証を呼びかけている。また、WooCommerce拡張機能の開発者には品質テスト基盤「Quality Insights Toolkit（QIT）」の利用を推奨している。

リリースがブロックされた場合、制限を解除するには指摘内容を確認して問題を修正し、新バージョンを再公開する必要がある。新リリースのスコアが高リスク閾値を下回れば、通常通りクールダウン期間を経て配布される。

誤検知と思われる場合はプラグインチームへ問い合わせることも可能だが、ペレス氏は「チームが膨大な数のレビューを処理しているため、異議申し立ての手動審査を待つよりも修正版を公開する方がほぼ確実に早い」と説明し、迅速な修正リリースの公開を推奨している。