Die Schwachstelle steckt in der Art, wie WordPress die Template-Datei für eine Seite auswählt. Einer der dabei zusammengesetzten Dateinamen stammt aus einem Teil der Web-Adresse. In den betroffenen Versionen wurde dieser Wert nicht durch die eigene Prüfung auf Traversal-Schritte mit ../ geschickt — dieselbe Prüfung, die der benachbarte Code bereits verwendet.
Da der Name nach dem Muster page-{Wert}.php gebildet wird, muss für einen funktionierenden Angriff das aktive Theme einen Ordner auf oberster Ebene besitzen, dessen Name mit page- beginnt; außerdem muss die Zieldatei auf .php enden. Einige Themes, darunter ältere Standard-Themes von WordPress, bringen einen passenden Ordner mit.
Das bloße Laden einer lokalen PHP-Datei führt zunächst nur aus, was diese Datei ohnehin tut. Damit daraus Code nach Wahl des Angreifers wird, braucht es eine zweite Bedingung: Auf dem Server muss bereits eine PHP-Datei liegen, die beim Laden etwas Brauchbares bewirkt. Genau darauf zielt die Einschränkung „auf manchen Servern“ in der Beschreibung von WordPress — vollständige Codeausführung droht eben nicht auf jeder verwundbaren Seite.
Der Sicherheitsanbieter Patchstack nennt in seiner eigenen Analyse zwei Prüfpunkte, an denen Betreiber ihre Gefährdung ablesen können: ob das aktive Theme einen Ordner auf oberster Ebene mit einem Namen hat, der mit page- beginnt, und ob PHP mit der Einstellung register_argc_argv läuft, auf der eine bekannte Technik zur Codeausführung aufsetzt. Beides sei keine Abhilfe, so das Unternehmen, zeige aber, wie nah eine Seite am ungünstigsten Fall liegt. Die Einstellung ist unter PHP 8.5 standardmäßig deaktiviert, in älteren PHP-Versionen dagegen standardmäßig aktiv.
WordPress hat den Fix als Entgegenkommen in jeden noch unterstützten älteren Zweig zurückportiert, hinunter bis Version 4.7.37. Welches Release im Einzelfall einzuspielen ist, hängt vom genutzten Zweig ab; die vollständige Liste steht in den Release Notes.
Stand 22. September lagen keine Berichte über Angriffe vor, es existierte kein öffentlicher Proof-of-Concept-Exploit, und die Lücke war auch nicht im Known-Exploited-Vulnerabilities-Katalog der US-Behörde CISA verzeichnet.
Entdeckt und gemeldet hat die Schwachstelle nach Angaben von WordPress Robert Ressl. The Hacker News hat WordPress und Ressl um eine Stellungnahme gebeten.