d3kc4rt1/cve-2026-1657Неаутентифицированная произвольная загрузка файлов в плагине EventPrime
Отказ от ответственности: Этот репозиторий создан исключительно в образовательных целях и для этичного раскрытия информации. Уязвимость была ответственно сообщена поставщику и устранена. Не используйте эту информацию для эксплуатации систем без соответствующего разрешения.
В плагине EventPrime для WordPress (версии <= 4.2.8.1) была обнаружена уязвимость неаутентифицированной произвольной загрузки файлов. Этот дефект позволяет любому неаутентифицированному посетителю загружать файлы непосредственно в каталог uploads WordPress и создавать записи вложений в медиабиблиотеке.
Уязвимость существует из-за того, что конкретная AJAX-конечная точка явно зарегистрирована с nopriv (общедоступна) и не имеет ни проверок авторизации, ни надлежащей проверки содержимого файлов. Злоумышленники могут злоупотреблять этой конечной точкой, чтобы вызвать исчерпание дискового пространства, засорить медиабиблиотеку или потенциально загрузить вредоносные полезные нагрузки, замаскированные под изображения.
<= 4.2.8.1Первопричина — сочетание небезопасной регистрации AJAX-хука и недостаточной проверки файлов.
1. Небезопасная регистрация AJAX-конечной точки:
В includes/class-eventprime-event-calendar-management.php плагин регистрирует действие upload_file_media. Примерно в строке 557 он задает {upload_file_media: true} в своей карте действий, где true означает поддержку _nopriv. Следовательно, хук gwp_ajax_nopriv_ep_upload_file_media регистрируется, что делает конечную точку доступной для любого пользователя.
2. Отсутствие проверок авторизации и nonce:
Функция-обработчик upload_file_media() (в includes/class-ep-ajax.php, строки 1659-1697) не использует current_user_can() для проверки привилегий на загрузку и не проверяет security nonce.
3. Ошибочная логика проверки:
Обработчик проверяет только расширение файла (например, jpg/jpeg/png/gif) на основе имени файла, предоставленного клиентом (строки 1661-1664). Он не выполняет надежную серверную проверку содержимого (например, getimagesize() или wp_check_filetype_and_ext()). Это означает, что вредоносные скрипты или другие типы файлов, переименованные в harmless.jpg, будут записаны на диск до того, как WordPress попытается сгенерировать метаданные.
4. Сохранение файла:
Файл сохраняется с помощью move_uploaded_file() непосредственно в wp_upload_dir()['path'], а вложение WordPress создается через wp_insert_attachment().
images) это может привести к удаленному выполнению кода (RCE).1. Подготовьте полезную нагрузку: Создайте образец файла изображения на вашей локальной машине с именем poc.jpg.
2. Выполните запрос: Отправьте POST-запрос multipart/form-data на публичную AJAX-конечную точку без каких-либо сессионных cookie:
curl -i \
-F "[email protected];filename=poc.jpg" \
"http://TARGET_SITE/wp-admin/admin-ajax.php?action=ep_upload_file_media"
3. Просмотрите ответ: Сервер ответит 200 OK и вернет JSON-объект, содержащий идентификатор только что созданного вложения:
{"success":true,"data":{"attachment_id":117}}
4. Проверка:
wp-content/uploads/<year>/<month>/poc.jpg.Чтобы устранить эту уязвимость, разработчики должны:
nopriv, если по замыслу загрузка предназначена только для аутентифицированных пользователей.current_user_can('upload_files'), чтобы гарантировать, что загрузка доступна только авторизованным привилегированным пользователям.check_ajax_referer(), чтобы предотвратить CSRF-атаки.wp_handle_upload()), которые выполняют более строгие проверки MIME-типов и содержимого.