Вы выходите из аккаунта в английской версии магазина - и сессия на эстонском домене тоже должна завершиться. Вот на этом переходе старая конфигурация WPML может открыть еще одну дверь в аккаунт.
Но условия здесь важны. CVE-2026-76877 касается единого входа между отдельными языковыми доменами, то есть SSO, и гонки запросов во время выхода настоящего пользователя. Это не захват любого сайта с WPML одним запросом. Адреса вроде example.com/et/ - не та конфигурация с отдельными доменами, которую описывает этот сценарий.
По состоянию на 11 ноября 2026 года есть существенная оговорка: Patchstack прямо пишет, что официального исправления нет. Переход на поддерживаемую стабильную WPML 5 - разумный шаг, но не доказательство устранения именно этой уязвимости.
Проверяйте версию WPML вместе с настройками языков
В уведомлении от 9 ноября 2026 года Patchstack указывает WPML Multilingual CMS до версии 4.9.7 включительно. Проблема - нарушение аутентификации без предварительного входа в аккаунт, оценка CVSS - 8,1. Исправленный выпуск ветки 4.9.x не назван.
Номер версии - только половина проверки. Еще нужно выяснить, используются ли отдельные домены для языков и работает ли между ними общий вход.
Допустим, магазин туристического снаряжения использует example.com для английского и example.ee для эстонского, а сессии аккаунтов общие. Такую схему стоит проверить. Само наличие WPML еще не подтверждает этот риск. Уязвимая версия тоже не доказывает взлом.
Не гадайте по главной странице. Вместе со специалистом, который обслуживает сайт, проверьте установленную версию плагина, настройки адресов языковых версий и то, как устроен обмен сессиями.
Что за гонка при выходе из аккаунта
Описание Wordfence CNA, опубликованное в NVD, объясняет проблему как гонку запросов при выходе через SSO между языковыми доменами. Во время выхода настоящего пользователя обработка анонимных или общих токенов может привести к выдаче его файлов cookie аутентификации постороннему. Для этого атакующий должен выиграть гонку.
Администраторов это тоже касается. В этом и серьезность проблемы.
Если на пальцах: система согласует выход между доменами, но при описанных условиях может выдать доступ не тому человеку. Пароль жертвы атакующему не нужен. Зато нужны подходящая конфигурация и удачный момент во время выхода. «Без пароля» не значит «без каких-либо условий».
В рассмотренных уведомлениях нет подтверждения реальных атак. Patchstack говорит об ожидаемой эксплуатации, а не об уже замеченных взломах. Риск стоит воспринимать всерьез, но предупреждение - еще не свидетельство того, что кто-то проник на ваш сайт.
Оставьте 2FA, но не считайте ее исправлением
Длинный пароль не исправит ошибочную выдачу cookie. Ограничение неудачных попыток входа тоже: здесь речь не об обычном переборе паролей через форму авторизации.
Двухфакторная аутентификация администраторам по-прежнему нужна. Не отключайте ее. Просто проверка в обычной форме входа не обязательно остановит другой механизм, который выдает cookie уже авторизованного пользователя.
В руководстве по защите входа в WordPress разобраны эти повседневные меры. Они полезны, но не заменяют работу с риском в междоменном SSO.
Сначала ограничьте риск, потом нажимайте «Обновить»
Я бы начал с короткой письменной проверки, а не со спешного апдейта рабочего сайта. На первичный сбор сведений можно отвести 15-30 минут, если доступы и ответственный специалист под рукой. Это ориентир, не срок устранения проблемы.
- Запишите конфигурацию. Версию WPML, языковые домены, связанные компоненты WPML и состояние междоменного SSO.
- Обратитесь в поддержку WPML. Если ваша версия это поддерживает, временно отключите междоменный SSO до подтверждения, что риск устранен. Способ отключения пусть подтвердит поддержка.
- Если отключение недоступно, привлеките специалиста для изоляции затронутых языковых доменов. Особенно когда между ними переходят покупательские аккаунты или сессии оформления заказа.
- До изменений сделайте бэкап. Сохраните файлы и базу данных отдельно от рабочего сервера. Проверьте, что из копии можно восстановиться.
Перед изменениями убедитесь что ответственный за заказы знает о возможных последствиях. Временную потерю общего входа придется объяснить покупателям, если они привыкли переходить между языковыми версиями магазина.
И не заменяйте домены адресами вида /et/ на скорую руку. Это уже перенос URL: редиректы, видимость в поиске, старые ссылки. Другая задача. Возможно, немаленькая.
Подготовьте проверенный переход на стабильную WPML 5
В журнале изменений разработчика WPML 5.0.0 датирована 15 сентября 2026 года. Среди изменений есть усиление безопасности, в том числе по сообщению Wordfence. Но CVE-2026-76877 там не названа. Этого недостаточно, чтобы объявить 5.0.0 подтвержденным исправлением.
В проверенном журнале WPML 5.3.0 указана как стабильная версия от 4 ноября, а 5.3.1-beta.1 - как бета от 9 ноября. Планируйте уход со старой затронутой ветки 4.9 на актуальную поддерживаемую стабильную WPML 5 после проверки на тестовой копии. Не на бету. И запросите у поддержки WPML подтверждение, что риск в вашей схеме доменного SSO устранен. Новая основная версия сама по себе не гарантирует безопасность навсегда.
На тестовой копии используйте отдельные аккаунты без важных данных и тестовый режим оплаты. Закройте ее от посторонних и отключите отправку настоящих писем клиентам. Затем проверьте:
- Страницы каждого языка, меню, ссылки на товары и переведенный контент.
- Вход и выход на настроенных доменах: завершаются ли сессии там, где должны.
- Для WooCommerce - сохранение корзины, оформление и создание заказа, сообщения с подтверждением. Без реальных списаний.
Эти проверки помогают заметить поломки рабочих сценариев. Отсутствие уязвимости они не доказывают. Если некому заняться тестовой копией, бэкапами и переносом изменений, можно поручить это специалисту по обслуживанию WordPress.
Подозрительные аккаунты нужно проверять, а не угадывать причину
Незнакомый администратор или неожиданная активность аккаунта - повод разобраться. Но сами по себе они не указывают именно на эту уязвимость.
Сохраните доступные журналы обращений и безопасности, сведения об аккаунтах и время событий до того, как обычная очистка сотрет следы. Сразу уточните у хостинга сроки хранения логов. Не вставляйте cookie сессий, пароли и данные покупателей в публичные формы поддержки.
В инструкции по восстановлению взломанного WordPress разобран весь процесс восстановления. При подозрении на чужой доступ запланируйте проверку учетных данных. Такая проверка и любая их замена требуют разрешения владельца; параллельно нужно аккуратно ограничить подозрительные сессии.
Если нужна помощь с расследованием и восстановлением, ручная очистка взломанного сайта поможет разобраться в случившемся, а не просто убрать заметный симптом.
Сегодня запишите две вещи: версию WPML и наличие общих сессий между отдельными языковыми доменами. Если обе указывают на описанный риск, отправьте сведения поддержке WPML и запросите поддерживаемый способ временно ограничить доступ. До того как считать обновление готовым ответом.