User Frontend EUVD-2026-114657

Requires an authenticated WordPress account at Subscriber level or above and the ability to submit a frontend post through the plugin's submit_post() AJAX handler. The core bypass depends on the discrepancy between the blocklist guard (which inspects the sanitize_textarea_field copy) and the persisted copy processed by wp_kses(), whose wp_kses_no_null() step strips the injected C0 control byte (\x01) placed inside the [wpuf-registration] tag name; strip_shortcodes() does not neutralize it because the Frontend container registering the shortcode is only instantiated when is_admin() is false, and admin-ajax requests report is_admin() === true. For the attacker to obtain an immediately active privileged session, the default autologin_after_registration setting must be enabled (it is default-on); if disabled, an Editor account is still created but without the auto-login session. The resulting rendered Editor registration form is submittable by any unauthenticated visitor, but planting it requires the Subscriber-level account. Limiting factors: authenticated Subscriber access needed to inject; the published-post rendering path requires the shortcode to reach a public frontend post; full privileged-session impact is gated on the autologin default remaining enabled. Affected: all versions up to and including 4.3.13.

This is a genuine high-priority privilege-escalation issue rather than a paper-high CVSS. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8, from Wordfence) indicates a network-reachable, low-complexity attack needing only low privileges and no user interaction, with high confidentiality/integrity/availability impact - consistent with CWE-269. The crucial contextual amplifier is that the affected product is itself a frontend user-registration/membership plugin, so the PR:L prerequisite (Subscriber-level access) is frequently trivial to obtain on exactly the sites that run it, effectively lowering the real-world barrier below what PR:L alone suggests. Countervailing signals: no EPSS score was provided, the CVE is NOT on CISA KEV, no SSVC exploitation/automatable/technical-impact decision was supplied, and there is no confirmed working public exploit - the references are a Wordfence advisory, plugin source lines, and the fix changeset, not verified exploit code. The vuln.today decision label is 'this_week' (not act_now/emergency). Net: treat as a real, actionable escalation path to be remediated this week; the exploitation chain is well-documented and mechanically plausible, but there is currently no evidence of in-the-wild exploitation or of packaged exploit code, so this is not an emergency-tier fire.

An authenticated Subscriber submits a frontend post whose post_content carries a [wpuf-registration role="editor"] shortcode with a single \x01 byte injected into the tag name; the blocklist guard inspects the sanitize_textarea_field copy and misses it, while wp_kses_no_null() strips the control byte before storing the clean, functional shortcode. Once the post is published it renders a live Editor-role registration form on the public frontend, which the attacker or any visitor can submit to mint a WordPress Editor account - gaining an immediately active privileged session when the default autologin_after_registration setting is enabled. No verified working public exploit is identified; the mechanism is documented by Wordfence and the plugin source/changeset references.