Skip to content
Laskyr

CVE-2026-120070: User Frontend privilege escalation vulnerability

high 8.8 published 2026-10-31 · updated 2026-11-02

Fixed in User Frontend 4.3.14 (first release after the affected range)

User Frontend 4.3.13 and older is affected by this privilege escalation issue. Sites on 4.3.14 or newer are not affected; the latest release is 4.3.14.

Affected versions
4.3.13 and older
Fixed in
4.3.14 *
Latest version
4.3.14
Severity
High · CVSS 8.8
Active installs
20,000+
Type
Privilege escalation

* The source does not name a fixed version; this is the first wordpress.org release after the last affected version.

What an attacker needs

CVSS vector (score by Wordfence): CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

What to do now

  1. Update User Frontend to 4.3.14 or newer: Dashboard → Updates, or Plugins → “update now”.
  2. If you cannot update right away, deactivate it until you can.
  3. Turn on auto-updates for it: Plugins → “Enable auto-updates” on its row.
  4. Not sure which version you run? Check your version against every known User Frontend issue. With WP-CLI: wp plugin get wp-user-frontend --field=version.
  5. If you ran an affected version and something looks off (new admin users, spam pages, redirects), run the free scan below.

The advisory

The User Frontend – Membership, User Registration, User Profile, User Directory & Content Restriction with Frontend Post Submission plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.3.13 via the `post_content` parameter of the `submit_post()` function. The vulnerability exists because the protected-shortcode blocklist guard inspects the `sanitize_textarea_field()` copy of the submitted `post_content`, while the copy actually persisted to the database is processed through `wp_kses()`, whose `wp_kses_no_null()` step strips C0 control bytes — allowing an attacker to inject a single `\x01` byte inside the `[wpuf-registration]` tag name to defeat the `strpos()` blocklist check while the clean, functional shortcode is stored verbatim; `strip_shortcodes()` does not neutralize the stored shortcode either, because the Frontend container that registers it via `add_shortcode()` is only instantiated when `is_admin()` is false, and `admin-ajax` requests have `is_admin() === true`. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject a `[wpuf-registration role="editor"]` shortcode into a published post, causing a live Editor-role registration form to be rendered publicly on the frontend that any visitor — or the attacker themselves — can submit to mint a WordPress Editor account with an immediately active privileged session when the default `autologin_after_registration` setting is enabled.

Description from the CVE record, published by Wordfence (the CVE Numbering Authority), via the NVD entry for CVE-2026-120070.

References

Related

Ran an affected version? Check your site for signs of a hack

The free scan reads the public side of your site and looks for spam pages, hidden redirects, injected scripts and blacklist entries. No login, no install, about a minute.

Where this data comes from

First hour checklist

If the site was just hacked, read the emergency kit before you delete files. The page is free. Email is optional.

Read the emergency kit