28 октября WordPress выпустил версию 7.1.4 и закрыл в ней 22 уязвимости. Одна из них устроена необычно: она существует только в те несколько секунд, пока сайт обновляется. Во время установки обновления WordPress распаковывает пакет во временную папку wp-content/upgrade, и при некоторых настройках веб-сервера распакованный установщик оттуда доступен из интернета. Входить в систему атакующему не нужно.
То есть уязвим сам момент починки. Совет «обновляйтесь немедленно», который мы повторяем из статьи в статью, здесь приводит к открытию окна — пусть и на секунды. Отказаться тоже нельзя: не обновляться хуже.
Исправления выпущены для всех поддерживаемых веток, вплоть до 4.7.39 — это линия 2016 года. Сайты на 4.6 и старше не получат ничего: для них выхода нет, кроме переезда на поддерживаемую ветку.
Насколько это страшно на самом деле
Здесь нужна холодная вода, и её много.
Окно атаки измеряется секундами и открывается только в момент обновления. В оценке уязвимости прямо стоит признак высокой сложности атаки. Дейв Йонг из Patchstack, разбиравший выпуск, пишет, что не назвал бы эту уязвимость практически эксплуатируемой.
Подтверждённых взломов нет ни одного. Есть попытки — и вот с их количеством любопытная история.
| Источник | Сколько попыток | За какой срок |
|---|---|---|
| Wordfence, первая публикация | более 18 500 | 21 час |
| Более поздние сводки | 58 000 — 60 471 | 24 часа |
Цифры расходятся втрое, и приводятся они со ссылкой на одну и ту же компанию. Скорее всего дело в разных окнах наблюдения и разных наборах правил, но проверить это со стороны нельзя. Мы приводим обе и не выбираем ту, что звучит страшнее.
И главное, что теряется в заголовках: попытка — не взлом. Десятки тысяч запросов означают, что по интернету ходит автоматика и дёргает все сайты подряд. Это говорит о готовности инфраструктуры атаки, а не о её результатах.
Но и успокаиваться на слове «неэксплуатируемая» не стоит, и вот почему. «Окно в несколько секунд» звучит как «надо попасть в игольное ушко» — если представлять себе человека, который сидит и ждёт. Автоматика не ждёт: она опрашивает сотни тысяч сайтов по кругу, круглосуточно, и ей достаточно оказаться на нужном сайте в нужную секунду один раз из миллиона попыток. А автоматические обновления ядра включены у огромного числа сайтов и происходят не в случайный момент, а вскоре после выхода релиза. То есть секунды уязвимости у множества сайтов приходятся примерно на одно и то же время. Насколько это меняет расклад на практике, публично никто не считал, и мы тоже не будем — но держать в уме стоит.
Почему эта папка вообще видна из интернета
Вопрос, который стоит задать: а почему распакованный установщик в принципе доступен снаружи? Ответ лежит в устройстве платформы, и он интереснее самой уязвимости.
WordPress живёт в корне сайта целиком. Всё, что в нём есть, — ядро, админка, темы, плагины, загрузки, — лежит внутри того каталога, который веб-сервер отдаёт в интернет. Отдельной папки для публичных файлов там нет, потому что wp-content обязана быть доступной браузеру: оттуда грузятся стили, скрипты и картинки. А раз доступна сама папка, то доступно и всё, что внутрь неё временно попадает, — включая распакованный установщик.
Для сравнения: в приложениях, собранных по другой схеме, наружу отдаётся только подкаталог вроде public, а код, настройки и служебные каталоги лежат уровнем выше — и недостижимы по вебу в принципе, при любой ошибке в настройках. Там подобная уязвимость не могла бы возникнуть: распаковывать установщик было бы просто некуда, чтобы он оказался снаружи.
Это не упрёк WordPress: платформа сделана так двадцать лет назад, когда хостинг был один каталог и FTP, и переделать это сейчас невозможно — сломаются миллионы сайтов. Но это хороший пример того, что архитектурные решения не устаревают сами. Они просто продолжают работать, и однажды из них вырастает уязвимость, которую приходится закрывать двадцатью с лишним выпусками сразу.
Девять минут, и что они значат
По сетям разошлась цифра: первая атака через девять минут. Формулировка важнее цифры, поэтому приведём её точно.
Wordfence развернул правило для этой уязвимости 28 октября в 20:30 UTC. Первый запрос, который под это правило попал, зафиксирован девятью минутами позже.
Это не скорость реакции атакующих на выход заплатки. Это другое: к моменту, когда защитники включили обнаружение, перебор уже шёл — и попал в сеть за девять минут. Про то, сколько прошло от публикации исправления до первой попытки, данных нет.
Мы измеряли похожее у Atlassian: два часа между публикацией разбора и первой волной атак. Так вот, девять минут — не продолжение того же ряда, и складывать эти числа в один график нельзя: они про разные вещи. Общее у них одно — к моменту, когда об уязвимости узнаёт владелец сайта, её уже ищут.
Главное: защита оказалась товаром
А теперь то, из-за чего мы вообще взялись за эту новость.
Правило, закрывающее эту уязвимость на уровне межсетевого экрана, Wordfence выпустил 28 октября — примерно через три часа после выхода WordPress 7.1.4. Получили его платные подписчики.
Бесплатные пользователи того же самого продукта получат то же самое правило 27 ноября. Это не сбой и не задержка: это штатное правило компании — тридцать дней отсрочки для бесплатного тарифа.
Претензий к Wordfence у нас нет. Компания имеет полное право зарабатывать, бесплатный тариф никому ничего не обещал, а условия опубликованы. Дело не в ней.
Дело в том, что владелец сайта, у которого «стоит защита», месяц живёт без защиты именно от той уязвимости, о которой сейчас пишут все, — и, скорее всего, не знает об этом. Он поставил плагин, увидел зелёную галочку и считает вопрос закрытым. А расписание его безопасности определяется прайс-листом чужой компании.
Это и есть зависимость в чистом виде, без метафор. Не «сервис может упасть» и не «вендор может задержаться», а: сроки вашей защищённости — чужое коммерческое решение, принятое без вас и не в ваших интересах. Причём совершенно законное.
Вывод из этого не «Wordfence плохой» и даже не «надо платить». Вывод прозаичнее: защита на уровне межсетевого экрана — это заплатка поверх заплатки, и полагаться на неё вместо обновления нельзя. Обновление закрывает дыру. Правило лишь мешает её нащупать, и то по расписанию, которое составляете не вы.
Что делать
- Обновиться. Нужна 7.1.4 или соответствующий выпуск вашей ветки: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 и так далее вплоть до 4.7.39.
- Если ветка 4.6 или старше — исправления не будет. Здесь нужно не обновление, а переезд, и это работа другого масштаба, которую стоит начинать сейчас, а не когда припечёт.
- Закрыть доступ снаружи к
wp-content/upgrade. Эта папка нужна только самому WordPress и только на время установки; отдавать её наружу не нужно никогда. На nginx это одна строка:location ^~ /wp-content/upgrade/ { deny all; } - Проверить, что обновление действительно применилось — в админке, а не по памяти. Автообновление ядра включено не везде и иногда молча не срабатывает.
- Посмотреть список администраторов и журналы веб-сервера за последнюю неделю, и поискать в каталогах сайта PHP-файлы, которых вы туда не клали.
- Не считать плагин безопасности заменой обновлению. Он закрывает известные приёмы и делает это тогда, когда решит его разработчик.
Коротко
- 28 октября WordPress 7.1.4 закрыл 22 уязвимости. Одна из них существует только в те секунды, пока сайт обновляется, и не требует входа в систему.
- Исправления выпущены для веток вплоть до 4.7.39. Для 4.6 и старше их не будет.
- Подтверждённых взломов нет. Разбиравший выпуск специалист Patchstack называет уязвимость практически неэксплуатируемой.
- Попыток — от 18 500 за 21 час до 60 471 за сутки по разным публикациям, со ссылкой на один и тот же источник. Попытка не равна взлому.
- «Девять минут» — это срок от включения правила защиты до первого пойманного запроса, а не от выхода заплатки до первой атаки.
- Правило для платных подписчиков вышло 28 октября, для бесплатных выйдет 27 ноября. Тридцать дней — штатная отсрочка бесплатного тарифа.
- Закройте
wp-content/upgradeснаружи. Это полезно независимо от этой истории.
Источники
- Разбор выпуска 7.1.4, перечень исправленных веток и оценка практической эксплуатируемости — публикация Patchstack от 28 октября 2026 года.
- Число попыток за 21 час и точное время развёртывания правила — SecurityOnline от 30 октября 2026 года, со ссылкой на данные Wordfence.
- Сроки получения правила платными и бесплатными пользователями и число заблокированных попыток за сутки — Cybersecurity News от 30 октября 2026 года.
- Про скорость появления атак после выхода заплатки — наша статья от 15 октября. Про WordPress как платформу — разбор от 18 сентября.
- Про то, чем платят на каждой ступени самостоятельности, — шкала зависимости.