skrkcb2/cve-2025-0924-differentAnálisis técnico de CVE-2025-0924, una vulnerabilidad Stored XSS en el plugin WP Activity Log para WordPress. Incluye análisis de causa raíz, demostración de explotación y guía de remediación.
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' 파라미터에서 입력 검증 부족과 출력 이스케이프 미비로 인해 발생하며 해당 취약점이 어떻게 발생하는지 살펴보고 이에 따른 대응 방안을 모색 해보고자 합니다.
Stored XSS es una vulnerabilidad en la que un script malicioso se almacena en el servidor y se ejecuta automáticamente cuando otros usuarios abren la página, clasificado como CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
WordPress es el sistema de gestión de contenidos (CMS) de código abierto más popular del mundo, que permite crear y gestionar sitios web y blogs fácilmente. Los usuarios pueden ampliar y personalizar el sitio mediante varios plugins y temas sin necesidad de conocimientos de código.
WP Activity Log es un plugin que rastrea y registra las actividades de administración en sitios WordPress. Es útil para que los administradores monitoreen en tiempo real varios eventos que ocurren en el sitio y proporcionen registros para auditorías de seguridad o resolución de problemas.
CVE-2025-0924 en el plugin WP Activity Log (versiones 5.2.2 e inferiores) ocurre debido a una validación insuficiente de la entrada y una falta de escape de la salida en el parámetro 'message'. Examinaremos cómo ocurre esta vulnerabilidad y exploraremos medidas de mitigación.
WordPress 에서 사용자가 사이트 제목에 악성 스크립트를 복사 붙여 넣고 해당 변경 사항이 WP Activity Log 5.2.2를 통해 로그가 설정 되면 Stored XSS 공격이 이루어 집니다. 예제를 살펴 보며 WP Activity Log를 이용해 어떻게 Stored XSS가 유발 되는지 알아 보겠습니다.
[Figura 1] Creación de entrada de WordPress, inserción de script en BD
[Figura 1]을 보면, 처음 로그 생성을 위해 게시글을 생성합니다. 이 과정에서 두 개의 글을 작성하는데, 하나는 직접 타이핑하여 입력하고, 다른 하나는 복사하여 붙여넣는 방식으로 입력을 진행합니다.게시글 생성 후 데이터베이스를 확인하면, 복사하여 붙여넣은 게시글의 경우 post_title 필드의 값이 적절히 **sanitize(입력 값 정리 및 필터링)**되지 않고 저장되는 현상을 확인할 수 있습니다.
이는 입력 방식에 따라 데이터가 다르게 처리될 가능성을 시사하며, XSS(크로스 사이트 스크립팅) 취약점이 발생할 수 있는 원인이 될 수 있습니다.
[Figura 2] Generación de registro en WP Activity Log y verificación de ataque
[Figura 1]에서 생성한 게시글 내역이 WP Activity Log의 로그로 남아 데이터 베이스에서 정보를 가져와 More details... 를 요청 하는 중 [Figura 2]의 스크립트 실행을 확인 할 수 있습니다. 
[Figura 3] class-list-events.php - retorno de More details...
[Figura 3]에서 보다 시피 More details... 는 AjaxInspector(ajax callback function / get metadata), occurrence를 받아 결과를 출력 합니다. 
[Figura 4] AuditLog.php -> AjaxInspector() - sin sanitizar
[Figura 4] Ejemplo de metadatos
[Figura 3]에서 본 [Figura 4]AjaxInspector 는 [Figura 5]metadata 를 통해 결과 생성 중에 변수를 santize하지 않고 return하여 발생 하여 마무리 됩니다.En WordPress, si un usuario copia y pega un script malicioso en el título del sitio y ese cambio se registra mediante WP Activity Log 5.2.2, se produce un ataque Stored XSS. Veamos un ejemplo para entender cómo se provoca Stored XSS utilizando WP Activity Log.
[Figura 1] Creación de entrada de WordPress, inserción de script en BD
En la [Figura 1], primero se crea una entrada para generar el registro. En este proceso se escriben dos entradas: una se introduce tecleando directamente, y la otra se introduce copiando y pegando.Después de crear la entrada, al verificar la base de datos se puede observar que, en el caso de la entrada copiada y pegada, el valor del campo post_title no se sanitiza (limpieza y filtrado de valores de entrada) adecuadamente y se almacena sin procesar.
Esto sugiere la posibilidad de que los datos se procesen de manera diferente según el método de entrada, lo que puede ser una causa de vulnerabilidad XSS (Cross-Site Scripting).
[Figura 2] Generación de registro en WP Activity Log y verificación de ataque
El historial de la entrada creada en la [Figura 1] queda registrado en WP Activity Log. Mientras se solicitan More details... para obtener información de la base de datos, se puede confirmar la ejecución del script en la [Figura 2].
[Figura 3] class-list-events.php - retorno de More details...
Como se ve en la [Figura 3], More details... recibe AjaxInspector (función de callback ajax / obtener metadatos) y occurrence, y devuelve el resultado.
[Figura 4] AuditLog.php -> AjaxInspector() - sin sanitizar
[Figura 4] Ejemplo de metadatos
El AjaxInspector visto en la [Figura 3] y la [Figura 4] genera el resultado a través de los metadatos de la [Figura 5] sin sanitizar las variables, lo que provoca la vulnerabilidad y concluye el ataque.지금 까지 WordPress 보안 로그 플러그인인 WP Activity Log 를 통하여 Stored XSS를 알아 봤습니다. 해당의 경우는 사용자 페이지 생성 및 로그에 스크립트 내용을 올릴수만 있다면 발생 함으로 대응 방안으로 WP Activity Log 5.2.2버전 이상 -> 5.3.0 업데이트 를 제시하고자 합니다.
[Figura 5] Cambios en AjaxInspector / adición de esc_html()
[Figura 5] Cambios en AjaxInspector / adición de esc_html()
현재 5.3.0 버전으로 업그레이드한 후 테스트를 진행했고, 조치가 이루어진 것을 확인했으나 CVE-2025-0924에서 설명된 취약점 Stored Cross-Site Scripting via the ##message## parameter 을 통해 이루어지며 class-alert.php, class-alert-manager.php를 경로라 명시하지만
현재 저의 분석의 경우 message parameter가 아닌 meta data에서 문제가 되며 과정 중 문제가 되는 경로의 php의 경우 class-list-events.php, AuditLog.php 임으로 nist의 설명과 일치하는 부분은 Stored Cross-Script 빼고 전부 다릅니다. 그러하여 정확한 일치 여부는 추가로 파악이 필요합니다.
En este caso, parece que el problema ocurrió por no sanitizar adecuadamente el HTML de retorno usando esc_html(). Sin embargo, aún no estoy seguro de si este análisis coincide exactamente con la vulnerabilidad descrita en CVE-2025-0924.
Actualmente, después de actualizar a la versión 5.3.0, realicé pruebas y confirmé que la corrección se ha aplicado. Sin embargo, la vulnerabilidad descrita en CVE-2025-0924, Stored Cross-Site Scripting via the ##message## parameter, se produce a través del parámetro ##message## y se mencionan las rutas class-alert.php y class-alert-manager.php,
En mi análisis actual, el problema no está en el parámetro message sino en los metadatos, y los archivos PHP involucrados son class-list-events.php y AuditLog.php. Por lo tanto, aparte de Stored Cross-Site Scripting, todo lo demás difiere de la descripción de NIST. Por lo tanto, se necesita investigación adicional para determinar la concordancia exacta.
