Команда WordPress объявила о запуске автоматизированной проверки безопасности для каждого обновления плагинов перед его распространением через API WordPress.org. Система использует ИИ-модели и Jetpack Scan для анализа изменений в коде, присваивает релизу оценку риска и автоматически блокирует распространение обновлений с высоким показателем — без участия команды модераторов. Нововведение затрагивает всех разработчиков плагинов и тем WordPress, а также администраторов сайтов, использующих автоматические обновления через панель управления WordPress.
Проблема: обновления без контроля
До сих пор новые плагины проходили ручную проверку перед добавлением в каталог WordPress.org, однако последующие обновления публиковались без какого-либо систематического аудита. Как пояснил Давид Перес, один из руководителей команды официального репозитория плагинов: «Плагин может быть безопасным сегодня, но в следующем релизе появится уязвимость или вредоносный код». Отсутствие промежуточного этапа проверки между коммитом обновления и его доставкой на миллионы сайтов создавало окно для атак через цепочку поставок.
Проблема не теоретическая. По данным WordPress, 28 июля 2026 года автоматическая система обнаружила бэкдор в обновлении неназванного плагина с примерно 20 000 активных установок. Скомпрометированная версия не была распространена через API WordPress.org, поскольку находилась в пределах периода ожидания (cooldown). Плагин был закрыт для скачивания через 26 минут после того, как команду WordPress уведомила компания Wordfence. Следует отметить, что WordPress не раскрыл название плагина, а независимого подтверждения этого инцидента в открытых источниках не обнаружено.
Как работает новая система
С 5 июня 2026 года все плагины и темы WordPress проходят обязательный период ожидания перед распространением через API обновлений — это часть инициативы Protect The Shire. Изначально задержка составляла до 24 часов, но впоследствии была сокращена до текущих шести часов. Новая автоматическая проверка встраивается именно в это временное окно и работает по следующей схеме:
- Во время периода ожидания изменения в каждом релизе анализируются несколькими ИИ-моделями совместно с Jetpack Scan.
- Результаты перекрёстно верифицируются и объединяются в итоговую оценку безопасности: чем выше балл, тем выше потенциальный риск.
- Релизы с высокой оценкой риска блокируются автоматически по завершении проверки. Обновления ниже порога проходят стандартный процесс публикации.
- Разработчики получают письмо с результатами проверки только в случае блокировки релиза.
Важная оговорка: высокая оценка риска не означает наличие вредоносного кода. WordPress прямо указывает, что случайно внесённая уязвимость может получить такой же высокий балл, как и намеренно внедрённый бэкдор. Система измеряет риск, а не умысел.
Паттерны кода, повышающие оценку риска
WordPress опубликовал конкретный перечень паттернов, на которые реагирует система:
- REST-, AJAX- и admin-post-эндпоинты без проверки прав доступа (nonce сам по себе не является авторизацией);
- SQL-запросы, построенные без
$wpdb->prepare(); - Работа с файлами (пути, загрузки, удаления, подключения) на основе данных из запроса;
- Вызовы
unserialize()для данных из запросов или удалённых ответов; - Запись в опции, метаданные пользователей или настройки из эндпоинтов, доступных подписчикам или неаутентифицированным пользователям;
- Загрузка и выполнение кода во время работы, обфусцированный или упакованный код.
Разработчикам рекомендуется проверять код с помощью WordPress Coding Standards и PHP_CodeSniffer. Авторам расширений для WooCommerce предлагается использовать платформу Quality Insights Toolkit.
Что делать при блокировке релиза
Единственный способ снять блокировку — исправить выявленные проблемы и опубликовать новую версию. Если обновлённый релиз получит оценку ниже порога блокировки, он пройдёт стандартный процесс с шестичасовым периодом ожидания. Разработчики могут обжаловать результат через обращение к команде Plugins Team, однако, как отмечает Перес, выпуск исправленной версии почти всегда быстрее ожидания ручной проверки апелляции.
Оценка воздействия
Нововведение затрагивает всю экосистему WordPress.org — каждый плагин и каждую тему, распространяемые через официальный API обновлений, включая обновления в один клик из панели управления. Для разработчиков это означает необходимость более тщательного соблюдения стандартов кодирования: даже непреднамеренные ошибки безопасности могут привести к блокировке релиза и задержке доставки обновлений пользователям.
При этом система охватывает только канал распространения WordPress.org. Плагины, установленные из сторонних источников или обновляемые через собственные механизмы разработчиков, под действие этой проверки не подпадают. Ранее мы уже писали об уязвимостях в плагинах WordPress, и новая система направлена именно на предотвращение подобных ситуаций на этапе распространения.
Автоматическая проверка безопасности — логичное развитие инициативы Protect The Shire, которая последовательно выстраивает многоуровневую защиту цепочки поставок WordPress. Администраторам сайтов на WordPress дополнительных действий предпринимать не нужно: система работает на стороне WordPress.org. Разработчикам плагинов стоит уже сейчас прогнать свой код через WordPress Coding Standards и PHP_CodeSniffer, чтобы следующий релиз не оказался заблокирован из-за паттернов, которые система расценит как рискованные.
