ANALYSIS · e597d722· FINISHED 2026-08-16 · PATCHDIFF

computer-repair-shopcache/computer-repair-shop_4.1132 → cache/computer-repair-shop_4.1133✓ COMPLETED

Files18

Vulnerable14

True positives11

CVE matched1

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

CVE-2026-3567

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 18 CVE 1 Vuln 14

SORT

1 files · page 1/1

lib/includes/main_page.php

AI: 2 vulnerabilities

CVE-2026-3567 1 TP 1 FP

#%!d(float64=009)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-3567

Security writeup for CVE-2026-3567

✓ 1 FILE

## The Exploit

An authenticated user with subscriber-level access or higher can modify any plugin configuration setting—including business name, email, logo, GDPR settings, and payment options—by chaining two AJAX endpoints to forge a valid admin nonce and then submit arbitrary settings.

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

action=wc_rb_get_fresh_nonce&nonce_name=wcrb_main_setting_nonce
```

The attacker receives a fresh, cryptographically valid nonce. They then use it immediately in a second request:

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

action=wc_rep_shop_settings_submission&wcrb_main_setting_nonce_field=<nonce_from_step_1>&business_name=Attacker%20Shop&business_email=attacker@evil.com&business_logo=http://evil.com/logo.png&gdpr_enabled=0
```

The plugin accepts the request and updates `option_business_name`, `option_business_email`, and `option_business_logo` in the WordPress options table. The attacker observes a JSON success response. The next time a customer visits the booking page or receives a confirmation email, they see the attacker's branding and contact information. Critical: the nonce generator `wc_rb_get_fresh_nonce()` is registered with **both** `wp_ajax` and `wp_ajax_nopriv` hooks, so it does not require any authentication at all—but the second-stage function checks the nonce without checking user capabilities, allowing any logged-in user to pass it.

## What the Patch Did

**Before:**
```php
global $wpdb;
$values = array();

if ( ! isset( $_POST['wcrb_main_setting_nonce_field'] ) || ! wp_verify_nonce( $_POST['wcrb_main_setting_nonce_field'], 'wcrb_main_setting_nonce' ) ) {
        $message = esc_html__("Something is wrong with your submission!", "computer-repair-shop");
```

**After:**
```php
global $wpdb;
$values = array();

if ( ! current_user_can( 'manage_options' ) ) {
    wp_send_json_error( array( 'message' => 'Unauthorized' ) );
    wp_die();
}

The patch adds a **`current_user_can( 'manage_options' )` capability check** before any settings are processed. This WordPress API call verifies that the authenticated user has the admin-level `manage_options` capability—a capability granted only to administrator users by default. Without this check, the function relied solely on nonce verification, which proves only that a request came from a form generated on the site, not that the user had permission to modify admin settings.

## Root Cause

**CWE-862: Missing Authorization.**

The entry point is the `wcrb_main_setting_nonce_field` POST parameter, supplied by the attacker in step two. The dataflow is:

1. Attacker generates a valid nonce via `wc_rb_get_fresh_nonce()` (which performs no capability check).
2. Attacker submits the nonce in `wcrb_main_setting_nonce_field` to `wc_rep_shop_settings_submission()`.
3. `wp_verify_nonce()` validates the nonce but does not check user role or capabilities.
4. The function proceeds to call `update_option()` on 15+ plugin options (business_name, business_email, business_logo, etc.), crossing the trust boundary from user input to persistent configuration without authorization.

The vulnerability exists because the developer confused **authentication** (is the user logged in?) with **authorization** (does the logged-in user have permission to modify admin settings?). The nonce proves the request is genuine; it does not prove the user is an administrator.

## Why It Works

The load-bearing line is:

```php
if ( ! current_user_can( 'manage_options' ) ) {
    wp_send_json_error( array( 'message' => 'Unauthorized' ) );
    wp_die();
}
```

If you remove this line and leave only the nonce check, the bug remains fully exploitable. Any authenticated user can still mint a nonce and modify settings.

The engineer added the `wp_die()` call and JSON error response to ensure that the function terminates cleanly and communicates the denial to the client, rather than silently failing or producing ambiguous error messages. The check must execute **before** the nonce verification and **before** any `update_option()` calls—placing it at the top of the function ensures that low-privilege users fail fast, with no possibility of reaching the dangerous code paths.

Defense-in-depth here means: nonce checks alone are insufficient for sensitive operations; capability checks are mandatory. Nonces prevent CSRF; they do not prevent privilege escalation.

## Hardening Checklist

- **Always call `current_user_can()` before sensitive operations.** For admin-only settings, check `current_user_can( 'manage_options' )` at the top of the handler. For shop manager or custom roles, check the appropriate capability. This is not optional for AJAX handlers that modify options or post types.

- **Audit all AJAX handlers registered via `wp_ajax_nopriv`.** This hook allows unauthenticated users to call the handler. If you use `wp_ajax_nopriv`, you must apply stricter input validation and rate limiting. Prefer `wp_ajax` alone for admin-only functions.

- **Separate nonce verification from authorization.** Nonces use `wp_verify_nonce()` or `check_admin_referer()` and prove the request is genuine; capabilities use `current_user_can()` and prove the user is permitted. Always do both checks in the correct order: capability first, then nonce.

- **Use `sanitize_option()` or `sanitize_text_field()` on every option value before `update_option()`.** In this case, `business_email` should pass through `sanitize_email()`, and URLs should pass through `esc_url()`. This prevents stored XSS and injection into configuration files.

- **Log privilege escalation attempts.** When `current_user_can()` fails, log the failed request (user ID, action, timestamp). This enables detection of brute-force attacks on nonce generation.

## References

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

CVE CVE-2026-3567

PRODUCT computer-repair-shop

AFFECTED ≤ cache/computer-repair-shop_4.1132

FIXED IN cache/computer-repair-shop_4.1133

STATUS Generated

Security writeup · CVE-2026-3567

Source files · 1

lib/includes/main_page.php Linked

↗ NVD