CVE-2026-60137 и CVE-2026-63030: что обновлять

Обе уязвимости WP2Shell исправлены в WordPress 6.9.5 и 7.0.2; ветка 6.8 получила исправление только для одной из них в версии 6.8.6. Это минимальные версии с патчем, а не рекомендация оставаться на них: установите последнее обновление доступной вам ветки. Ниже — что именно проверять и как не спутать номер релиза с реальным состоянием сайта.

Что известно о двух уязвимостях WordPress

WP2Shell — общее название цепочки из CVE-2026-60137 и CVE-2026-63030. В официальном сообщении WordPress первая описана как SQL-инъекция, вторая — как ошибка обработки пакетных запросов REST API, также связанная с SQL-инъекцией и приводящая к удалённому выполнению кода. Это две разные проблемы, поэтому нельзя сводить их к одной «дырке в API». Для эксплуатации не требуется, чтобы сайт был крупным или известным: автоматический сканер не оценивает оборот компании, он проверяет доступный сайт и его программные версии. Но и объявлять каждый старый сайт уже взломанным неправильно: уязвимая версия означает необходимость обновления, а не доказательство состоявшейся атаки. Если нужна системная проверка CMS и процесса обновлений, мы проводим аудит информационной безопасности.

Важная граница по версиям: WordPress до 6.8 официальная команда не считает затронутым именно этой парой уязвимостей. Это не сертификат безопасности старой установки — там могут быть другие известные проблемы и давно не обновлявшиеся плагины. Ветка 6.8 затронута только первой уязвимостью; в 6.9 затронуты обе. Для основной ветки 7.0 релиз 7.0.2 включил исправления обеих. Патчи для старых веток были выпущены одновременно с основным security-релизом, чтобы не заставлять всех перескакивать на новую крупную версию. Это полезная совместимость, но не повод забыть про следующие обновления.

Название WP2Shell звучит как название одного эксплойта, однако в статье я разделяю подтверждённые сведения: два CVE, типы ошибок и версии исправлений. База знаний содержит сообщения об эксплуатации без авторизации и принудительном обновлении затронутых установок; официальный релиз тоже сообщает, что для уязвимых сайтов включили принудительные обновления через механизм автообновления. Это не позволяет обещать, что каждый сайт обновился: автообновление зависит от состояния установки, доступности файлов и настроек. Проверьте результат вручную. «Наверное, обновилось» — удобный статус, но не техническая проверка.

• CVE-2026-60137 — SQL-инъекция
• CVE-2026-63030 — ошибка REST API batch
• До WordPress 6.8 эта пара не затрагивает

Какие версии содержат исправления

WordPress выпустил исправления 17 июля 2026 года. Минимальные версии с патчами — 6.8.6, 6.9.5 и 7.0.2. Соответствие не одинаковое: 6.8.6 закрывает CVE-2026-60137; 6.9.5 и 7.0.2 закрывают обе уязвимости. В релизе также отмечено, что бета-ветка 7.1 была затронута и исправление вошло в 7.1 beta 2. Бету на рабочем сайте ставить нельзя; это упоминание важно лишь для полноты охвата. Я сверяю диапазон с официальной страницей WordPress, потому что пересказ «обновитесь до 7.0.2» теряет смысл для сайта, который остаётся на поддерживаемой ветке 6.9.

Есть и другая ловушка: минимальная версия патча не равна актуальной версии ветки. На дату проверки, 27 октября 2026 года, официальный список релизов показывает более поздние выпуски, включая 7.1.3, 7.0.7, 6.9.10 и 6.8.11. Это пример текущего состояния, оно меняется с новыми релизами. Практическое правило проще таблицы с вечными цифрами: установите актуальный выпуск своей ветки, если она доступна и поддерживается, и отдельно проверьте совместимость сайта. Не оставайтесь на 6.9.5 или 7.0.2 лишь потому, что именно они фигурируют в сообщении о CVE.

В старой статье о конкретном инциденте уместно написать, что в июле исправления появились в 6.8.6, 6.9.5 и 7.0.2. В инструкции для администратора я добавляю следующий шаг: после установки исторического минимума проверьте, нет ли более свежего security-релиза. Обновление WordPress часто включает не только исправление рассматриваемой уязвимости. Пропустить накопленные исправления ради точного совпадения с номером в заметке — как закрыть одну трещину и не посмотреть на стену вокруг неё. Версию выбирают по ветке и актуальному каналу выпуска, а не по заголовку новости.

• 6.8.6 — исправляет первую уязвимость
• 6.9.5 — исправляет обе
• 7.0.2 — исправляет обе

Как проверить версию и обновить ядро

В панели откройте «Консоль → Обновления»: там видна версия WordPress и доступные обновления. Из командной строки WP-CLI показывает установленную версию командой wp core version. Запускайте команду из каталога сайта или укажите путь, если WP-CLI настроен на другой каталог. Команда выводит номер файлов ядра; она не доказывает, что сайт целиком исправен, что база обновлена или что файлы не менялись вручную. Для первичной проверки этого достаточно. Затем сравните результат с актуальными выпусками официального архива, а не с сохранённой где-то таблицей из старой статьи.

Перед обновлением я фиксирую текущую версию, проверяю доступность бэкапа файлов и базы и убеждаюсь, что копию можно восстановить. Для рабочего сайта полезно проверить обновление на тестовой копии, особенно если тема или плагины давно не обновлялись. Это не обязательный ритуал на каждый клик, но рискованное сочетание старой темы, самописных модификаций и крупного перехода нельзя проверять на живых данных. После обновления проверьте номер версии ещё раз, откройте ключевые страницы и формы, посмотрите журнал ошибок и запустите проверку целостности файлов. Если панели пишет «готово», а номер не изменился — готово только уведомление.

