Неудачный апдейт. Переезд на другой хостинг, после которого сайт не открывается. Обычно именно в такой момент вы тянетесь за бэкапом - когда уже нервничаете и хотите поскорее все вернуть.
На этой неделе два плагина для резервных копий WordPress закрыли ошибки, из-за которых само восстановление могло запустить чужой SQL-код. Он мог давно лежать в бэкапе и ничем себя не выдавать. А потом вы восстанавливаете сайт - и начинаются проблемы. Если пользуетесь UpdraftPlus или Backuply, обновите плагин до следующего восстановления. Не посреди аврала.
Обновление UpdraftPlus: две связанные ошибки
14 октября 2026 года вышел UpdraftPlus 1.26.9. Он закрыл неприятную дыру: если атакующий без прав администратора мог записать свой текст в ячейку базы данных размером больше 1MB, а владелец позже сделал бэкап и восстановил сайт, при восстановлении мог выполниться SQL-код атакующего. Об ошибке разработчикам сообщила Wordfence.
Условий тут немало. Простое открытие страницы не запускает атаку. И это не значит, что каждый бэкап заражен.
Но уже 15 октября 2026 года вышла версия 1.26.10. Jakub Herman нашел второй, похожий случай. Он срабатывал только тогда, когда базу восстанавливали на сервере с другой конфигурацией - не той, что была у сервера при создании бэкапа. Переезд на новый хостинг подходит под такой сценарий. Разработчики советуют обновиться всем. И правильно: когда магазин лежит, меньше всего хочется разбираться в настройках двух серверов баз данных.
Обновление от 18 октября: 16 октября 2026 года вышел UpdraftPlus 1.26.11. Он закрывает пробел в исправлении из 1.26.9, который проявляется только если сервер базы данных работает в редком режиме SQL NO_BACKSLASH_ESCAPES. У вас его почти наверняка нет, но всё равно ставьте 1.26.11 или новее.
Если у вас платная редакция UpdraftPlus, ищите соответствующий выпуск ветки 2.x, а не номер версии бесплатного плагина.
Backuply: текст в профиле превращается в доступ администратора
У Backuply путь к неприятностям другой. Уязвимы версии до 1.5.8 включительно; в 1.5.9, выпущенной 1 октября 2026 года, ошибку исправили. Ее номер - CVE-2026-93953, оценка - 8,0 (высокая). Wordfence опубликовала подробности 15 октября 2026 года и указала исследователя daroo.
На пальцах это работает так. Пользователь, который вошел на сайт и имеет всего лишь роль Subscriber, добавляет специальный текст в поле Biographical Info своего профиля. WordPress хранит его в wp_usermeta, а Backuply переносит в SQL-дамп бэкапа. Позже администратор восстанавливает эту копию. Текст вырывается за пределы своего поля и запускает SQL с полными правами на базу данных.
Wordfence показала вполне конкретный результат: включить открытую регистрацию, назначить новым пользователям роль Administrator, а затем зарегистрировать аккаунт. Им управляет атакующий. Настройки сохраняются после восстановления, потому что параметры сайта восстанавливаются раньше метаданных пользователей. Никому не надо нажимать на подозрительную ссылку. Достаточно самого восстановления.
Паниковать?
Сообщений о массовых атаках нет. И регистрация постороннего человека сама по себе эту ошибку не запускает: владелец должен восстановить бэкап, в который уже попали подготовленные данные.
Вот только из-за такой задержки проблему легко пропустить. В интернет-магазинах с личными кабинетами, на форумах и сайтах с открытой регистрацией или комментариями у посторонних больше шансов оставить свои данные в будущей копии. А переезд на другой хостинг может добавить условие, нужное для второй ошибки UpdraftPlus.
Похожую схему мы уже разбирали в статье про атаку через восстановление бэкапа All-in-One WP Migration. Самое неприятное тут - ожидание: человек подкладывает данные сейчас, а потом ждет, когда вам понадобится бэкап.
Что сделать до следующего восстановления
Откройте страницу плагинов WordPress сегодня. Не оставляйте проверку до того дня, когда сайт перестанет работать.
- Сначала проверьте версии. До восстановления обновите UpdraftPlus до 1.26.11 или новее, либо Backuply до 1.5.9. Для платной редакции UpdraftPlus проверьте соответствующий выпуск 2.x.
- Пока не можете обновить - отложите восстановление. Старый бэкап не становится безопасным только потому, что вы сделали его сами. Лучше сначала получить помощь с обновлением, а уже потом импортировать копию.
- Вспомните, что попало в бэкап. Если на сайте появились подозрительные аккаунты, копия, сделанная до их регистрации, может быть лучшей отправной точкой. Но гарантий нет - посторонние могли оставить данные и другим способом.
- Если есть возможность, используйте тестовый сайт. Сначала обновите плагин, потом восстановите копию отдельно от рабочего сайта. Проверьте пользователей и настройки, прежде чем переносить результат на боевой сайт.
По данным Wordfence, пользователи ее файрвола на тарифах Premium, Care и Response получили правило для Backuply 24 сентября 2026 года; бесплатным пользователям оно станет доступно 24 октября 2026 года. Защита полезная, но правило файрвола не заменяет обновление плагина.
Обновление поможет, если сайт уже пострадал?
Нет. Оно защищает будущие восстановления, но не отменяет изменения, которые уже успела внести уязвимая версия. Если вы восстанавливали бэкап Backuply, пока стояла затронутая версия, проверьте сайт сейчас. То, что главная страница открывается, ничего не говорит о настройках регистрации.
В WordPress зайдите в Settings > General. Проверьте Anyone can register (параметр users_can_register) и New User Default Role (параметр default_role). Регистрация должна быть выключена, если она вам не нужна. Роль по умолчанию - Subscriber либо Customer для магазина с аккаунтами покупателей. Administrator для открытой регистрации - точно не норма.
Затем откройте список Users и отфильтруйте его по роли Administrator. Всех узнаете? Посмотрите и недавно зарегистрированные аккаунты, а в описаниях профилей - странный текст, похожий на SQL. Расшифровывать его самому не нужно. Неожиданная настройка или чужой администратор - уже повод остановиться и разбираться.
Если нашли что-то подозрительное, считайте сайт взломанным. Смените пароли, проверьте аккаунты и изменения в базе. Если нужна помощь, закажите очистку взломанного WordPress-сайта. Просто выключить регистрацию обратно недостаточно: у атакующего уже может быть аккаунт администратора.
После восстановления - три минуты на проверку
Даже после обновления заведите привычку проверять сайт после каждого восстановления: откройте Anyone can register, посмотрите New User Default Role, пробегитесь по списку администраторов. Сделайте это до того, как сообщите всем, что сайт снова работает. Три минуты могут избавить от очень неприятного сюрприза.
И не ограничивайтесь проверкой главной страницы. Файл с копией - лишь часть работы; бэкап еще не план восстановления. В плане стоит указать, кто обновляет плагины, где вы проверяете восстановление и какие настройки смотрите после него.
Добавьте обновление в дела на сегодня
Такую задачу лучше закрывать заранее, а не когда сайт уже сломан. Если за сайтом следит специалист, проверьте, входит ли контроль версий в обслуживание WordPress-сайта. Если занимаетесь им сами - откройте список плагинов сейчас и посмотрите установленную версию. Во время срочного восстановления узнавать о пропущенном апдейте будет поздновато.