WordPress объявила о запуске автоматической проверки безопасности каждого выпуска плагина перед его распространением через API обновлений WordPress.org. Система анализирует обновления на наличие потенциальных уязвимостей и других рисков безопасности.
"Новые плагины проходят проверку перед добавлением в каталог, но после этого обновления выпускаются постоянно. Плагин может быть безопасным сегодня, а в следующем релизе получить уязвимость или вредоносный код" - заявил Дэвид Перес, один из руководителей команды официального репозитория плагинов WordPress.
По словам WordPress, отсутствие последовательного этапа проверки между фиксацией выпуска и его доставкой пользователям создавало возможность для вредоносных атак.
CMS сообщила, что автоматическая проверка обнаружила бэкдор в одном из выпусков плагина с примерно 20 000 активных установок 28 июля 2026 года. Поскольку этот выпуск находился в периоде задержки перед распространением, скомпрометированная версия так и не была доставлена через API обновлений WordPress.org.
Через 26 минут после того, как компания Wordfence, специализирующаяся на безопасности WordPress, уведомила команду плагинов об обновлении, загрузка плагина была заблокирована. Название плагина WordPress не раскрыла.
С 5 июня 2026 года каждый плагин и тема WordPress проходят период задержки перед распространением через автоматические обновления. Этот механизм стал частью новой инициативы по безопасности Protect The Shire. Идея заключается в том, чтобы добавить дополнительный барьер в процесс выпуска и не позволять вредоносным обновлениям сразу попадать к конечным пользователям.
Сейчас период задержки составляет шесть часов. Изначально он был установлен на уровне 24 часов.
Новая система должна закрыть еще одну критическую брешь в безопасности: выпуск плагина или темы с высоким уровнем риска теперь автоматически блокируется без участия команды плагинов.
Процесс проверки состоит из нескольких этапов.
В течение периода задержки изменения каждого выпуска анализируются на WordPress.org с помощью моделей искусственного интеллекта (AI) и Jetpack Scan.
Результаты проверок сопоставляются и объединяются в единый показатель безопасности. Чем выше показатель, тем выше потенциальный риск.
Выпуски с высоким показателем риска автоматически блокируются после завершения проверки. Выпуски, не достигшие установленного порога, продолжают проходить обычный процесс публикации.
Разработчики плагина получают электронное письмо с результатами проверки. Такие письма отправляются только в случае блокировки выпуска.
При этом высокий показатель риска не обязательно означает, что разработчик действовал намеренно. Система учитывает не только признаки вредоносного кода, но и случайно внесенные уязвимости.
В комментарии к объявлению Перес уточнил, что проверка безопасности ищет те же классы уязвимостей, которые обычно выявляются в ходе аудита безопасности. Разработчикам рекомендуется использовать WordPress Coding Standards и правила PHP_CodeSniffer (PHPCS) для проверки кода и контроля его качества.
Разработчикам расширений для WooCommerce рекомендуется использовать платформу тестирования Quality Insights Toolkit (QIT).
Повысить показатель риска также могут следующие особенности кода:
REST-, AJAX- или admin-post-эндпоинты без проверки capability. Один nonce сам по себе не является механизмом авторизации.
Запросы, сформированные без использования
$wpdb->prepare().Пути к файлам, загрузка, удаление или подключение файлов, построенные на основе данных из запросов.
Использование
unserialize()для данных из запросов или удаленных ответов.Запись options, user meta или настроек через эндпоинты, доступные пользователям с ролью subscriber или неавторизованным пользователям.
Получение или выполнение кода во время работы приложения, а также обфусцированный или упакованный код.
После блокировки выпуска разработчик может снять ограничения только одним способом: изучить результаты проверки, исправить обнаруженные проблемы и выпустить новую версию. Если новый выпуск получит показатель ниже порога высокого риска, он продолжит проходить стандартный процесс с периодом задержки.
"Если результат проверки кажется ошибочным, авторы могут обратиться к команде плагинов. Однако команда обрабатывает большое количество проверок, поэтому публикация исправленного выпуска почти всегда оказывается быстрее, чем ожидание ручного рассмотрения апелляции" - отметил Перес.
Источник: HN