Если Вы получили от меня письмо со ссылкой на эту страницу, то потому, что Ваш сайт, по всей видимости, использует версию плагина Events Manager (плагин WordPress events-manager от Marcus Sykes / wp-events-plugin.com), которая попадает в затронутый диапазон известной проблемы безопасности. На этой странице объясняется, в чём заключается проблема, как определить, касается ли она вообще Вашего сайта, и как обновиться.

Прежде всего, самый важный факт об этом уведомлении: версия из затронутого диапазона сама по себе не означает, что Ваш сайт уязвим. Описанную ниже проблему можно эксплуатировать только тогда, когда Events Manager настроен на приём бронирований от посетителей, которые не вошли в систему (режим плагина “No-User-Account Booking Mode”, то есть бронирование без учётной записи). Если Ваш сайт требует учётной записи для бронирования или вообще не принимает бронирований, он, скорее всего, не уязвим даже на затронутой версии. Я могу прочитать версию Вашего плагина из публичных файлов, но не вижу Вашу конфигурацию бронирования, поэтому данное уведомление является предупредительным сигналом, а не подтверждённым выводом о Вашем сайте.

Речь идёт об уязвимости CVE-2026-12987, неавторизованной инъекции PHP-объектов, приводящей к SQL-инъекции в системе бронирования плагина. Орган, присвоивший CVE, не опубликовал оценку серьёзности; Patchstack оценивает ту же находку в 8,8 из 10 (высокая степень серьёзности). Она затрагивает версии с 4.0.0 по 7.3.6 и устранена в версии 7.3.7. Если Вы используете затронутую версию, обновите Events Manager до 7.3.7 или новее (рекомендуется текущий выпуск линейки 7.4.x). Нет никаких признаков того, что эта проблема где-либо эксплуатируется.

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

Это уязвимость плагина, а не ядра WordPress. Полностью актуальный WordPress не защищает Вас, если сам плагин Events Manager находится на затронутой версии.

Является ли это сообщение подлинным?

Да. Это добросовестное уведомление в рамках ответственного раскрытия информации от независимого исследователя безопасности. Я не прошу у Вас денег, паролей или доступа к Вашему сайту и не пытался проникнуть в него, что-либо загрузить или что-либо эксплуатировать.

Всё, что я сделал, это просмотрел публично доступные файлы, которые Ваш сайт предоставляет каждому посетителю (точно так же, как публична Ваша главная страница), и отметил номер версии, который плагин Events Manager публикует в своём публичном файле readme.txt. Системы бронирования я специально не касался, и ничто в этой проверке не затрагивает Ваши данные, Вашу административную панель или какую-либо частную часть Вашего сайта (подробнее в разделе Что я делал и чего не делал ниже).

Если Вы хотите убедиться в том, кто я, ознакомьтесь с контактными данными внизу этой страницы и на странице Обо мне.

Почему это важно

Events Manager является одним из старейших плагинов для событий и бронирований для WordPress (в официальном каталоге с 2008 года, с примерно 6,3 миллионами загрузок за всё время). Он позволяет сайту публиковать события и принимать бронирования на них, в том числе, если оператор того пожелает, бронирования от посетителей, у которых нет учётной записи на сайте.

В затронутых версиях, когда посетитель отправляет бронирование, заполненные им пользовательские поля регистрации сохраняются как данные бронирования, а когда плагин позже загружает это бронирование, он распаковывает (“десериализует”) сохранённые данные, не ограничивая то, что им разрешено содержать. Поэтому специально сформированный ввод может быть превращён в программные объекты по выбору злоумышленника (инъекция PHP-объектов), а цепочка таких объектов достигает запроса к базе данных, который не параметризован должным образом (SQL-инъекция). Практический эффект для сайта в уязвимой конфигурации: злоумышленник без учётной записи и без входа в систему мог бы прочитать произвольные данные из базы данных сайта, такие как хеши паролей и секретные ключи, которые использует WordPress.

