The User Frontend – Membership, User Registration, User Profile, User Directory & Content…

Why it is Yellow

• CVSS 8.8 high

References

• https://plugins.trac.wordpress.org/browser/wp-user-frontend/tags/4.3.13/includes/Ajax/Frontend_Form_Ajax.php#L132
• https://plugins.trac.wordpress.org/browser/wp-user-frontend/tags/4.3.13/includes/Ajax/Frontend_Form_Ajax.php#L253
• https://plugins.trac.wordpress.org/browser/wp-user-frontend/tags/4.3.13/includes/Frontend/Registration.php#L116
• https://plugins.trac.wordpress.org/browser/wp-user-frontend/tags/4.3.13/includes/Frontend/Registration.php#L362
• https://plugins.trac.wordpress.org/changeset/3770255/wp-user-frontend/trunk/includes/Ajax/Frontend_Form_Ajax.php
• https://www.wordfence.com/threat-intel/vulnerabilities/id/f84b6767-f254-45c9-8e78-36d4beac2a98?source=cve

Original description

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.