ANALYSIS · 0aa97981· FINISHED 2026-06-13 · PATCHDIFF

custom-registration-form-builder-with-submission-manager5.3.0.0 → 5.3.1.0✓ COMPLETED

Files17

Vulnerable11

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-1991

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 17 CVE 1 Vuln 11

SORT

1 files · page 1/1

services/class_rm_user_services.php

AI: 1 vulnerabilities

CWE-862: Missing AuthorizationCWE-352: Cross-Site Request Forgery (CSRF) CVE-2024-1991

#%!d(float64=017)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-1991

Security writeup for CVE-2024-1991

✓ 1 FILE

## The Exploit

An authenticated WordPress user with subscriber-level access (or above) can escalate their own privileges to administrator by calling the vulnerable AJAX endpoint without administrator capabilities being checked.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in=<subscriber_session>

action=rm_update_users_role&rm_sec_nonce=<valid_nonce>&user_id=<attacker_user_id>&user_role=administrator
```

The attacker observes an HTTP 200 response with a success indicator in the AJAX handler output. Upon page reload or login refresh, the attacker's WordPress user account now carries the `administrator` role and can access `/wp-admin/`, create users, install plugins, and modify arbitrary website content.

## What the Patch Did

**Before**
```php
if(check_ajax_referer('rm_ajax_secure','rm_sec_nonce')) {
```

**After**
```php
if(check_ajax_referer('rm_ajax_secure','rm_sec_nonce') && current_user_can('manage_options')) {
```

The patch adds a second security gate: `current_user_can('manage_options')`. The original code validated only the CSRF nonce token via `check_ajax_referer()` — a check that confirms the request originated from an authenticated session and carries a valid token, but does *not* verify that the requester has permission to perform the requested action. The fixed code chains the capability check with a boolean AND operator, ensuring that *both* conditions must be true: the nonce must be valid *and* the user must hold the `manage_options` capability (held only by administrators by default).

## Root Cause

**CWE-862: Missing Authorization** — The `update_users_role()` function modifies user roles, a privileged operation that should be restricted to administrators. The function accepted requests from any authenticated user who could obtain a valid CSRF nonce. The nonce itself (`rm_sec_nonce`, echoed into the page during normal WordPress rendering) is available to all logged-in users, not just admins. The dataflow is: attacker crafts a POST request with parameters `action=rm_update_users_role`, `user_id` (the attacker's own user ID), `user_role=administrator`, and `rm_sec_nonce` (copied from any page the attacker visits while logged in). The request reaches the AJAX endpoint, the nonce is validated, and the role is updated — no capability check ever blocks the attacker.

## Why It Works

The load-bearing line is `current_user_can('manage_options')`. Remove it and the vulnerability remains: the nonce check alone does not enforce privilege separation. `check_ajax_referer()` is not a *capability* check; it is a *session* check — it confirms you are who you say you are, not that you are *allowed* to do what you are asking. The engineer added the `&&` to chain two independent security controls: session/origin validation (nonce) and role-based access control (capability). Only the capability check closes the privilege-escalation path.

## Hardening Checklist

- **Audit all AJAX handlers** — Search your codebase for `check_ajax_referer()` calls not paired with `current_user_can()` or `current_user_can_for_blog()` checks. Use `wp-cli` or grep to find `add_action('wp_ajax_')` and verify each handler enforces a capability gate appropriate to its action.

- **Define a capability matrix** — For every administrative or user-modifying action (role change, user creation, settings update), document which WordPress capability should guard it. Use built-in caps like `manage_options`, `edit_users`, `edit_posts` rather than custom strings; leverage `user_has_cap` hooks if custom roles require special rules.

- **Test as a subscriber** — Reproduce every AJAX-driven user-facing feature logged in as a subscriber. Attempt to modify other users, change settings, or invoke admin-only code paths. If any succeed without error, you have found an authorization bypass.

- **Use `wp_verify_nonce()` with early return** — Never nest nonce verification inside conditional logic. Use the pattern `if ( ! wp_verify_nonce(...) ) { wp_die(); }` followed by your capability check. This prevents logical OR/AND bugs from short-circuiting the security gate.

- **Employ the REST API's `permission_callback`** — If building new AJAX or REST endpoints, register them with an explicit `permission_callback` that returns a `WP_Error` if the user lacks required caps, rather than inlining capability checks into the handler function body.

## References

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

CVE CVE-2024-1991

PRODUCT custom-registration-form-builder-with-submission-manager

AFFECTED ≤ 5.3.0.0

FIXED IN 5.3.1.0

STATUS Generated

Security writeup · CVE-2024-1991

Source files · 1

services/class_rm_user_services.php Linked

↗ NVD