Две вещи помогают взглянуть на это трезво. Во-первых, точкой входа является публичная форма бронирования, поэтому атака работает только там, где посетитель, не вошедший в систему, может отправить бронирование. Это как раз предварительное условие “No-User-Account Booking Mode”: если бронирование на Вашем сайте требует учётной записи, уязвимый путь недостижим для анонимных посетителей, и Ваш сайт, скорее всего, не уязвим даже на затронутой версии. Во-вторых, это проблема чтения данных, а не захват сервера или учётной записи администратора: она сама по себе не позволяет злоумышленнику выполнить код на Вашем сервере или войти в Вашу административную панель. И, повторяя это прямо, нет никаких признаков активной эксплуатации: её нет в каталоге известных эксплуатируемых уязвимостей CISA (Known Exploited Vulnerabilities), её оценка вероятности эксплуатации (EPSS) близка к нулю, и мне не известно ни об одном отчёте об эксплуатации.

Если в моём письме упоминалась эта проблема, это означает, что версия, о которой сообщает Ваш сайт, попадает в затронутый диапазон. Я не проверял, уязвим ли Ваш конкретный сайт, и не вижу, как настроена Ваша система бронирования; всё, что я наблюдал, это то, что сайт сообщает о затронутой версии.

Затронут ли мой сайт?

Это определяют два вопроса, в таком порядке.

Первый: принимаете ли Вы бронирования от посетителей, которые не вошли в систему? Это решающий вопрос, и ответить на него можете только Вы.

  • Если бронирования на Вашем сайте требуют учётной записи или входа в систему или Ваш сайт вообще не принимает бронирований, Вы, скорее всего, не уязвимы даже на затронутой версии. Обновление всё же рекомендуется как обычное обслуживание.
  • Если Ваш сайт принимает бронирования от посетителей без учётной записи (Events Manager называет это “No-User-Account Booking Mode”), проблема касается Вас, и Вам следует обновиться незамедлительно.
  • Чтобы проверить: в административной панели WordPress найдите в настройках бронирования Events Manager параметр, разрешающий бронирования без учётной записи. Или просто проверьте это снаружи: откройте одну из страниц Ваших событий в окне приватного просмотра и посмотрите, сможете ли Вы заполнить и отправить бронирование без запроса на вход в систему.

Второй: какую версию Вы используете? Вам не обязательно верить мне на слово.

Из публичного манифеста (вход в систему не требуется): откройте в браузере yourdomain.com/wp-content/plugins/events-manager/readme.txt. Обратите внимание, что этот плагин поставляет свой файл readme как readme.txt (в нижнем регистре). Строка Stable tag: вверху содержит версию, о которой сообщает Ваша установка, и это тот же публичный файл, который прочитал я.

Из административной панели WordPress (если у Вас есть доступ):

  1. Войдите в панель управления WordPress (обычно по адресу yourdomain.com/wp-admin).
  2. Перейдите в Plugins затем Installed Plugins.
  3. Найдите Events Manager и запишите версию, указанную под его названием.

Затем примените следующее правило и учтите, что версии сравниваются численно, а не по алфавиту:

  • С 4.0.0 по 7.3.6: потенциально затронуты (при условии, оговорённом в вопросе о режиме бронирования выше), обновитесь сейчас.
  • 7.3.7 или новее: уже исправлены. Сюда входит 7.3.7.1, которая была последующим исправлением несвязанной с безопасностью регрессии отображения, а не вторым выпуском по безопасности: и 7.3.7, и 7.3.7.1 содержат исправление безопасности. Сюда также входят все текущие выпуски 7.4.x.
  • Старше 4.0: этой проблемой не затронуты. Уязвимая обработка данных бронирования впервые появилась в переработанной версии плагина 4.0, поэтому более ранние выпуски её не содержат (у столь старого выпуска есть множество других причин для обновления, но данное уведомление к ним не относится).
  • Не дайте себя ввести в заблуждение текстовым порядком: до 6.0 Events Manager использовал строки версий вроде 5.99912 (производитель застрял на схеме нумерации 5.999.x вплоть до 6.0), и такая версия является старым выпуском ниже 6.0, внутри затронутого диапазона, а не чем-то более новым, чем 7. Сравнивайте каждое число по очереди, вместо того чтобы читать версию как текст.

