ANALYSIS · b8567d1e· FINISHED 2026-08-23 · PATCHDIFF

custom-registration-form-builder-with-submission-managercache/custom-registration-form-builder-with-submission-manager_6.0.7.6 → cache/custom-registration-form-builder-with-submission-manager_6.0.7.7✓ COMPLETED

Files6

Vulnerable5

True positives2

CVE matched1

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

CVE-2026-32385

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 6 CVE 1 Vuln 5

SORT

1 files · page 1/1

includes/class_registration_magic.php

AI: 1 vulnerabilities

CVE-2026-32385 1 TP

#%!d(float64=001)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-32385

Security writeup for CVE-2026-32385

✓ 1 FILE

## The Exploit

An authenticated WordPress user with subscriber-level permissions or higher can modify the default payment method setting for the entire RegistrationMagic plugin without holding administrative privileges.

```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_options_default_payment_method&rm_sec_nonce=<valid_nonce>&payment_method=paypal_express
```

The server responds with a 200 status and no error message. The attacker then navigates to the RegistrationMagic settings page (or queries the database) and observes that the default payment method has been changed from its original value (e.g., `stripe`) to `paypal_express`. All new user registrations will now attempt to charge via PayPal instead, allowing the attacker to redirect payments or disrupt the site's payment flow.

## 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') || current_user_can('rm_options_managemanage_options'))) {
```

The patch adds a capability check using WordPress's `current_user_can()` function. The original code verified only the AJAX nonce (`rm_sec_nonce`), which proves the request originated from the same site and was not cross-site forged — but proves nothing about who is making the request. The fix enforces that the calling user must possess either the `manage_options` capability (held only by administrators) or the plugin-specific `rm_options_managemanage_options` capability (likely reserved for payment settings managers). Unauthenticated users and low-privilege subscribers now receive an implicit `false` from the conditional and cannot reach the payment method update logic.

## Root Cause

**CWE-862: Missing Authorization**

The AJAX handler `rm_options_default_payment_method()` on line 1223 of `includes/class_registration_magic.php` receives the `payment_method` parameter from the POST request body. The function trusts that `check_ajax_referer()` is a sufficient guard: the nonce proves the request came from the authenticated WordPress session, not a cross-site attacker. However, nonce validation does not verify the caller's role or permissions. Any user who successfully logged in — including a subscriber with no administrative duties — can forge a valid nonce-protected request and reach the sink where the payment method is updated. The trust boundary between "authenticated" and "authorized" was collapsed: the developer conflated CSRF prevention with access control.

## Why It Works

The load-bearing line is `current_user_can('manage_options')`. If this check were removed and only the nonce remained, the vulnerability would persist unchanged. The second capability check, `current_user_can('rm_options_managemanage_options')`, exists for defence-in-depth: it allows the plugin to grant payment-settings access to custom roles without requiring full administrator status. A developer who removes *only* the second check still gains protection from the first. The logical AND operator (`&&`) between nonce and capability ensures both controls must pass; removing either one re-opens the vulnerability. The nonce check is *necessary* to prevent CSRF attacks against administrators, but it is *not sufficient* for authorization — hence the engineer correctly added the capability layer afterward, making the fix resilient to partial removal or misunderstanding.

## Hardening Checklist

- **Audit every AJAX handler for capability checks**: Search `admin-ajax.php` handlers and AJAX actions for `check_ajax_referer()` calls that lack a subsequent `current_user_can()` gate. Use `wp_verify_nonce()` or `check_ajax_referer()` for CSRF only; never assume nonce validation implies authorization.

- **Require explicit capability definition in plugin documentation**: When a function modifies site settings, declare the minimum required capability (`manage_options`, custom caps, etc.) in inline code comments and user-facing docs. This prevents future maintainers from accidentally weakening the check.

- **Use `wp_enqueue_script()` with `wp_localize_script()` to inject nonces**: Nonces passed via hidden form fields or script attributes are easier to audit than hardcoded strings. Centralize nonce generation so a grep for `wp_create_nonce()` reveals all security-sensitive endpoints.

- **Implement unit tests that assert authorization**: For every settings-mutation action, write a test that verifies a subscriber role gets a `403` or auth error, and an admin role succeeds. Use WordPress testing frameworks (`WP_UnitTestCase`) or snapshot tests against mock user roles.

- **Enable WordPress security.txt or plugin security headers**: Publish a security.txt or SECURITY.md file directing researchers to responsible disclosure. Many vulnerabilities in widely-used plugins remain unpatched for months because the vendor has no public security contact.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-32385

CVE CVE-2026-32385

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

AFFECTED ≤ cache/custom-registration-form-builder-with-submission-manager_6.0.7.6

FIXED IN cache/custom-registration-form-builder-with-submission-manager_6.0.7.7

STATUS Generated

Security writeup · CVE-2026-32385

Source files · 1

includes/class_registration_magic.php Linked

↗ NVD