В прошлом месяце мы писали про дыру в WordPress, которая пускала атакующих без пароля. Речь шла о версиях 7.0.0 и 7.0.1. wp2shell. Уязвимость в REST API, не требующая авторизации, и боты, которые автоматически искали недавно обновлённые сайты.
На этот раз дыра другая. WordPress 7.0.4 вышел 12 августа, а вчера мы установили его на все сайты, которые обслуживаем. Не потому, что какой-то из них уже пострадал. Смысл обновления безопасности как раз в том, чтобы успеть до первой чистки.
Если из статьи запомнится только одно, пусть будет это: обновите WordPress сейчас. Ниже разберёмся, почему 7.0.3, 7.0.4 и июльская дыра без пароля — три разные истории.
Два серьёзных обновления безопасности за шесть дней
WordPress 7.0.3 вышел 6 августа. Он исправил CVE-2026-64638 — уязвимость, которую исследователи pwn.ai назвали XSS2Shell. Всё начиналось с отражённого XSS на странице wp-login.php. Для запуска XSS учётная запись не требовалась, но для выполнения PHP-кода на сервере нужно было, чтобы уже авторизованный администратор открыл специально подготовленную ссылку.
Это важное отличие. Перед нами была не ещё одна полностью автоматическая атака, как в июле. Требовался подходящий человек, уже вошедший в админку, и неправильная ссылка. После этого цепочка могла использовать его сессию, создать пароль приложения, установить вредоносный плагин и добраться до выполнения кода на сервере.
Через шесть дней появился WordPress 7.0.4. CVE-2026-65640 — совсем другая уязвимость. Пользователь с ролью автора или выше может загрузить вредоносный PostScript-файл. Если сервер использует Imagick вместе с Ghostscript, обработка файла может привести к удалённому выполнению кода.
Проще говоря, WordPress принимает файл, Imagick занимается обработкой изображения, а для PostScript подключается Ghostscript. Опасность возникает именно в этой связке. При успешной атаке злоумышленник уже не ограничен публикацией записей — он выполняет команды с правами веб-сервера.
Касается ли это вашего сервера?
Если хостинг использует только GD, без связки Imagick и Ghostscript, именно эта атака не сработает. На многих недорогих тарифах виртуального хостинга Imagick вообще не установлен. Но на VPS и более мощных тарифах Imagick вместе с Ghostscript встречаются достаточно часто, поэтому полагаться на догадки не стоит.
Большинство владельцев сайтов не знают, какая библиотека обрабатывает изображения на сервере. И не обязаны знать. В настройках WordPress нет понятного переключателя «Imagick и Ghostscript включены». Можно спросить хостера или проверить конфигурацию PHP, но откладывать обновление до ответа не нужно. Сначала патч. Детали можно выяснить потом.
WordPress также объявил о переносе исправлений в старые ветки вплоть до 4.7. Если сайт всё ещё работает на 6.8 или 6.9, проверьте наличие обновления безопасности именно для своей ветки. Установите его. Не стоит в пятницу вечером без подготовки переходить на WordPress 7.0, если крупное обновление ещё нужно проверить на совместимость.
Почему это не повторение июля
Для июльской уязвимости учётная запись вообще не требовалась. Поэтому атака так быстро разошлась. Мы чистили эстонский магазин косметики на WooCommerce, сайт производственной компании и ещё один эстонский интернет-магазин, где заражение оставалось незамеченным 12 дней. В ту же волну попал сайт латвийской отопительной компании. Во всех случаях входной точкой был wp2shell и уязвимость в WordPress 7.0.0 или 7.0.1.
Исправленная в 7.0.4 дыра требует как минимум учётную запись автора. Это сужает круг атакующих, но не делает проблему безобидной. Авторы загружают иллюстрации. Сотрудники магазина добавляют фотографии товаров. Даже пользователь с формулировкой «только записи, без админки» может иметь право загружать файлы.
Заодно стоит проверить роли. Если человеку нужно лишь готовить черновики, может хватить роли участника. Право загрузки файлов оставьте тем, кому оно действительно нужно. Но аккуратные права доступа не заменяют обновление. Сначала патч, затем ревизия пользователей.
Ни один сайт из нашего списка обслуживания через эту уязвимость не пострадал. Мы не стали ждать первого случая.
Что мы сделали вчера
Установили 7.0.4 на все обслуживаемые сайты. Запустили обновление. Проверили, что сайт вернулся и номер версии изменился. Перешли к следующему. Это скучная сторона обслуживания WordPress, и она мне нравится гораздо больше, чем выставлять счёт за чистку.
Если сайт странно ведёт себя ещё с июля и его никто нормально не чистил, обновление ядра остаётся лишь первым шагом. Вредоносному файлу в wp-content/uploads всё равно, что в админке теперь написано 7.0.4. Здесь уже нужна полноценная очистка взломанного сайта: проверка файлов, пользователей, базы данных, бэкдоров и исходной точки входа.
Начинать нужно с тех же действий, которые описаны в статье что делать сразу после подозрения на компрометацию. Не удаляйте случайные файлы наугад. Сначала снимок, затем карта заражения и только потом чистка.
Неожиданный PostScript-файл в медиатеке — как раз то изменение, которое может обнаружить мониторинг целостности файлов, если нужная папка входит в область проверки. Он не отменит атаку, но покажет, что на сайте появился файл, которого там быть не должно.
Важное уточнение про XSS2Shell и 2FA
Двухфакторная аутентификация всё равно нужна. Она защищает учётную запись, если пароль украли, и останавливает множество обычных попыток захвата аккаунта. В нашем руководстве по двухфакторной аутентификации есть практическая настройка.
Но 2FA не исправляет XSS2Shell и не спасает сессию, в которой администратор уже авторизован. Атака на 7.0.3 как раз опиралась на такую активную сессию. Решение здесь — обновление WordPress. Ни одна настройка плагина его не заменяет.
Сделайте сегодня три вещи
- Откройте Консоль → Обновления и установите WordPress 7.0.4 или обновление безопасности для своей ветки.
- После установки проверьте номер версии. Не считайте, что автоматическое обновление обязательно завершилось успешно.
- Просмотрите пользователей с правом загрузки файлов. Если оно им не нужно, понизьте роль.
Автоматические обновления вовремя спасают множество сайтов, но иногда не срабатывают из-за прав на запись, зависшего режима обслуживания или ограничений хостинга. Проверьте версию сами. Если там нет 7.0.4 или исправленного выпуска для вашей ветки, работа ещё не закончена.
В июле была дыра без пароля. 6 августа исправили XSS на странице входа. 12 августа закрыли путь через PostScript-файл и учётную запись автора на серверах с Imagick и Ghostscript. Вчера мы обновили все сайты на обслуживании. Проверьте свой сегодня.