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