WordPress.orgがプラグイン配布前の自動セキュリティ審査を導入 — 7月には約2万サイトで使われるプラグインへのバックドア混入を配布前に阻止

要点

• WordPress.orgのプラグインチームは2026年9月9日、プラグインのすべてのリリースを配布前に自動でセキュリティ審査する仕組みを導入した。審査でリスクが高いと判定された版は、WordPress.orgの更新APIを通じて配布される前に自動でブロックされる。
• WordPress.orgは、この仕組みの必要性を示す事案として2026年7月28日のバックドア混入事案を挙げている。約2万サイトで有効化されていたプラグインの新版にバックドアがコミットされたが、自動審査が高いセキュリティスコアを付け、その版がクールダウン期間内だったため、問題のある版は配布されなかった。プラグイン名は公表されていない。
• 配布前の待機時間（クールダウン）は2026年6月5日開始の取り組み「Protect The Shire」で始まった。当初は最大24時間だった待機時間は、現在は6時間になっている。
• WordPress.orgは**「スコアが高いことは悪意を示すものではない」**と明記し、誤って入り込んだ脆弱性も意図的なマルウェアと同じくらい高いスコアになり得ると説明している。あわせて、誤検知（false positive）の報告を最も有用なフィードバックとして求めている。

何が変わるのか

WordPress.orgのプラグインチームのDavid Perez氏（@davidperez）は2026年9月9日、公式ブログ「Make WordPress Plugins」でプラグインのリリースごとの自動セキュリティ審査の開始を発表した。

発表によると、新しいプラグインはディレクトリに登録される前に審査される。一方で、登録後の更新は継続的に配布され、リリースがコミットされてから数百万サイトに届くまでの間に一貫した審査ステップが存在しなかった。WordPress.orgは「プラグインは今日は安全でも、将来のリリースで脆弱性や悪意のあるコードを持ち込む可能性がある」と説明している。

新しい仕組みでは、リリースがWordPress.orgの更新APIを通じて配布される前に、セキュリティ上の問題（意図的なものか意図しないものかを問わない）を解析し、潜在的なリスクがあると判断された版は配布しない。

7月28日のバックドアは配布前に止まった

WordPress.orgが公表した事案は次のとおりだ。

2026年7月28日、約2万サイトで有効化されていたプラグインのリリースにバックドア（正規のソフトウェアに混入される不正な侵入経路）がコミットされた。自動審査はこれを検知して高いセキュリティスコアを付け、そのリリースはまだクールダウン期間内だったため、問題のある版がWordPress.orgの更新APIを通じて配布されることはなかった。

プラグインチームがセキュリティ企業Wordfenceから更新の連絡を受けた26分後に、このプラグインはダウンロードが停止されたという。WordPress.orgは問題のプラグイン名を公表していない。

審査の仕組み：クールダウン中の解析とスコアによる自動ブロック

配布前の待機は2026年6月5日から始まっている。WordPress.orgのMatt Mullenweg氏が同日に公表した取り組み「Protect The Shire」で、プラグインとテーマの新しい版は自動更新で配布されるまでに待機時間を設ける方針が示された。開始時の待機時間は最大24時間だったが、2026年9月9日の発表では現在は6時間と説明されている。

この待機時間のあいだに、WordPress.orgは複数のAIモデルとJetpack Scanを組み合わせて各リリースの変更点を解析する。解析結果は突き合わせたうえでセキュリティスコアとしてまとめられ、スコアが高いほど潜在的なリスクが高いと判定される。複数のツールで突き合わせることで精度を高め、誤検知を抑えているが、誤検知はゼロではないという。

スコアが高い版は、審査が終わった時点で自動的にブロックされる。ブロックされた版は、問題が解決するまでWordPress.orgの更新APIを通じて配布されない。コミット権限を持つすべての開発者には、検知内容を記載したメールが届く。しきい値を下回った版は通常どおりの手順で配布される。なお、現時点でメールはブロックされた場合にのみ送信されるため、メールが届いていない開発者は対応する必要がないとWordPress.orgは説明している。

WordPress.orgは、スコアが高いことは悪意を示すものではないと明記している。意図せず入り込んだ脆弱性が、意図的なマルウェアと同じくらい高いスコアになることはあるという。スコアが測るのはリスクの大きさであり、意図ではない。

ブロックされた場合の手順

WordPress.orgは、ブロックされたリリースを解除する最も速い方法として次を示している。

• 通知された検知内容を確認する
• 問題を修正し、新しいリリースを公開する。新しいリリースのスコアがしきい値を下回れば、通常のクールダウン手順に進む
• 検知内容が誤っていると思われる場合はプラグインチームに連絡する。ただしチームは大量の審査を抱えているため、修正版の公開が、異議申し立ての人手審査を待つよりもほぼ常に速いとWordPress.orgは説明している

事前に確認しておくべき項目（プラグインチームの推奨）

Perez氏はブログのコメント欄で、リリース前に自ら確認しておく手段を挙げている。

• WordPress Coding Standardsを適用したPHPCS（PHP_CodeSniffer）。WordPress-ExtraルールセットにはWordPress.Security.*のsniff（EscapeOutput、ValidatedSanitizedInput、NonceVerification）が含まれる。検知される内容の多くはエスケープ漏れや権限確認・nonce確認の不足だという
• Plugin Check（ローカルまたはCIではwordpress/plugin-check-action）
• データの流れを追う静的解析（szepeviktor/phpstan-wordpressを使ったPHPStan、またはWordPress向けルールを適用したSemgrep）。別ファイルを経てユーザー入力が処理地点に届くような、sniff型のツールでは見つけにくい問題を検知できるという
• WooCommerce拡張機能を公開している場合はQIT（Quality Insights Toolkit）

あわせて、スコアを押し上げやすいコードのパターンとして次が挙げられている。

• 権限確認（capability check）のないREST、AJAX、admin-postのエンドポイント。nonceだけでは認可にならない
• $wpdb->prepare()を使わずに組み立てられたクエリ
• リクエストのデータから組み立てられたファイルパス、アップロード、削除、include
• リクエストのデータやリモートの応答に対するunserialize()
• 購読者権限や未認証の利用者から到達できるエンドポイントからの、オプション・ユーザーメタ・設定の書き込み
• 実行時に取得・評価されるコード、難読化・パックされたコード

Perez氏は「これらは人の目による確認の代わりにはならない」としたうえで、管理者向け画面用に書いたエンドポイントが誰からでも到達できる状態になっているケースが最も多いとし、リリース前に短いセキュリティ観点の確認を行うことの効果を挙げている。

サイト運営者にとっての意味

今回の変更は、WordPress.orgの更新APIを使う側の挙動も変える。あるリリースが自動審査でブロックされた場合、その版はダッシュボードからのワンクリック更新を含めて配布されない。サイトには以前の版が残り、開発者が修正版を公開してスコアがしきい値を下回れば、通常のクールダウン手順を経て配布される。

WordPress.orgは、この審査は今後もデータを集めながら改善を続けるとして、誤検知に関するフィードバックが最も有用だとしている。

出典

• WordPress.org Plugins Team「Automated security review for plugin releases」2026年9月9日 https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/
• WordPress.org「Protect The Shire」2026年6月5日 https://wordpress.org/news/2026/06/pts/