skrkcb2/cve-2025-0924-differentAnalisi tecnica di CVE-2025-0924, una vulnerabilità XSS memorizzata nel plugin WP Activity Log per WordPress. Include analisi della causa principale, dimostrazione dello sfruttamento e guida alla correzione.
Lo Stored XSS è una vulnerabilità in cui uno script malevolo viene salvato sul server e, successivamente, viene eseguito automaticamente quando altri utenti aprono la pagina interessata. È un tipo di attacco classificato come CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
WordPress è il sistema di gestione dei contenuti (CMS) open source più popolare al mondo e consente di creare e gestire facilmente siti web e blog. Gli utenti possono espandere e personalizzare il sito tramite vari plugin e temi senza bisogno di conoscenze di programmazione.
WP Activity Log è un plugin che traccia e registra le attività amministrative di un sito WordPress. Consente agli amministratori di monitorare in tempo reale i vari eventi che si verificano sul sito e di fornire log utili per l'audit di sicurezza o la risoluzione dei problemi.
CVE-2025-0924 riguarda il plugin WP Activity Log (versioni 5.2.2 e precedenti) ed è causata dalla mancanza di convalida dell'input e dalla mancata escape dell'output nel parametro 'message'. In questo articolo esamineremo come si manifesta questa vulnerabilità e cercheremo di individuare le relative misure di mitigazione.
In WordPress, se un utente copia e incolla uno script malevolo nel titolo del sito e la modifica viene registrata nei log tramite WP Activity Log 5.2.2, si verifica un attacco Stored XSS. Esaminiamo un esempio per capire come WP Activity Log possa causare uno Stored XSS.
[Figura 1] Creazione di un articolo WordPress e inserimento dello script nel DB
Come mostrato nella [Figura 1], per generare i log viene inizialmente creato un articolo. In questo processo vengono scritti due articoli: uno viene inserito digitando direttamente, mentre l'altro viene inserito tramite copia e incolla.Dopo la creazione dell'articolo, controllando il database si può osservare che, nel caso dell'articolo copiato e incollato, il valore del campo post_title viene salvato senza essere adeguatamente sanitizzato (pulizia e filtraggio dei valori di input).
Ciò suggerisce la possibilità che i dati vengano elaborati in modo diverso a seconda del metodo di inserimento e può essere una delle cause dell'insorgere della vulnerabilità XSS (Cross-Site Scripting).
[Figura 2] Generazione dei log di WP Activity Log e verifica dell'attacco
La cronologia degli articoli creati nella [Figura 1] viene registrata nei log di WP Activity Log; durante la richiesta di More details..., che recupera le informazioni dal database, è possibile osservare l'esecuzione dello script mostrato nella [Figura 2]. 
[Figura 3] class-list-events.php - return di More details...
Come si può vedere nella [Figura 3], More details... riceve AjaxInspector (ajax callback function / get metadata) e l'occurrence e restituisce il risultato. 
[Figura 4] AuditLog.php -> AjaxInspector() - non sanitize
[Figura 4] metadata sample
L'AjaxInspector, visto nella [Figura 3] e nella [Figura 4], genera il risultato tramite i metadata della [Figura 5] e, non sanitizzando la variabile durante la restituzione, causa la vulnerabilità, concludendo così il ciclo dell'attacco.Finora abbiamo analizzato lo Stored XSS tramite WP Activity Log, il plugin di log di sicurezza per WordPress. Poiché questo tipo di vulnerabilità si verifica se è possibile inserire contenuti script nella creazione di pagine da parte dell'utente e nei log, come contromisura proponiamo l'aggiornamento di WP Activity Log dalla versione 5.2.2 (e versioni precedenti) alla 5.3.0.
[Figura 5] Modifiche ad AjaxInspector / aggiunta di esc_html()
In questo caso, il problema sembra essere dovuto al fatto che l'HTML di ritorno non è stato adeguatamente sanitizzato utilizzando esc_html(). Tuttavia, non sono ancora certo che questa analisi corrisponda esattamente alla vulnerabilità descritta in CVE-2025-0924.
Sebbene, dopo l'aggiornamento alla versione 5.3.0, abbia effettuato dei test e confermato che la correzione è stata applicata, la vulnerabilità descritta in CVE-2025-0924 si manifesta tramite Stored Cross-Site Scripting via the ##message## parameter e indica come percorsi interessati class-alert.php e class-alert-manager.php;
nella mia analisi attuale, invece, il problema riguarda i metadati e non il parametro message, e i file PHP che risultano problematici durante il processo sono class-list-events.php e AuditLog.php. Di conseguenza, l'unico elemento che corrisponde alla descrizione del NIST è "Stored Cross-Site Script", mentre tutto il resto è diverso. Pertanto, per determinare l'esatta corrispondenza è necessario un ulteriore approfondimento.
