28 октября 2026 года вышел WordPress 7.1.4. Это обновление безопасности, и WordPress.org советует установить его сразу. Если у вас включены автоматические фоновые обновления, движок мог уже обновиться сам. Мог. Вот это я бы и проверил первым делом, прежде чем что-либо менять на сайте.
Обновление, 30 окт.: атакующие уже начали пробовать уязвимость с папкой upgrade. Подробности в новом разделе ниже.
Есть еще одна вещь на стороне сервера: могут ли посетители открыть через браузер папку wp-content/upgrade/. Одно из исправлений касается именно того, что происходит там во время обновления. Техническую часть разберем без долгого погружения, а потом - что сегодня сделать владельцу небольшого сайта.
Что исправили в этом выпуске
По подсчетам Patchstack, в 7.1.4 закрыли 22 уязвимости, описанные в 17 уведомлениях. Для одного выпуска много: версия 7.1.3, вышедшая тремя неделями раньше, исправляла семь. Но это не значит, что 22 случайных прохожих могут вот так запросто взломать ваш сайт.
Для всех проблем, кроме двух, атакующему сначала нужен аккаунт с правами Contributor или выше. Проще говоря, человек с доступом к написанию записей мог спрятать в контенте скрипт. Тот сработал бы, когда страницу откроет администратор или посетитель. Семь уведомлений касаются сохраненных XSS-уязвимостей в Interactivity API: некоторые атрибуты data-* проходили через фильтр содержимого. Остальные исправления затрагивают разметку блоков, Customizer, блоки пагинации комментариев, загрузку файлов с правами Author и разрешения для Notes у пользовательских ролей.
- Ошибки, связанные с публикациями, - повод проверить, у кого остался аккаунт. Прекращать публиковать записи не надо.
- Одна менее серьезная проблема давала анонимным посетителям возможность находить неопубликованные наборы изменений Customizer. Теперь для доступа нужны права customize.
- В выпуске также обновили корневые сертификаты после отзыва сертификата eMudhra.
Ни Patchstack, ни WordPress.org не сообщают об атаках с использованием этих уязвимостей в реальных условиях. Это не доказательство, что никто не пытался. Я бы такой вывод не делал.
Почему папке upgrade уделяют столько внимания
На уровне сервера я бы занялся проблемой в процессе обновления ядра WordPress, о которой сообщил Умут Байрам. Это состояние гонки, и аккаунт для атаки не нужен. Когда WordPress устанавливает или обновляет что-то, он распаковывает пакет в wp-content/upgrade/. Веб-сервер может отдавать эту папку посетителям, как и другие папки сайта.
До 7.1.4 имя временной папки можно было угадать по названию пакета. При очистке мог удалиться и файл index.php, который мешает просматривать список файлов в папке. В итоге на несколько секунд во время обновления по предсказуемому адресу могла лежать доступная через браузер полная копия WordPress, включая wp-admin/setup-config.php. Она запускалась без обычной конфигурации сайта. Если попасть в нужный момент, можно было запустить установщик внутри папки вашего сайта, указав базу данных под своим контролем.
Окно короткое. Patchstack оценивает атаку как сложную и не считает ее практически удобной. Но окно возвращается снова при каждом обновлении, в том числе автоматическом, а слабое место тянется еще со времен WordPress 2.8. Ни логин, ни действия владельца сайта атакующему не нужны. Поэтому отмахиваться от проблемы я бы не стал.
Обновление, 30 октября: атаки начались
Через день после выхода версии Wordfence сообщил, что уязвимость с окном обновления уже пытаются использовать. Первое срабатывание их нового правила файрвола случилось через девять минут после его запуска. За первые 21 час они насчитали больше 18 500 запросов к временным путям установщика setup-config.php.
Картина типичная для состояния гонки: некоторые источники около 14,5 часа подряд опрашивали небольшие группы сайтов, надеясь попасть в те несколько секунд, пока идет обновление. Другие перебирали варианты имен папок и версий. Не все запросы шли точно по уязвимому пути, и ни один источник, который мы читали, пока не сообщает о подтвержденных взломах.
Советы те же, просто срочнее:
- Проверьте в
Dashboard > Updates, что сайт действительно работает на 7.1.4 (или на исправленной версии своей ветки). - Закройте доступ из браузера к
wp-content/upgrade/, как показано ниже. - Если сайт оставался без обновления, поищите в логах запросы к PHP-файлам в
wp-content/upgrade, новых администраторов, незнакомые плагины или PHP-файлы, которые вы туда не клали.
Если у вас Wordfence: атака обращается к PHP-файлу напрямую, без загрузки WordPress, поэтому, по словам Wordfence, для защиты нужен режим файрвола Extended Protection. Правило файрвола не заменяет обновление.
Что поменял WordPress
В версии 7.1.4 к имени временной папки добавили 16 случайных символов. WordPress также заново создает index.php и больше не удаляет его, а еще не дает скопировать wp-config.php из рабочей папки. Все это исправления в самом движке.
Согласно списку выпусков Patchstack, патчи получили и старые ветки вплоть до 4.7, в том числе 7.0.8 и 4.7.39. В публикации WordPress.org говорилось, что перенос исправлений на старые ветки еще идет и версии будут выходить по готовности. Так что лучше посмотреть последнее доступное обновление именно для вашей ветки, а не гадать по номеру. Для 4.6 и более старых версий патча нет. И да, активно поддерживают только самую новую версию WordPress. Наличие патча - не повод оставаться на старой ветке навсегда. Выход WordPress 7.2 запланирован на 8 декабря.
Что сделать сегодня
- Убедитесь, что обновление установилось. Не считайте автоматическое обновление успешным, пока не проверили. Откройте
Dashboard > Updatesи найдите сообщение «You have the latest version of WordPress». Номер версии также виден внизу админки или вTools > Site Health > Info > WordPress. Если в команде кто-то пользуется WP-CLI, командаwp core versionбыстро даст ответ. На старой ветке ищите ее последний патч безопасности - например, 7.0.8 для ветки 7.0. Ждать там номер 7.1.4 не нужно. Сама проверка займет пару минут; заодно откройте главную и страницу оформления заказа, если у вас магазин. - Закройте доступ к папке upgrade через браузер. Защита работает и во время обновления. PHP-файрвол или плагин безопасности здесь ненадежны: распакованная копия загружает собственные файлы WordPress, поэтому файрвол основного сайта для такого запроса не запустится. На Apache добавьте правило в главный
.htaccessв корне сайта, выше блока WordPress. Не кладите его внутрьwp-content/upgrade/- движок очищает эту папку.RedirectMatch 403 ^/wp-content/upgrade/Для Nginx правило добавляют в конфигурацию сервера, внутрь блока server:
location ^~ /wp-content/upgrade/ { deny all; }Затем откройте в браузере
https://yoursite/wp-content/upgrade/. Нужен ответ 403 Forbidden, а не список файлов. Между обновлениями в папке должен оставаться толькоindex.php. Самим обновлениям запрет не мешает: WordPress пишет туда через PHP, не через браузер посетителя. На управляемом хостинге нет доступа к конфигурации? Попросите поддержку закрыть путь и подтвердить результат. На нашем хостинге WordPress настройкой сервера занимаемся мы. Проверка занимает минуты; если править конфигурацию самому, сначала сохраните ее копию. - Проверьте, кто может писать на сайте. Зайдите в
Users > All Usersи отфильтруйте Contributor, Author, Editor, а также роли магазина вроде Shop manager. Удалите аккаунты бывших сотрудников, старых подрядчиков и агентств, чьи услуги вам больше не нужны. Если человек еще работает с сайтом, но уже не публикует материалы, снизьте ему права. Чем меньше таких аккаунтов, тем меньше возможностей использовать ошибки, связанные с контентом. Ушло минут десять? Для небольшого магазина это нормальная цена проверки. Если приглашаете нового специалиста, пригодится инструкция, как дать разработчику доступ к WordPress и сохранить контроль. - Назначьте ответственного за обновления. Автоматика выручает, но кто-то должен заметить сбой и проверить сайт после апдейта. Не обязательно выделять на это полдня: поставьте короткую еженедельную проверку в календарь. Если хотите передать задачу нам, она входит в обслуживание WordPress. И пока разбираетесь с доступами, загляните в старые подключения: вот как проверить пароли приложений и ключи доступа. Удаление аккаунта бывшего автора само по себе не говорит вам, какие еще способы входа остались.
Начните с того, что легко проверить
Я бы сперва открыл Dashboard > Updates, а потом проверил адрес папки upgrade. Оба шага дают понятный результат уже сегодня. Если вместо 403 папка открывается, напишите тому, кто управляет сервером. До его ответа вычеркивать этот пункт рано.