CVE-2026-19991: UsersWP <= 1.2.70 - Authenticated (Subscriber+) Arbitrary File Deletion
The UsersWP plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to, and including, 1.2.70 via the uploadfileremove() AJAX handler. The plugin stores the value of an account 'file' form field taken directly from $POST when no real $FILES upload is provided (processaccount() calls uwpvalidatefields() and arraymerges the result with the empty output of UsersWPFiles::validateuploads()). At storage time the value is only checked with validatefile(), which passes any string that does not contain a literal '../'. When the value is later processed by uploadfileremove(), it is again gated with validatefile() and then normalized through uwpgetfilerelativeurl(); that helper performs a global strreplace() of the uploads base URL against the stored URL, allowing a crafted URL containing embedded '..<uploads-baseurl>' tokens to collapse into '../../' traversal sequences after the last validation. The transformed value is then appended to the uploads base directory and passed to wpdeletefile() without any canonical containment check. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the affected site's server (including wp-config.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs an authenticated WordPress account with at least Subscriber-level access. The issue is therefore relevant where untrusted or low-privilege users can register for or obtain accounts.
What does an attacker need to do to trigger the deletion?
The attacker must supply a crafted value for an account form field of type "file" without providing a real file upload, causing that value to be stored. They can then target the AJAX file-removal handler, using URL manipulation that becomes path traversal after the plugin's URL normalization.
Why do the plugin's file validation checks not prevent exploitation?
The validation rejects literal "../" sequences, but the crafted input can contain embedded uploads-base-URL values instead. A later global replacement of the uploads base URL converts those values into traversal sequences after validation, and the resulting path is deleted without a canonical path-containment check.