WordPress.org с 9 сентября 2026 года автоматически проверяет каждый новый релиз плагина и блокирует те, что набрали высокую оценку риска, ещё до рассылки на сайты через автообновления. Для владельца сайта это значит две вещи: обновление приходит не мгновенно, а после проверки, и часть заражённых версий до сайта просто не доезжает.
Объявление опубликовала команда плагинов WordPress.org в записи об автоматической проверке безопасности релизов. По профильным изданиям новость разошлась в середине сентября, и в техподдержку сразу пошли вопросы от клиентов: почему плагин обновился только к вечеру, почему подрядчик пишет, что его релиз заблокировали, и стоит ли теперь вообще держать автообновления включёнными.
Что именно объявил WordPress.org
Каталог начал сам сканировать код каждого релиза и останавливать подозрительные версии без участия человека. Раньше решение о блокировке принимала команда плагинов, обычно после сигнала от исследователей безопасности или жалобы пользователей. Теперь проверка запускается на каждый релиз без исключений.
Устроено это так. Изменения в релизе анализируют несколько ИИ-моделей вместе с сервисом Jetpack Scan, результаты перепроверяются между собой и сводятся в одну оценку риска. Чем выше оценка, тем выше потенциальная опасность релиза. Версии с высокой оценкой блокируются автоматически сразу по окончании проверки, а всем, у кого есть права коммита в плагин, уходит письмо.
Важная оговорка, которую команда сделала отдельно: высокая оценка не означает злого умысла. Оценка измеряет риск, а не намерение автора. Разработчик может получить блокировку из-за неудачной конструкции в коде, а не из-за попытки что-то спрятать. Дальше у него два пути: исправить найденные проблемы и выпустить новый релиз либо, если он считает срабатывание ошибочным, написать в команду плагинов.
Для владельца сайта здесь принципиально то, что фильтр стоит на стороне каталога. Заражённая версия не попадает в API обновлений, а значит, не приходит ни на один сайт с включёнными автообновлениями. Ничего настраивать у себя для этого не нужно.
Откуда взялась задержка обновлений и что такое Protect The Shire
Автоматическая проверка, это вторая часть инициативы, которая стартовала ещё в начале лета. 5 июня 2026 года Мэтт Мулленвег объявил инициативу Protect The Shire: для каждого релиза плагина и темы в каталоге вводился временный период охлаждения перед рассылкой через автообновления.
Период охлаждения (cooldown) это пауза между публикацией новой версии в каталоге WordPress.org и её рассылкой на сайты. Изначально пауза составляла 24 часа, сейчас она сокращена до 6 часов. Именно в это окно и укладывается автоматическая проверка кода.
Логика понятная. Если вредоносный релиз доезжает до сайтов мгновенно, у защитников нет ни одного шанса вмешаться. Пауза даёт время машине проверить код, а команде среагировать на сигнал. Инициатива распространяется на весь каталог, а это больше 78 тысяч плагинов и тем.
Двадцать четыре часа многим показались перебором. Разработчики плагинов и компании, обслуживающие чужие сайты, публично возражали против такой задержки: она мешала выкатывать срочные исправления. После обратной связи окно сократили до шести часов, и в таком виде оно работает сейчас.
Система успела показать себя до официального анонса автопроверки. В конце июля в плагин с примерно 20 тысячами активных установок был встроен бэкдор. Автоматическая проверка его обнаружила, и релиз закрыли через 26 минут после уведомления от исследователей. Раньше на такой сценарий уходили часы или сутки, и за это время обновление успевало разойтись по сайтам.
Что изменилось для сайта на практике
Меняется момент, когда обновление доезжает до вашего сайта, и то, что с ним происходит по дороге. Сам механизм автообновлений остался прежним: официальная документация по фоновым автообновлениям не поменялась, изменилась сторона каталога.
| Этап | Как было до июня 2026 | Как устроено сейчас |
|---|---|---|
| От публикации релиза до рассылки | Практически сразу | Период охлаждения, сейчас 6 часов |
| Проверка кода релиза | Выборочная, по сигналам исследователей и жалобам | Автоматическая для каждого релиза: ИИ-модели плюс Jetpack Scan |
| Опасный релиз | Снимался после обращения, часть сайтов успевала обновиться | Блокируется автоматически по итогам проверки, до рассылки |
| Кого уведомляют о блокировке | Автора, в переписке с командой | Всех коммиттеров плагина, письмом сразу после блокировки |
Обратная сторона тоже есть. Срочная заплатка к свежей уязвимости теперь тоже ждёт своё окно. Если разработчик выложил экстренный фикс, ваш сайт получит его не через минуту, а в пределах нескольких часов. Для большинства сайтов это несущественно. Но если вы ведёте проект, где уязвимость уже эксплуатируется, обновление стоит поставить руками из админки: ручная установка окна охлаждения не ждёт.
Сколько теперь ждать обновление плагина
До шести часов с момента публикации релиза автором. На старте инициативы окно было 24 часа, но его сократили вчетверо после обратной связи от сообщества.
На обычную работу это почти не влияет, если вы не следите за версиями по часам. Плагин обновится в течение дня, как и раньше. Задержку замечают в основном две категории: разработчики, которые ждут выхода собственного релиза, и подрядчики, обслуживающие десятки сайтов и привыкшие катить обновления пачкой сразу после публикации.
На проектах B2BPRO.KZ мы чаще всего видим другую проблему, и она серьёзнее шестичасовой паузы: на сайте вообще никто не смотрит, какие версии стоят. Автообновления выключены полгода назад, чтобы ничего не сломалось, бэкапов нет, а список плагинов не пересматривался с момента запуска. На таком сайте задержка в шесть часов не имеет никакого значения, потому что обновление не приедет ни через шесть часов, ни через полгода.
Почему автоблокировка не закрывает вопрос безопасности
Новый фильтр защищает от плохого свежего релиза, но никак не помогает сайту, который не обновляется вообще. Разница принципиальная, и она хорошо видна на свежем примере.
В плагине All-in-One WP Migration and Backup нашли SQL-инъекцию, позволяющую выполнить код удалённо и без авторизации, то есть полностью захватить сайт. Уязвимость получила идентификатор CVE-2026-19949 и оценку 8,8 из 10 по шкале CVSS. Разработчик выпустил исправленную версию 7.110 ещё 20 августа 2026 года. К началу сентября обновились около 35% пользователей, а примерно 3,2 миллиона сайтов продолжали работать на уязвимых версиях.
Ни автоматическая проверка релизов, ни период охлаждения такому сайту не помогут. Исправление лежит в каталоге, проверку оно прошло, рассылка давно состоялась. Но если на сайте выключены автообновления и никто не заходит в админку месяцами, дыра остаётся открытой. По отчётам исследователей, между публикацией уязвимости и первыми массовыми попытками эксплуатации проходят часы, а не недели: злоумышленники читают те же бюллетени, что и специалисты по безопасности.
Ещё одна категория остаётся полностью вне защиты, это плагины и темы не из каталога. Всё, что скачано с торрентов, форумов и сомнительных сборок, никакой проверки WordPress.org не проходит по определению. Именно в таких сборках чаще всего и приезжает бэкдор. В Казахстане это всё ещё распространённая история: премиальную тему берут с ключом вместо лицензии, а через полгода сайт раздаёт редиректы на чужие ресурсы.
Отдельно стоит сказать про заброшенные плагины. Автопроверка срабатывает на релиз, а у плагина, который не обновлялся три года, релизов нет. Проверять нечего, и формально с ним всё в порядке, пока кто-нибудь не найдёт в нём уязвимость. Такие расширения опаснее всего именно тем, что выглядят спокойно: они стоят, работают и не просят внимания.
Что сделать прямо сейчас
Порядок действий на ближайшие полчаса выглядит так:
- Откройте раздел «Плагины» в админке и посмотрите, сколько расширений ждут обновления. Если счётчик двузначный, на сайте давно не было обслуживания.
- Снимите резервную копию: файлы и база данных. Копия должна лежать не только на том же хостинге, иначе при компрометации сервера вы потеряете и сайт, и бэкап.
- Обновите ядро WordPress, затем плагины, затем темы. После каждой пачки открывайте главную страницу и ключевые формы, проверяйте, что ничего не сломалось.
- Проверьте, включены ли автообновления для плагинов. В списке плагинов у каждой строки есть переключатель «Включить автообновления».
- Удалите то, чем не пользуетесь. Именно удалите, а не деактивируйте: файлы деактивированного плагина остаются на сервере и в ряде сценариев остаются достижимыми.
- Посмотрите на дату последнего обновления каждого плагина на его странице в каталоге. Расширение, которое не обновлялось несколько лет, пора менять на живой аналог.
- Сверьте список плагинов с каталогом WordPress.org. Всё, чего там нет и что не куплено у вендора напрямую, кандидат на замену.
- Заведите календарное правило: раз в неделю кто-то открывает админку и смотрит обновления. Без назначенного ответственного это не работает.
- Если сайт коммерческий и простой день стоит денег, заведите тестовую копию и катите обновления сначала туда.
Отдельный пункт для тех, у кого сайт сделан на заказ: уточните у подрядчика, есть ли на проекте собственные плагины. Если часть функциональности написана специально под вас, она распространяется мимо каталога, и автоматическая проверка WordPress.org её не касается вообще. Ответственность за её безопасность целиком на разработчике, и это один из вопросов, которые стоит задавать до подписания договора на разработку сайта под ключ, а не после инцидента.
Типичные ошибки владельцев сайтов
Большая часть взломов WordPress в нашей практике начинается не с изощрённой атаки, а с одного из пяти бытовых сценариев.
Первый: автообновления выключили и забыли. Год назад обновление сломало вёрстку, автообновления отключили, вернуться забыли. Сайт постепенно накапливает известные уязвимости. Теперь, когда каталог фильтрует релизы на своей стороне, аргумент «автообновления опасны» стал слабее, чем был.
Второй: бэкапы лежат рядом с сайтом. Копия в соседней папке на том же аккаунте хостинга спасает от неудачного обновления, но не спасает от взлома и не спасает от сбоя самого хостинга. Нужна внешняя копия, физически в другом месте.
Третий: плагины ставят посмотреть и не убирают. Каждое неиспользуемое расширение, это лишний код, который кто-то поддерживает, а может и не поддерживать. За пару лет такого подхода в админке набирается тридцать плагинов, из которых реально работают восемь.
Четвёртый: нелицензионные премиум-плагины. Вне каталога нет ни проверки, ни обновлений, ни ответственности. Экономия на лицензии в сто долларов регулярно оборачивается неделей восстановления сайта и потерянными позициями в поиске.
Пятый: нет ответственного. Фраза «сайтом занимается маркетолог» на практике означает, что сайтом не занимается никто. Обслуживание нужно назначить человеку или подрядчику явно, с понятным перечнем работ и сроками.
Чем автоматическая проверка отличается от ручной модерации
Ручная модерация в каталоге WordPress.org никуда не делась, она по-прежнему работает при первичной публикации плагина. Новая система добавляет второй слой: проверку каждой последующей версии.
Разница в масштабе. Первичная модерация касается новых плагинов, а обновлений выходят тысячи в неделю, вручную их не просмотреть. По данным профильных изданий, число еженедельных заявок в каталог выросло примерно со 150 в 2024 году до более чем 500 к началу 2026-го, и рост связывают с распространением инструментов разработки на базе ИИ. Кода стало кратно больше, и просматривать его глазами команда физически не успевает.
Отсюда и выбор инструментов: ИИ-модели плюс сканер. Первые ловят подозрительные конструкции и нетипичные изменения, второй известные вредоносные шаблоны. Итог сводится в одну оценку, по которой и принимается решение о блокировке. Понятно, что такая схема будет давать и ложные срабатывания, поэтому команда прямо описала процедуру для авторов, которые с блокировкой не согласны.
Стоит ли что-то менять в работе с сайтом
Для большинства компаний почти ничего, кроме одного: автообновления теперь имеет смысл держать включёнными. Раньше аргумент против них звучал так: между публикацией заражённого релиза и его приездом на сайт нет никакого фильтра, поэтому лучше обновляться руками и осознанно. Этот аргумент ослаб, потому что фильтр появился.
Остаётся вторая причина, по которой автообновления отключают: страх, что новая версия сломает вёрстку или конфликтнёт с другим плагином. Эта проблема никуда не делась, и решается она не отключением обновлений, а тестовой копией сайта и регулярным обслуживанием. Схема, которую мы ставим клиентам: автообновления включены для всех расширений, тестовая копия обновляется первой, живой сайт следом, резервная копия снимается перед каждой пачкой.
Компаниям, у которых сайт завязан на заявки и оплаты, стоит заодно проверить, что мониторинг доступности настроен. Если обновление всё-таки положит сайт, узнать об этом лучше от системы мониторинга через минуту, а не от клиента через сутки.
Как понять, что сайт уже скомпрометирован
Взломанный сайт почти никогда не выглядит взломанным для владельца. Главная открывается, формы работают, в админке всё на месте, а проблема видна только со стороны поисковика или посетителя, который пришёл из выдачи.
На что смотреть в первую очередь. В списке пользователей появился администратор, которого вы не заводили. При переходе из поиска сайт перекидывает на чужой ресурс, хотя по прямой ссылке открывается нормально. В Google Search Console висит предупреждение о безопасности или о вредоносном содержимом. В папке загрузок лежат php-файлы, хотя туда должны попадать только картинки и документы. Резко вырос объём исходящей почты с домена, и хостер прислал уведомление о спаме. В списке запланированных задач WordPress появились задания с бессмысленными именами.
Любой из этих признаков означает, что обновлением плагинов дело уже не решится: нужно чистить сайт и менять все пароли, включая доступы к хостингу и базе данных. Восстановление из резервной копии помогает, только если копия сделана до заражения, а не вчера. Это ещё один аргумент хранить несколько поколений бэкапов, а не одну последнюю версию.
Частые вопросы
Мне теперь нужно что-то настраивать в админке?
Нет, настраивать ничего не нужно. Проверка релизов работает на стороне WordPress.org, до того как обновление попадает в API и доезжает до сайта. Единственное, что стоит сделать со своей стороны, это убедиться, что автообновления плагинов включены, и снять свежую резервную копию сайта. Никаких новых настроек, галочек или плагинов система не требует.
Сколько времени проходит между выходом релиза и обновлением на сайте?
До шести часов. Это текущий период охлаждения в рамках инициативы Protect The Shire; на старте, в июне 2026 года, он составлял 24 часа. В это окно укладывается автоматическая проверка кода. Если нужно поставить обновление немедленно, например вышла заплатка к активно эксплуатируемой уязвимости, установите его вручную из раздела «Плагины»: ручная установка паузу не ждёт.
Значит ли это, что WordPress стал безопасным и можно не следить за сайтом?
Нет. Новый механизм защищает только от одного сценария, от заражённого или опасного свежего релиза в каталоге. Он никак не помогает сайту, который не обновляется: исправление уязвимости может месяц лежать в каталоге, но пока владелец не обновит плагин, дыра остаётся открытой. Именно так выглядит ситуация с миллионами сайтов на устаревших версиях популярных расширений.
Что делать, если мой плагин заблокировали, а я уверен, что с ним всё в порядке?
Это вопрос к автору плагина, а не к владельцу сайта. Команда WordPress.org прямо пишет, что высокая оценка риска не означает злого умысла: сработать может неудачная конструкция в коде. Разработчику нужно либо исправить найденные проблемы и выпустить новую версию, либо обратиться в команду плагинов, если он считает срабатывание ошибочным. Письмо о блокировке уходит всем, у кого есть права на плагин.
Проверяются ли платные плагины и темы не из каталога?
Нет. Автоматическая проверка распространяется только на плагины и темы, которые распространяются через каталог WordPress.org. Премиум-расширения, купленные напрямую у вендора, сборки с торрентов и плагины, написанные подрядчиком специально под ваш проект, идут мимо этой системы. За их безопасность отвечает тот, кто их поставил, и для заказных решений это стоит зафиксировать в договоре на обслуживание.
Само по себе решение WordPress.org выглядит запоздалым: фильтр на цепочке поставок стоило ставить раньше, и разработчики говорили об этом годами. Но для казахстанского бизнеса важнее другое. Платформа взяла на себя часть работы, которую раньше приходилось делать вручную или не делать вовсе. Остальное по-прежнему на стороне владельца сайта: резервные копии, актуальные версии, отсутствие пиратских сборок и человек, который за всё это отвечает.