skrkcb2/cve-2025-0924-differentAnalyse technique de CVE-2025-0924, une vulnérabilité de type Stored XSS dans le plugin WP Activity Log pour WordPress. Comprend une analyse des causes profondes, une démonstration d'exploitation et des conseils de correction.
Le Stored XSS (XSS stocké) est une vulnérabilité où un script malveillant est stocké sur le serveur et exécuté automatiquement lorsque d'autres utilisateurs ouvrent la page concernée. Il s'agit d'un type d'attaque classé sous CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
WordPress est le système de gestion de contenu (CMS) open source le plus populaire au monde, permettant de créer et gérer facilement des sites web et des blogs. Il permet aux utilisateurs d'étendre et de personnaliser leur site via divers plugins et thèmes sans connaissances en codage.
WP Activity Log est un plugin qui suit et enregistre les activités d'administration sur un site WordPress. Il permet aux administrateurs de surveiller en temps réel divers événements sur le site et fournit des journaux utiles pour les audits de sécurité ou la résolution de problèmes.
La CVE-2025-0924 affecte le plugin WP Activity Log (versions 5.2.2 et inférieures) en raison d'un manque de validation des entrées et d'absence d'échappement de sortie sur le paramètre 'message'. Nous allons examiner comment cette vulnérabilité se produit et explorer les mesures de réponse correspondantes.
Dans WordPress, lorsqu'un utilisateur copie et colle un script malveillant dans le titre du site et que ces modifications sont enregistrées dans les journaux via WP Activity Log 5.2.2, une attaque Stored XSS se produit. Nous allons examiner un exemple pour comprendre comment le Stored XSS est déclenché via WP Activity Log.
[Figure 1] Création d'un article WordPress, insertion de script DB
En regardant [Figure 1], on crée d'abord un article pour générer un journal. Dans ce processus, on rédige deux articles : l'un en tapant directement, l'autre en copiant-collant.Après la création de l'article, en vérifiant la base de données, on constate que pour l'article copié-collé, la valeur du champ post_title n'est pas correctement sanitisée (nettoyée et filtrée) et est stockée telle quelle.
Cela suggère que les données peuvent être traitées différemment selon le mode de saisie, ce qui peut être une cause de vulnérabilité XSS.
[Figure 2] Création du journal WP Activity Log et vérification de l'attaque
Les détails de l'article créé dans [Figure 1] sont conservés dans le journal de WP Activity Log. Lors de la récupération des informations de la base de données et de la demande de « More details... », on peut confirmer l'exécution du script de [Figure 2]. 
[Figure 3] class-list-events.php - retour de More details...
Comme on peut le voir dans [Figure 3], « More details... » reçoit AjaxInspector (fonction de rappel ajax / obtenir les métadonnées) et l'occurrence, puis affiche le résultat. 
[Figure 4] AuditLog.php -> AjaxInspector() - pas de sanitisation
[Figure 4] échantillon de métadonnées
L'élément AjaxInspector de [Figure 4], vu dans [Figure 3], renvoie des variables sans les avoir sanitisées lors de la génération du résultat via les métadonnées de [Figure 5], ce qui provoque la vulnérabilité.Nous avons jusqu'à présent examiné le Stored XSS via WP Activity Log, le plugin de journalisation de sécurité de WordPress. Cette vulnérabilité se produit dès qu'il est possible de placer un contenu de script dans la page d'un utilisateur ou dans le journal. Comme mesure de réponse, nous proposons la mise à jour de WP Activity Log de la version 5.2.2 ou antérieure vers la version 5.3.0.
[Figure 5] Modifications d'AjaxInspector / ajout de esc_html()
Dans ce cas, le problème semble provenir du fait que esc_html() n'a pas été utilisé pour sanitizer correctement lors du retour du HTML de résultat. Cependant, je ne suis pas encore certain que cette analyse corresponde exactement à la vulnérabilité décrite dans CVE-2025-0924.
Actuellement, après avoir mis à jour vers la version 5.3.0, j'ai effectué des tests et confirmé que la correction a été appliquée. Cependant, la vulnérabilité décrite dans CVE-2025-0924, Stored Cross-Site Scripting via le paramètre ##message##, se produit via les chemins class-alert.php, class-alert-manager.php.
Or, dans mon analyse, le problème vient des métadonnées et non du paramètre message, et les fichiers PHP concernés sont class-list-events.php et AuditLog.php. Ainsi, mis à part le Stored Cross-Site Scripting, les détails ne correspondent pas à la description du NIST. Par conséquent, une vérification supplémentaire est nécessaire pour confirmer la correspondance exacte.
