Уязвимость CVE-2026-119977 в ядре WordPress уже используют в реальных атаках, поэтому одного обновления до 7.1.4 мало: нужно еще проверить, не успели ли сайтом воспользоваться до патча. Проверка сводится к трем действиям: найти в журналах доступа запросы к папке wp-content/upgrade, сверить файлы ядра с эталоном и осмотреть список администраторов.
3 ноября 2026 года американское агентство CISA внесло уязвимость в каталог активно эксплуатируемых уязвимостей (KEV) и дало федеральным ведомствам срок на исправление до 6 ноября. В тот же день Канадский центр кибербезопасности выпустил бюллетень AV26-1117 с призывом обновить WordPress. Сама исправленная версия вышла раньше, 28 октября: что в нее вошло и как обновиться, мы подробно писали в статье о выпуске WordPress 7.1.4. Эта статья для тех, кто уже обновился или собирается, и хочет понять, не успели ли до патча воспользоваться его сайтом.
Что известно об атаках на CVE-2026-119977
Атаки начались почти сразу после публикации исправления и идут массово, но об успешных взломах исследователи пока не сообщали. Уязвимость относится к классу «время проверки и время использования» (TOCTOU): это ошибка, при которой программа проверяет условие в один момент, а действует в другой, и злоумышленник успевает вмешаться в промежутке.
По описанию CISA, при полном обновлении ядра WordPress распаковывает новые файлы во временную папку с предсказуемым адресом, и эта папка доступна из интернета. Пока идет распаковка, неавторизованный злоумышленник может обратиться к установочным файлам из этой папки и выполнить код на сервере. Учетная запись на сайте ему не нужна, зато нужно попасть в короткое окно, пока обновление не завершилось.
По данным команды Wordfence, которые приводит SecurityWeek, первое срабатывание нового правила их файрвола пришло через девять минут после его выпуска. За первые 21 час было зафиксировано больше 18 500 запросов к установочным файлам setup-config.php во временных папках обновления. Боты перебирают сайты подряд и ждут, когда какой-нибудь из них начнет обновляться.
Затронуты версии WordPress с 4.7 по 7.1.3. В официальном анонсе WordPress 7.1.4 сказано, что исправление переносится во все ветки, которые еще получают обновления безопасности, то есть до 4.7 включительно, и что эти выпуски выходят по мере готовности. Версии 4.6 и старше исправлений не получат. В исправленной версии временная папка получает случайное имя, в нее добавлена защита от прямого обращения, а установочные данные больше не переносятся из нее небезопасным способом.
Кому проверять сайт, а кому хватит обновления
Проверять журналы стоит всем, чей сайт обновлял ядро WordPress в период с конца октября до установки 7.1.4, потому что именно во время обновления открывается окно для атаки. Если ядро в эти дни не обновлялось совсем, риск ниже, но обновиться все равно нужно: первое же обновление уязвимой версии откроет то же окно.
| Ситуация с сайтом | Что сделать | Срочность |
|---|---|---|
| Сайт уже на 7.1.4 или на исправленном выпуске своей ветки, ядро до этого не обновлялось с конца октября | Сверить файлы ядра, просмотреть администраторов | В течение недели |
| Ядро обновлялось автоматически или вручную с 28 октября по день установки патча | Полная проверка журналов, файлов и пользователей | Сегодня |
| Сайт все еще на версии от 4.7 до 7.1.3 | Закрыть доступ к папке обновлений, затем обновиться и проверить | Сегодня |
| Сайт на версии 4.6 или старше | Планировать перенос на актуальную версию, временно закрыть папку обновлений | Как можно скорее |
Отдельный случай: сайты, где автообновления ядра включены и никто за ними не следит. Такой сайт мог обновиться сам в любой из дней после 28 октября, и владелец об этом не знает. Дату последнего обновления ядра можно увидеть по времени изменения файлов в корне сайта, например wp-includes/version.php, в файловом менеджере хостинга.
Как найти следы атаки в журналах доступа
Главный признак попытки атаки: запросы к PHP-файлам внутри папки wp-content/upgrade в журнале доступа веб-сервера. Обычный посетитель туда никогда не обращается, поэтому любой такой запрос заслуживает внимания. Журнал доступа (access log) — это файл, куда веб-сервер записывает каждое обращение к сайту: адрес, время, IP и код ответа.
- Откройте панель хостинга и найдите раздел с журналами сайта. В разных панелях он называется по-разному: «Журналы», «Логи», «Статистика». Нужен именно журнал доступа, а не журнал ошибок.
- Скачайте журналы за период с 28 октября по сегодняшний день. Часть хостингов хранит старые журналы в архивах .gz, их тоже нужно взять.
- Найдите в журналах строки, где встречается wp-content/upgrade. Если у вас есть доступ к серверу по SSH, это делается одной командой:
zgrep -h "wp-content/upgrade" access.log*. Без SSH подойдет поиск по тексту в любом редакторе. - Из найденных строк выделите те, где адрес заканчивается на .php, особенно setup-config.php.
- Посмотрите код ответа сервера в каждой такой строке. Ответы 404 и 403 означают, что файла не было или доступ был закрыт. Ответ 200 на запрос к PHP-файлу в этой папке — повод для полной проверки.
- Сопоставьте время запросов с ответом 200 и время обновления ядра. Если они совпадают, считайте сайт потенциально скомпрометированным и переходите к разделу о действиях после взлома.
Сотни запросов с ответом 404 сами по себе не страшны: это работа сканеров, которые перебирают все сайты подряд. Опасен именно успешный ответ в момент, когда временная папка существовала.
Что еще считать тревожным сигналом
Кроме журналов, о взломе обычно говорят изменения внутри самого сайта, которые никто из команды не делал. Проверьте следующее:
- в разделе «Пользователи» появился администратор, которого никто не создавал, или у существующего пользователя повысилась роль;
- в списке плагинов есть незнакомый плагин, иногда с названием, похожим на системное;
- в папках wp-content/uploads или wp-content/upgrade лежат PHP-файлы (в uploads их в норме быть не должно вообще);
- изменился файл wp-config.php, а дата изменения совпадает с днем обновления;
- сайт стал перенаправлять часть посетителей на сторонние ресурсы, особенно с мобильных устройств или из поиска;
- хостинг прислал предупреждение о рассылке спама или повышенной нагрузке.
Ни один признак не доказывает взлом сам по себе. Но если совпали два-три пункта, проверка становится обязательной.
Как проверить, что файлы ядра не изменены
Проще всего сверить файлы ядра с эталонными контрольными суммами WordPress командой WP-CLI. Если на хостинге есть WP-CLI и SSH, достаточно выполнить в папке сайта wp core verify-checksums. Команда сравнивает файлы ядра с эталоном для установленной версии и выводит список файлов, которые не совпали или не должны там находиться. Описание есть в документации WP-CLI о проверке контрольных сумм ядра.
Аналогичную проверку для плагинов из официального каталога делает команда wp plugin verify-checksums --all. Платные плагины и темы, которых нет в каталоге wordpress.org, так проверить нельзя: их файлы сравнивают с чистым архивом от разработчика.
Если WP-CLI нет, можно скачать архив своей версии с wordpress.org и сравнить папки wp-admin и wp-includes с теми, что лежат на сервере. Это дольше, но тоже работает. Файлы в wp-content (темы, плагины, загрузки) эталона в архиве ядра не имеют, их смотрят отдельно.
Помните, что проверка контрольных сумм ловит изменения в ядре, но не видит вредоносный код, который положили в новую папку или в базу данных. Поэтому сверку файлов делают вместе с просмотром журналов и пользователей.
Как обновлять сайт, пока атаки продолжаются
Сайт на уязвимой версии открывает окно для атаки в момент обновления, поэтому перед обновлением имеет смысл закрыть веб-доступ к папке wp-content/upgrade. Для самого обновления доступ к этой папке через браузер не нужен: WordPress пишет туда файлы напрямую на диске.
Для сервера на nginx правило в конфигурации сайта выглядит так:
location ^~ /wp-content/upgrade/ { deny all; return 403; }
Для Apache можно положить в папку wp-content/upgrade файл .htaccess со строкой Require all denied. Если папки нет, ее создают вручную. Это временная мера на сам момент обновления. Исправленная версия ядра уже защищает временную папку сама, но правило можно оставить: на наших проектах оно обновлениям не мешало. Если после его установки обновление завершается ошибкой, правило снимают и разбираются с причиной.
Порядок обновления сайта, который сейчас еще на уязвимой версии:
- Сделайте полную резервную копию файлов и базы данных и проверьте, что архив открывается.
- Закройте веб-доступ к wp-content/upgrade правилом выше и проверьте в браузере, что адрес вида ваш-сайт/wp-content/upgrade/ отдает 403.
- Обновите ядро до 7.1.4 или до исправленного выпуска своей ветки. Если у вас есть тестовая копия, сначала обновите ее: как ее подготовить, описано в материале о тестовой копии сайта на WordPress.
- Сразу после обновления выполните сверку файлов ядра и просмотрите журналы за время обновления.
- Убедитесь, что формы заявок, корзина и оплата работают: на коммерческом сайте это важнее любых других проверок после обновления.
Что делать, если следы взлома нашлись
Если журналы показали успешные обращения к установочным файлам или нашлись чужие администраторы и файлы, сайт нужно считать взломанным и чистить по порядку. Удалять подозрительные файлы по одному бесполезно: злоумышленник часто оставляет второй, запасной вход.
- Сохраните текущее состояние сайта и журналы отдельно от рабочих копий. Они понадобятся, чтобы понять, что именно сделал злоумышленник.
- Смените пароли всех администраторов, пароль к базе данных, доступ к хостингу и FTP.
- Замените секретные ключи и соли в wp-config.php: это разлогинит все активные сессии, включая чужие. Новые значения выдает официальный генератор WordPress.
- Удалите неизвестных пользователей и проверьте роли оставшихся.
- Переустановите ядро из чистого архива той же версии, а плагины и темы скачайте заново из официальных источников.
- Найдите и удалите PHP-файлы в uploads и upgrade, проверьте задания планировщика и базу данных на посторонние вставки кода.
- После чистки еще раз выполните сверку контрольных сумм и неделю внимательно смотрите журналы.
Если на сайте хранились персональные данные клиентов, например заявки с телефонами или личные кабинеты, отдельно обсудите с юристом обязанности компании по закону Республики Казахстан о персональных данных. Решение о том, куда и как сообщать, лучше принимать по фактам из журналов.
Сколько времени занимает проверка и кому ее поручить
Проверка небольшого корпоративного сайта без следов взлома занимает от часа до нескольких часов, чистка взломанного сайта обычно растягивается на день и больше. Самая долгая часть — получить журналы: на части хостингов их хранят всего несколько дней, и тогда картину приходится восстанавливать по косвенным признакам.
По опыту поддержки сайтов в B2BPRO.KZ мы чаще всего видим одну и ту же картину: сайт сделали несколько лет назад, подрядчик ушел, автообновления включены, а журналы и резервные копии никто не смотрел. В такой ситуации владелец узнает о проблеме последним, обычно от клиента, который не смог отправить заявку. Если у вашего сайта нет человека, который отвечает за обновления и безопасность, эту работу можно передать нам: разработка и сопровождение сайтов на WordPress включают обновления, резервные копии и проверку после инцидентов.
Если вы решили проверять сами, держите под рукой три вещи: доступ к панели хостинга, свежую резервную копию и контакт технической поддержки хостинга. Поддержка хостинга часто может выгрузить журналы, которые не видны в панели.
Типичные ошибки при проверке
Большинство ошибок связано с тем, что проверку останавливают на первом успокаивающем результате. Вот что мы встречаем чаще всего:
- Обновили до 7.1.4 и решили, что вопрос закрыт. Обновление закрывает дыру, но не удаляет то, что могли оставить до него.
- Смотрят журнал ошибок вместо журнала доступа. В журнале ошибок обращений к wp-content/upgrade может не быть совсем.
- Пугаются сотен строк с кодом 404 и начинают чистить сайт, который не пострадал. Эти строки оставляют сканеры, опасны только успешные ответы.
- Удаляют подозрительный файл и не меняют пароли и ключи в wp-config.php. Злоумышленник с активной сессией или запасным файлом вернется.
- Восстанавливают сайт из резервной копии, сделанной уже после взлома, и возвращают тем самым вредоносный код.
- Забывают про старые копии сайта на поддоменах вроде dev или old. Они часто остаются на уязвимой версии и дают доступ к тому же хостингу.
Если в компании несколько сайтов на WordPress, составьте их список с версиями и датами последних обновлений. Такой список помогает не только сейчас: следующая уязвимость в ядре или популярном плагине будет, и проверка по готовому списку займет минуты.
Как подготовить сайт к следующей уязвимости
Чтобы следующая уязвимость в ядре или плагине не превращалась в аврал, нужны три вещи: журналы, которые хранятся достаточно долго, резервные копии вне хостинга и понятный ответственный за обновления. Эту подготовку проще сделать сейчас, пока история с CVE-2026-119977 свежа и все понимают, зачем она нужна.
Начните с журналов. Узнайте у хостинга, сколько дней хранится журнал доступа. Если меньше месяца, попросите увеличить срок или настройте ежедневную выгрузку журналов в отдельное хранилище. В этой истории именно журналы отвечают на вопрос, был взлом или нет, и без них проверка превращается в гадание.
Затем резервные копии. Копия, которая лежит на том же хостинге, что и сайт, при взломе аккаунта может пострадать вместе с ним. Храните хотя бы одну копию в другом месте и раз в квартал пробуйте восстановить из нее тестовый сайт: так вы узнаете, что копия рабочая, до того как она понадобится.
Дальше решите, как сайт обновляется. Автообновления ядра для младших выпусков безопасности полезны, их стоит оставить включенными. Но кто-то должен получать письма WordPress об обновлениях и раз в неделю заходить в консоль. Удобно завести для этого общий ящик: письма на личную почту сотрудника перестанут читать в тот день, когда он уволится.
И последнее: уберите с хостинга все, чем не пользуетесь. Старые копии сайта, отключенные плагины, неиспользуемые темы и пользователи бывших подрядчиков увеличивают число мест, через которые можно зайти. На проверку и чистку такого мусора обычно уходит час, а риск от него остается годами.
Частые вопросы
Как понять, что мой сайт на WordPress пытались взломать через CVE-2026-119977?
Ищите в журнале доступа запросы к PHP-файлам в папке wp-content/upgrade, особенно к setup-config.php. Запросы с кодом 404 или 403 означают неудачную попытку, их оставляют сканеры. Ответ 200 в момент обновления ядра говорит о том, что попытка могла пройти, и тогда нужна полная проверка файлов, пользователей и базы данных.
Можно ли просто обновить WordPress до 7.1.4 и ничего не проверять?
Обновление закрывает уязвимость, но не удаляет то, что злоумышленник мог оставить до патча. Если ядро сайта обновлялось с 28 октября до установки 7.1.4, проверьте журналы и сверьте файлы ядра. Если обновлений в этот период не было, достаточно короткой проверки администраторов и контрольных сумм.
Что делать, если на сайте стоит WordPress 4.6 или еще более старая версия?
Для версий 4.6 и старше исправление не выпускается, поэтому такой сайт нужно переносить на актуальную версию WordPress. До переноса закройте веб-доступ к папке wp-content/upgrade и не запускайте полное обновление ядра без резервной копии. Перенос старого сайта обычно требует проверки темы и плагинов на совместимость.
Касается ли эта уязвимость сайтов на 1С-Битрикс и Тильде?
Нет, CVE-2026-119977 относится только к ядру WordPress и его процессу обновления. Сайты на 1С-Битрикс, Тильде и других платформах эта уязвимость не затрагивает. Но если на том же хостинге рядом с ними лежит старая копия сайта на WordPress, ее стоит проверить или удалить: взлом одного сайта может дать доступ ко всему аккаунту хостинга.
Сколько дней нужно хранить журналы доступа сайта?
Для коммерческого сайта разумный минимум — 30 дней, лучше 90. Атаку часто обнаруживают через одну-две недели после того, как она произошла, и короткий срок хранения стирает следы раньше, чем их начнут искать. Если хостинг хранит журналы меньше, настройте их ежедневную выгрузку в отдельное хранилище или попросите поддержку хостинга увеличить срок.