Answer in brief
CVE-2026-19991 records a High severity (CVSS 8.1) vulnerability in UsersWP <= 1.2.70 - Authenticated (Subscriber+) Arbitrary File Deletion. The current sources do not mark it as known exploited. The current feed maps stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WP (generic), stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WP (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WP (generic), stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WP (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WPgeneric | >=0 <=1.2.70 | Not reported |
| stiofansisland/UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WPgeneric | 0 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
The UsersWP plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to, and including, 1.2.70 via the upload_file_remove() AJAX handler. The plugin stores the value of an account 'file' form field taken directly from $_POST when no real $_FILES upload is provided (process_account() calls uwp_validate_fields() and array_merges the result with the empty output of UsersWP_Files::validate_uploads()). At storage time the value is only checked with validate_file(), which passes any string that does not contain a literal '../'. When the value is later processed by upload_file_remove(), it is again gated with validate_file() and then normalized through uwp_get_file_relative_url(); that helper performs a global str_replace() 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 wp_delete_file() 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.
Quoted source text, attributed separately from HOL analysis.