Обновление через панель — штатный способ; WordPress также поддерживает фоновые обновления для многих установок. Не считайте автообновление заменой инвентарю: сайты с проблемами прав на файлы, отключёнными обновлениями или ошибками во время установки могут остаться на старой версии. WP-CLI пригоден для регулярного сбора версии, но автоматический скрипт должен сообщать об ошибке и недоступности сайта, а не молча записывать пустое значение как «всё хорошо». Для нескольких сайтов храните адрес, ветку, текущий релиз, дату проверки и результат. Такая таблица короче расследования после вопроса «а этот сайт мы обновили?». О том, как проверять CMS сканированием и где заканчиваются возможности такой проверки, есть отдельный материал — проверка WordPress на уязвимости.

• Зафиксировать текущую версию
• Проверить и восстановить бэкап на тесте
• Установить свежий патч своей ветки
• Проверить версию и работу сайта

Разбор условного кейса с сайтом фотостудии

Разберу условный сценарий, а не буду выдавать его за опубликованный клиентский инцидент. В исходном кейсе — сеть фотостудий «Кадр на крыше», 29 рабочих мест, сайт на WordPress 6.9.2. Если такая установка встретилась в инвентаре, первое действие — зафиксировать версию и проверить официальный перечень затронутых релизов: 6.9.2 относится к ветке 6.9, исправления для которой появились в 6.9.5. Следом я уточняю, кто отвечает за тему и плагины, есть ли копия базы и файлов, и можно ли проверить восстановление без влияния на сайт. Нельзя честно обещать, что обновление займёт ровно час или что все компоненты совместимы, пока этого не проверили на конкретной установке.

Дальше план работ выглядит скучно — и это хорошо. Создаём резервную копию, поднимаем тестовую копию, обновляем её до последнего подходящего выпуска ветки и проверяем страницы, формы, вход в админку и журнал ошибок. Если тест прошёл, согласуем короткое окно, повторяем копирование непосредственно перед работами, обновляем рабочий сайт и проверяем версию после установки. В рассматриваемом примере 6.9.5 — минимальный релиз, содержащий оба исправления, но на дату публикации нужно смотреть более свежий релиз ветки. Если он установлен, это фиксируем; если переход блокируют несовместимые расширения, устраняем препятствие, а не объявляем сайт защищённым по обещанию подрядчика.

Вместо выдуманного результата «сканер подтвердил отсутствие уязвимостей» я записываю проверяемые итоги: какой релиз установлен, что проверено в интерфейсе, завершилось ли восстановление тестовой копии и остались ли ошибки. Сканер может помочь искать известные признаки, но отсутствие находок не доказывает отсутствие компрометации. Если до обновления были подозрительные учётные записи, неизвестные файлы или перенаправления, это отдельная проверка инцидента: один патч не удалит уже размещённый злоумышленником код. Так отчёт остаётся полезным и через месяц, а не выглядит как рекламная фраза «всё чисто».

• Версия в инвентаре: 6.9.2
• Проверка на копии сайта
• Обновление и функциональная проверка
• Фиксация результата и остаточных задач

Резервные копии и учёт обновлений

Бэкап на том же диске, что и сайт, может исчезнуть вместе с ним. Копию нужно хранить отдельно от рабочей системы и периодически проверять восстановлением. Перед обновлением особенно важно понимать, что именно попадает в копию: база содержит записи, настройки и учётные данные, файлы — ядро, темы, плагины и загрузки. Если резервный процесс давно никто не проверял, слово «есть» говорит только о наличии задания. Я прошу показать успешное восстановление на отдельной среде или хотя бы документированный результат последнего теста. Ежемесячная проверка восстановления в нашем процессе — рабочая рекомендация, а не универсальный интервал, установленный разработчиками WordPress. Практику отдельного хранения и восстановления мы разбираем в инструкции про резервное копирование WordPress.

Инвентарь не должен превращаться в музей таблиц. Для каждого сайта достаточно поддерживать ответственные поля: адрес, текущая ветка и версия, дата последней проверки, доступен ли бэкап, статус тестирования и найденные блокеры обновления. Номер CVE добавляйте, когда он относится к конкретному случаю; рядом укажите минимальную исправленную версию и ссылку на первичный релиз. При обнаружении старой версии сначала выясните, существует ли подходящий выпуск и можно ли обновить сайт штатно. Если версия уже исправлена, но сайт продолжает выдавать подозрительные ошибки, переходите к расследованию, а не ставьте диагноз по одному номеру.

Для небольшой компании такой учёт особенно полезен: сайт часто обслуживают по остаточному принципу, а доступы хранятся у разных подрядчиков. Не нужно покупать отдельную платформу ради пяти сайтов. Начните с общего списка и регулярного владельца процесса: кто проверяет обновления, кто согласует окно и кто подтверждает результат. В середине статьи я уже разобрал безопасный порядок; в конце напомню главное: установить исправление, проверить, что оно действительно установлено, и иметь рабочий путь назад. Если вам нужна помощь с обновлениями WordPress и резервным копированием, команда может взять эти действия на регулярное обслуживание сервера от 7 000 ₽ в месяц.

• Хранить копию отдельно от сайта
• Проверять восстановление на отдельной среде
• Записывать версию и дату проверки
• Не путать патч и расследование инцидента

Частые вопросы