skrkcb2/cve-2025-0924-differentTechnische Analyse von CVE-2025-0924, einer gespeicherten XSS-Schwachstelle im WP Activity Log Plugin für WordPress. Enthält Root-Cause-Analyse, Demonstrationsbeispiel zur Ausnutzung und Anleitung zur Behebung.
Stored XSS ist eine Schwachstelle, bei der ein bösartiges Skript auf dem Server gespeichert wird und später automatisch ausgeführt wird, wenn andere Benutzer die entsprechende Seite öffnen. Sie ist als CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) klassifiziert und gehört zu einer Art von Angriffen.
WordPress ist das weltweit beliebteste Open-Source-CMS (Content-Management-System) und ermöglicht es, Websites und Blogs einfach zu erstellen und zu verwalten. Benutzer können die Website ohne Programmierkenntnisse über verschiedene Plugins und Themes erweitern und anpassen.
WP Activity Log ist ein Plugin, das Verwaltungsaktivitäten von WordPress-Websites verfolgt und protokolliert. Es ist nützlich für Administratoren, um verschiedene Ereignisse auf der Website in Echtzeit zu überwachen und Protokolle für Sicherheitsaudits oder Problemlösungen bereitzustellen.
CVE-2025-0924 tritt im WP Activity Log Plugin (Version 5.2.2 und niedriger) aufgrund unzureichender Eingabevalidierung und fehlender Ausgabe-Escape im Parameter 'message' auf. Wir möchten untersuchen, wie diese Schwachstelle entsteht, und entsprechende Gegenmaßnahmen suchen.
Wenn ein Benutzer in WordPress ein bösartiges Skript in den Site-Titel kopiert und einfügt und diese Änderung über WP Activity Log 5.2.2 protokolliert wird, erfolgt ein Stored-XSS-Angriff. Anhand eines Beispiels werden wir untersuchen, wie Stored XSS mithilfe von WP Activity Log ausgelöst wird.
[Abbildung 1] WordPress Beitragserstellung, DB-Skript-Einfügung
Wie in [Abbildung 1] zu sehen, wird zunächst ein Beitrag erstellt, um ein Protokoll zu erzeugen. In diesem Prozess werden zwei Beiträge verfasst: einer wird direkt per Tastatureingabe eingegeben, der andere durch Kopieren und Einfügen.Wenn man nach der Beitragserstellung die Datenbank überprüft, kann man feststellen, dass bei dem kopierten und eingefügten Beitrag der Wert des post_title-Feldes nicht ordnungsgemäß sanitize (Bereinigung und Filterung von Eingabewerten) gespeichert wird.
Dies deutet darauf hin, dass Daten je nach Eingabemethode unterschiedlich verarbeitet werden können und eine Ursache für XSS-Schwachstellen (Cross-Site Scripting) sein kann.
[Abbildung 2] WP Activity Log Protokollerstellung und Angriffsprüfung
Der in [Abbildung 1] erstellte Beitragsverlauf bleibt als Protokoll in WP Activity Log erhalten. Während die Daten aus der Datenbank abgerufen und eine Anforderung an "More details..." gesendet wird, kann man die Skriptausführung in [Abbildung 2] feststellen. 
[Abbildung 3] class-list-events.php - More details... return
Wie in [Abbildung 3] zu sehen, gibt "More details..." die Ergebnisse aus, nachdem es AjaxInspector (ajax callback function / get metadata) und occurrence empfangen hat. 
[Abbildung 4] AuditLog.php -> AjaxInspector() - non sanitize
[Abbildung 4] metadata-Beispiel
Der in [Abbildung 3] gesehene AjaxInspector aus [Abbildung 4] gibt während der Ergebnisgenerierung über die [Abbildung 5]-Metadaten Variablen ohne Sanctize zurück, was die Schwachstelle auslöst.Bisher haben wir uns Stored XSS anhand von WP Activity Log, einem WordPress-Sicherheitsprotokoll-Plugin, angesehen. Da dieser Fall auftritt, sobald ein Skriptinhalt in die Benutzerseitenerstellung und in Protokolle eingebracht werden kann, möchten wir als Gegenmaßnahme das Update von WP Activity Log 5.2.2 oder niedriger auf Version 5.3.0 vorschlagen.
[Abbildung 5] AjaxInspector-Änderungen / esc_html() hinzugefügt
In diesem Fall scheint das Problem dadurch verursacht worden zu sein, dass beim Zurückgeben des Ergebnis-HTML nicht ordnungsgemäß mit esc_html() bereinigt wurde. Ob diese Analyse jedoch exakt mit der in CVE-2025-0924 beschriebenen Schwachstelle übereinstimmt, ist noch nicht vollständig sicher.
Nach dem Upgrade auf Version 5.3.0 wurden Tests durchgeführt und die Behebung bestätigt. Die in CVE-2025-0924 beschriebene Schwachstelle wird als Stored Cross-Site Scripting über den Parameter ##message## ausgeführt und gibt als Pfade class-alert.php und class-alert-manager.php an.
In meiner aktuellen Analyse liegt das Problem jedoch nicht im message-Parameter, sondern in den Metadaten. Die während des Prozesses betroffenen PHP-Dateien sind class-list-events.php und AuditLog.php. Somit stimmt nur der Teil "Stored Cross-Site Scripting" mit der Beschreibung von NIST überein, der Rest unterscheidet sich vollständig. Daher ist eine weitere Untersuchung erforderlich, um die genaue Übereinstimmung festzustellen.
