
Технический анализ CVE-2025-0924, уязвимости типа Stored XSS в плагине WP Activity Log для WordPress. Включает анализ первопричины, демонстрацию эксплуатации и рекомендации по устранению.
Stored XSS — это уязвимость, при которой вредоносный скрипт сохраняется на сервере и автоматически выполняется, когда другие пользователи открывают соответствующую страницу; это тип атаки, обозначаемый как CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
WordPress — самая популярная в мире система управления контентом (CMS) с открытым исходным кодом, позволяющая легко создавать и управлять веб-сайтами и блогами. Пользователи могут расширять и настраивать сайт с помощью различных плагинов и тем, не обладая знаниями в области программирования.
WP Activity Log — это плагин для отслеживания и записи действий администраторов на сайте WordPress. Администраторы могут в реальном времени отслеживать различные события, происходящие на сайте, а также получать логи для аудита безопасности и устранения неполадок.
CVE-2025-0924, возникающая в плагине WP Activity Log (версии 5.2.2 и ниже), обусловлена недостаточной проверкой входных данных и отсутствием экранирования вывода в параметре 'message'. Мы рассмотрим, как возникает эта уязвимость, и попытаемся найти соответствующие меры противодействия.
В WordPress, если пользователь копирует и вставляет вредоносный скрипт в название сайта, и это изменение регистрируется через WP Activity Log 5.2.2, происходит атака типа Stored XSS. Рассмотрим на примере, как WP Activity Log может вызвать Stored XSS.
[Рисунок 1] Написание записи в WordPress, вставка скрипта в БД
На [Рисунке 1] показано создание записи для генерации лога. При этом создаются две записи: одна вводится простым набором текста, другая — копированием и вставкой.После создания записи при проверке базы данных видно, что в случае скопированной и вставленной записи значение поля post_title сохраняется без должной санации (очистки и фильтрации входных значений). Это указывает на возможность различной обработки данных в зависимости от способа ввода, что может стать причиной возникновения уязвимости XSS.
[Рисунок 2] Генерация лога WP Activity Log и проверка атаки
Запись, созданная на [Рисунке 1], попадает в лог WP Activity Log; во время запроса More details... из базы данных можно увидеть выполнение скрипта, показанного на [Рисунке 2].
[Рисунок 3] class-list-events.php - возврат More details...
Как видно на [Рисунке 3], More details... использует AjaxInspector (ajax callback function / get metadata) и occurrence, возвращая результат.
[Рисунок 4] AuditLog.php -> AjaxInspector() - без санации
[Рисунок 4] пример metadata
Как показано на [Рисунке 3], AjaxInspector на [Рисунке 4] при формировании результата из metadata на [Рисунке 5] возвращает переменную без санации, что и приводит к уязвимости.До сих пор мы рассматривали Stored XSS через плагин безопасности WordPress WP Activity Log. Этот случай может возникнуть, если есть возможность разместить содержимое скрипта при создании страницы пользователя и в логе. В качестве меры противодействия рекомендуется обновление WP Activity Log с версии 5.2.2 до версии 5.3.0.
[Рисунок 5] Изменения в AjaxInspector / добавление esc_html()
В данном случае проблема, по-видимому, возникла из-за отсутствия правильной санации с помощью esc_html() при возврате результирующего HTML. Однако я пока не до конца уверен, точно ли этот анализ соответствует уязвимости, описанной в CVE-2025-0924.
После обновления до версии 5.3.0 были проведены тесты, и подтверждено, что меры приняты. Однако в CVE-2025-0924 описана уязвимость Stored Cross-Site Scripting через параметр ##message##, а путь указывается через class-alert.php, class-alert-manager.php.
В то же время в моём анализе проблема связана не с параметром message, а с метаданными, а затрагиваемые PHP-файлы — class-list-events.php и AuditLog.php. Таким образом, из описания NIST совпадает только тип уязвимости (Stored Cross-Site Script), а остальное отличается. Поэтому для точного установления соответствия требуется дополнительное исследование.