Представьте: злоумышленник сегодня оставляет на сайте две странные записи. Магазин не падает, заказы идут, в админке тишина. Вы даже не знаете, что что-то случилось.
Позже администратор экспортирует сайт в архив .wpress. Еще через какое-то время этот архив импортируют, чтобы восстановить сайт на той же уязвимой версии плагина. Вот тогда безобидная с виду запись из базы может стать рабочей SQL-инъекцией.
Так устроена CVE-2026-19949 в All-in-One WP Migration and Backup. Получается бэкап с таймером. Но это не значит, что малварь сидит в каждом архиве. Нет. Сначала на сайт должны подложить специально сформированные данные, затем экспорт должен перенести их в архив, а опасная обработка начнется лишь при последующем импорте или восстановлении.
Вывод короткий: если плагин установлен, обновите его до версии 7.110 или новее до следующего экспорта, импорта или восстановления. Именно до.
Ловушка начинается с двух трекбэков
Для первого шага атакующему не нужен аккаунт WordPress. Нужна публичная запись, которая принимает пинги, и возможность отправить на нее два специально сформированных трекбэк-запроса. Значения из них сохраняются в базе данных.
Дальше администратор делает экспорт через All-in-One WP Migration. Плагин переносит сохраненные значения в архив .wpress. Сам экспорт SQL-инъекцию не запускает. Он лишь упаковывает опасные данные и несет их дальше.
Триггер срабатывает позже, когда администратор импортирует этот архив или восстанавливает из него сайт через All-in-One WP Migration версии 7.109 или более ранней. Во время восстановления механизм поиска и замены обрабатывает подложенные значения, и они могут превратиться в SQL-инъекцию второго порядка.
Термин звучит академично. На пальцах все проще: опасная строка попала через один вход, спокойно доехала внутри архива, а доверенный процесс восстановления позднее сделал ее активной. Экспорт без последующего уязвимого импорта тут недостаточен.
И момент крайне неудобный. Бэкап обычно поднимают, когда сайт уже лежит, реклама крутится и владелец считает потерянные заказы. В такой спешке мало кто думает о двух трекбэках месячной давности.
Как цепочка может дойти до запуска PHP
SQL-инъекция может раскрыть значение ai1wm_secret_key. Согласно описанию CVE, доступ к этому ключу способен открыть дальнейший путь к удаленному выполнению кода через контроллер импорта All-in-One WP Migration, который не требует обычной авторизации.
В подробном разборе описан один возможный маршрут: импорт специально подготовленного архива .wpress с вредоносным must-use плагином. MU-плагины лежат в wp-content/mu-plugins/, и WordPress загружает их автоматически. Если чужой PHP-код действительно попадет туда и запустится, атакующий может получить выполнение команд на сервере.
Это объяснение потенциального RCE, а не подтверждение того, что отдельный вредоносный импорт уже происходил в реальной атаке. На 2 сентября таких подтвержденных случаев нет.
Для всей цепочки должны совпасть несколько условий:
- публичная запись принимает пинги, а два сформированных трекбэк-запроса сохраняют значения в базе;
- администратор экспортирует данные зараженного источника в архив
.wpress; - этот архив позже импортируют или восстанавливают через версию 7.109 или более раннюю;
- для выхода к RCE должна сработать и дальнейшая часть цепочки с секретным ключом и контроллером импорта.
Поэтому цифры на первый взгляд спорят друг с другом. У CVE-2026-19949 оценка CVSS 8.8, то есть возможный ущерб серьезный. При этом Patchstack считает практический приоритет низким, а эксплуатацию маловероятной: путь длинный и довольно капризный. Обе оценки могут быть честными одновременно.
Версии и дату исправления можно проверить в карточке уязвимости Wordfence.
Пять миллионов установок — не пять миллионов уязвимых сайтов
У All-in-One WP Migration and Backup больше 5 миллионов активных установок во всех версиях. Это общая популярность плагина, а не число сайтов, которые прямо сейчас уязвимы. Уязвимы версия 7.109 и более ранние.
Исправление вышло в 7.110 20 августа. Информацию раскрыли 24-25 августа, так что быстро обновившиеся сайты успели закрыть этот путь еще до широкой огласки.
На 2 сентября нет подтвержденной эксплуатации в реальных атаках, надежного публичного PoC и записи в каталоге CISA KEV. Хорошая новость. Можно действовать спокойно, без удаления всех архивов подряд и без предположения, будто любой файл .wpress уже заражен.
Сканер уязвимостей WordPress поможет заметить старую версию. Но проверка версии не расскажет, попали ли сформированные трекбэки в базу, уехали ли их значения в архив и обрабатывался ли потом этот архив во время уязвимого восстановления. Тут нужна уже первичная проверка инцидента.
Что сделать до следующего восстановления
- Обновите All-in-One WP Migration до 7.110 или новее. Сделайте это перед экспортом, импортом, переносом и восстановлением.
- Удалите плагин, если он не используется. Инструмент, поставленный два года назад ради одного переезда, не обязан круглосуточно торчать на рабочем сайте.
- Не выбрасывайте бэкапы в панике. Эта CVE не доказывает, что каждый архив заражен.
- Записывайте экспорт и восстановление. Дата, имя архива, исходный сайт и версия плагина потом сильно экономят время.
При регулярном обслуживании WordPress апдейт должен пройти до запланированной миграции. Порядок тут решает все: патч закрывает уязвимую обработку в будущих восстановлениях, но не доказывает, что раньше цепочка не сработала.
И не путайте наличие файла с готовым планом. В статье о том, почему бэкап — это еще не план восстановления, мы разбирали разницу между «архив где-то есть» и проверенным возвращением сайта в работу. Сейчас к этому добавился еще один пункт: чем именно и где вы будете проверять подозрительный архив.
Если архив уже восстанавливали на версии 7.109 или более ранней
Сначала не удаляйте. Проверьте именно последовательность: принимала ли публичная запись пинги, могли ли два сформированных трекбэк-запроса сохранить значения в базе, экспортировал ли администратор после этого сайт в .wpress, а затем импортировал или восстанавливал ли он тот же архив через версию 7.109 или более раннюю?
Если ответ «возможно», сделайте снимок текущего состояния и начните первичную проверку. Сохраните и подозрительный архив. Не тестируйте его на рабочем сайте. Изучать такой файл или восстанавливать его стоит только в изолированной среде с уже исправленным ПО.
До чистки проверьте администраторов WordPress, каталог mu-plugins, недавно измененные PHP-файлы, записи базы и серверные логи. Сохраните подозрительные файлы, временные метки и журналы. Удалить улику легко, вернуть ее потом почти нереально.
Порядок первых действий мы отдельно собрали в материале о том, что делать в первые 24 часа после взлома сайта. Принцип тот же: сперва зафиксировать состояние и понять возможный вход, потом чистить.
Нашли неизвестного администратора, чужой MU-плагин или PHP, которого там быть не должно? Считайте сайт скомпрометированным. Для очистки взломанного WordPress придется проверить ядро, плагины, темы, загрузки, базу, задания cron и доступы. После фиксации доказательств и очистки смените связанные пароли и ключи, затем завершите активные пользовательские сессии.
Суть без лишней паники
Цепочка идет строго по порядку: атакующий сохраняет данные через два сформированных трекбэк-запроса, экспорт переносит их в .wpress, а SQL-инъекция может сработать лишь при последующем импорте или восстановлении этого архива на версии 7.109 или более ранней. Один экспорт атаку не запускает.
Обновитесь до 7.110+ перед любой работой с архивами и удалите плагин, если он не нужен. Если вся последовательность могла уже произойти, сохраните текущий снимок и сам архив, проведите первичную проверку, а чистку начинайте только после фиксации следов.
Без костра из бэкапов. Сначала патч, затем безопасная проверка и только потом восстановление.