Как обновиться

Самый безопасный путь: обновление через сам WordPress, предварительно создав резервную копию:

  1. Создайте резервную копию Вашего сайта (файлы и база данных) перед внесением изменений. Большинство хостинг-провайдеров предлагают резервное копирование в один клик, или используйте плагин резервного копирования WordPress.
  2. В административной панели WordPress перейдите в Dashboard затем Updates, или Plugins затем Installed Plugins. Если обновление Events Manager указано в списке, установите его отсюда.
  3. Если Вы предпочитаете командную строку, WP-CLI делает то же самое: wp plugin update events-manager.
  4. Если обновление не появляется, Вы можете получить последний выпуск напрямую со страницы плагина в каталоге WordPress.org, Events Manager, и обновить его через Plugins затем Add New Plugin затем Upload Plugin.
  5. После обновления подтвердите новый номер версии (7.3.7 или новее; рекомендуется текущий выпуск линейки 7.4.x), следуя приведённым выше шагам, и проверьте, что страницы Ваших событий и бронирований работают нормально.

Раз уж Вы этим занялись, стоит убедиться, что ядро WordPress и Ваши прочие плагины актуальны, поскольку тот же принцип применим ко всем из них.

После обновления

Обновление до 7.3.7 или новее закрывает проблему, и для большинства сайтов на этом задача завершена. Нет никаких признаков того, что эта уязвимость где-либо эксплуатировалась, поэтому никакие экстренные меры не подразумеваются: Вам не нужно считать свой сайт скомпрометированным или отключать его.

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

  • Просмотрите недавние бронирования и активность пользователей на предмет чего-либо, что кажется неправильным, обычным образом, каким Вы просматриваете активность сайта.
  • Смените секреты, которые хранятся в Вашей базе данных и конфигурации: перегенерируйте секретные ключи и соли WordPress в wp-config.php (новые значения в одном клике на официальном генераторе секретных ключей; их замена разово выводит всех пользователей из системы) и смените пароль Вашей базы данных через панель хостинга. Поскольку хеши паролей были среди данных, теоретически доступных для чтения, разумным дополнительным шагом будет обновление паролей учётными записями администраторов.

Отнеситесь к этому как к обычной регулярной проверке безопасности, а не как к реагированию на инцидент. Если бронирования на Вашем сайте всегда требовали входа в систему (или Вы не принимаете бронирований), одного обновления достаточно.

Что я делал и чего не делал

Чтобы быть полностью прозрачным относительно проверки, стоящей за моим письмом: я лишь читал публичные файлы, которые Ваш сайт уже предоставляет каждому посетителю, а именно публичный файл плагина readme.txt и Вашу главную страницу. Я не получал доступ к Вашей административной панели WordPress, Вашей базе данных или какой-либо частной части сайта. В частности, я не касался уязвимого пути бронирования и ничего не тестировал и не эксплуатировал.

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

У меня нет веб-мастера / я застрял

Если Вы не тот человек, который обслуживает сайт, пожалуйста, перешлите эту страницу тому, кто это делает (Вашему веб-разработчику, агентству или хостинг-провайдеру). Они быстро узнают приведённые выше шаги.

Если Вы обслуживаете сайт самостоятельно и застряли, я с радостью бесплатно помогу Вам найти верное направление. Свяжитесь со мной, используя контактные данные ниже.

Контакты

Evan Harris, исследователь безопасности

Я обращаюсь по подобным вопросам исключительно для того, чтобы помочь операторам защитить их сайты. Если Вы предпочитаете, чтобы с Вами больше не связывались, просто сообщите мне об этом, и я это уважу.

Источники

Официальные уведомления и отслеживание

Производитель / плагин