9 сентября команда плагинов WordPress.org объявила о запуске автоматической проверки безопасности для каждого релиза плагина. Теперь до того, как версия уйдёт в update API WordPress.org — то есть до того, как она появится у вас в дашборде, — её изменения анализируются на предмет безопасности. Релизы, признанные потенциально рискованными (умышленно или случайно), блокируются автоматически.
Это заметное изменение в процессе, о котором стоит знать и владельцам сайтов, и тем, кто плагины делает.
Что именно изменилось
Логика каталога была такой: новый плагин проверяют перед тем, как пустить его в каталог, но дальше обновления выходят непрерывно. Плагин может быть безопасным сегодня и принести уязвимость или вредоносный код в следующем релизе. Единого шага проверки между коммитом и выпуском до сих пор не было — именно эту дыру и закрывают.
Как это работает сейчас:
- С 5 июня каждый релиз плагинов и тем проходит через cooldown перед распространением через update API, включая обновления в один клик из админки. Сейчас пауза — 6 часов.
- В течение этой паузы изменения анализируются на стороне WordPress.org: несколько ИИ-моделей вместе с Jetpack Scan. Результаты перекрёстно сверяются и превращаются в находки с оценкой безопасности — чем выше балл, тем выше потенциальный риск.
- Релизы с высоким баллом блокируются автоматически, как только проверка завершается. Всем коммиттерам плагина уходит письмо с находками. Релизы ниже порога продолжают идти обычным путём.
- Письма приходят только при блокировке: если вам ничего не написа́ли, делать ничего не нужно.
Перекрёстная проверка несколькими инструментами держит точность высокой, но, как честно отмечают авторы, не абсолютной — поэтому обратная связь по ложным срабатываниям для них особенно ценна.
Почему это появилось: июльский бэкдор и 26 минут
28 июля бэкдор был закоммичен в релиз плагина с примерно 20 000 активных установок. Автоматическая проверка его обнаружила и присвоила высокий балл безопасности. Релиз ещё находился внутри cooldown-окна, поэтому скомпрометированная версия так и не была распространена через update API. Плагин закрыли для скачивания через 26 минут после того, как Wordfence сообщил команде о случившемся.
Итог хороший, но он показал недостающую деталь: остановка распространения зависела от того, что кто-то из команды оказался на месте и успел среагировать. Автоматическая блокировка убирает эту зависимость.
Высокий балл не означает злой умысел
Важная оговорка, которую стоит прочитать дважды: оценка измеряет риск, а не намерение. Случайно внесённая уязвимость может получить такой же высокий балл, как умышленный вредоносный код.
По наблюдению команды, большинство находок — это не вредоносный код, а эндпоинт, написанный для админского экрана и оказавшийся доступным кому угодно. Типичная история: функция делалась «для своих», проверка прав забыта, а маршрут отвечает всем.
Если релиз заблокирован
Порядок действий, который предлагает команда:
1. Разобрать присланные находки — они описывают, что именно вызвало блокировку.
2. Исправить и выпустить новый релиз. Если новый релиз набирает балл ниже порога, он проходит обычный cooldown.
3. Если находка кажется неверной, можно обратиться к команде плагинов. Но объём проверок большой, и выпустить исправленный релиз почти всегда быстрее, чем ждать ручного разбора апелляции.
Что это значит для владельцев сайтов
Практических следствий два, и одно из них неочевидное.
- Обновления, которые предлагает ваш дашборд, теперь прошли проверку. Скомпрометированная версия просто не доедет до вас — её отсекут раньше. Раньше такой гарантии не было: заражённый релиз оказывался в списке обновлений и ждал, пока кто-то заметит.
- Между релизом и его доступностью появилась пауза. Сейчас это 6 часов. Для срочных патчей безопасности это означает задержку: если вендор выпустил исправление критической уязвимости, оно появится в дашборде не сразу — для чувствительных сайтов стоит договориться с разработчиком о прямой доставке или ставить патч вручную из проверенного источника.
Автоматическая проверка не отменяет базовых мер на стороне сайта: резервные копии, тестовый контур для обновлений, ограничение админского доступа и контроль изменений в файлах остаются вашей зоной ответственности. Проверка релиза защищает от чужого кода, но не от вашей собственной ошибки в настройках.
Как проверять плагины заранее: инструменты
Автор анонса Дэвид Перес в комментариях перечислил, чем авторам плагинов стоит пользоваться, чтобы не доходить до блокировки. Порядок — по отдаче:
- PHPCS с WordPress Coding Standards. Набор
WordPress-Extraвключает сниффыWordPress.Security.*— EscapeOutput, ValidatedSanitizedInput, NonceVerification. Большая часть того, что ловит автоматическая проверка, — это неэкранированный вывод или отсутствующая проверка прав и nonce. Прогон на каждом пул-реквесте отсекает это задолго до релиза:
composer require --dev wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer
vendor/bin/phpcs --standard=WordPress-Extra .- Plugin Check — локально или в CI через официальное действие. Это не только про безопасность: проверяются readme, локализация, производительность и требования каталога, но категория безопасности и проверка позднего экранирования заметно перекрываются с находками авто-ревью.
- Статический анализ, который следит за потоком данных — PHPStan с пакетом
szepeviktor/phpstan-wordpressили Semgrep с правилами для WordPress. Здесь находятся самые интересные случаи: пользовательский ввод, доходящий до «стока» через несколько файлов, чего сниффы просто не видят. - QIT, если вы публикуете расширения WooCommerce: там к проверкам совместимости добавлены сканирования безопасности.
Паттерны, которые чаще всего поднимают балл
Команда перечислила, на что реагирует проверка. Список полезен как чек-лист при ревью кода:
- REST-, AJAX- или admin-post-эндпоинты без проверки прав доступа. Отдельно подчёркнуто: nonce сам по себе не является авторизацией.
- Запросы к базе, собранные без
$wpdb->prepare(). - Пути к файлам, загрузка, удаление и подключение файлов, собранные из данных запроса.
unserialize()для данных запроса или ответа удалённого сервиса.- Опции, метаданные пользователей и настройки, которые записываются из эндпоинтов, доступных подписчикам или неавторизованным пользователям.
- Код, получаемый или исполняемый во время выполнения, а также обфусцированный и упакованный код.
Что из этого следует
- Для владельцев сайтов: канал автоматических обновлений стал фильтрованным, но появилась задержка около 6 часов. Планируйте срочные патчи отдельно от «просто обновиться».
- Для авторов плагинов: блокировка — это не обвинение. Оценка измеряет риск, а не намерение, и разблокировать релиз быстрее всего новым исправленным релизом, а не апелляцией.
- Для разработчиков: проверку стоит перенести влево — в CI на каждый пул-реквест. PHPCS с
WordPress-Extra, Plugin Check и статический анализ закрывают большую часть типовых находок. - Отдельно про права доступа: nonce и проверка capability — разные вещи, и проверка не заменяется проверкой. Именно эта путаница даёт заметную долю находок.
- Про ложные срабатывания: сообщать о них команде полезно — это то, на чём система учится, и единственный способ сделать порог точнее.
Если вы ведёте сайты на WordPress и хотите, чтобы обновления и безопасность не зависели от того, вспомнил ли кто-то про обновление, — посмотрите, как мы устроили эту работу на своих проектах. Про свежие изменения в ядре мы писали в разборе WordPress 7.1, а про магазины — в материале про WooCommerce 11.1.
По материалам make.wordpress.org (David Perez, 9 сентября 2026) и комментариев Дэвида Переса к анонсу.
