Exploitation Research Plan: CVE-2025-13113 (Web Accessibility by accessiBe)

1. Vulnerability Summary

The Web Accessibility by accessiBe plugin (versions <= 2.11) contains an unauthenticated sensitive information exposure vulnerability. The plugin registers a function accessibe_render_js_in_footer() to the wp_footer hook. This function retrieves the plugin's configuration options and outputs them directly into the page's HTML within a <script> tag using console.log().

Crucially, this output is not restricted to administrative users or debug environments. It appears on public-facing pages for any visitor. The logged data includes sensitive configuration parameters such as the owner's email address, accessiBe User IDs, Account IDs, and license information.

2. Attack Vector Analysis

• Endpoint: Any public-facing WordPress page (e.g., the homepage or a post).
• HTTP Method: GET
• Authentication: None (Unauthenticated).
• Preconditions:
  1. The plugin must be active.
  2. The plugin must have been configured with account details (email, IDs).
  3. The vulnerability is specifically noted to trigger when the accessibility widget is disabled in the settings (though it may occur in other states depending on the specific logic in accessibe_render_js_in_footer()).

3. Code Flow

1. Entry Point: The WordPress core triggers the wp_footer hook during the rendering of a frontend page.
2. Hook Registration: The plugin registers the vulnerable function:

   add_action('wp_footer', 'accessibe_render_js_in_footer');
   

3. Vulnerable Sink (accessibe_render_js_in_footer):
   • The function calls get_option('accessibe_settings') (or a similar option name like accessibe_options - inferred).
   • It iterates or directly passes the resulting array into a JavaScript snippet.
   • It echos a <script> block containing:

     console.log(<?php echo json_encode($settings_array); ?>);
     

4. Result: The browser console of any unauthenticated visitor receives a JSON object containing the full plugin configuration.

4. Nonce Acquisition Strategy

No nonce is required. This is a passive information exposure vulnerability. The data is automatically included in the HTML response of public pages.

5. Exploitation Strategy

The goal is to retrieve the HTML of the homepage and extract the sensitive JSON object from the console.log statement.

1. Step 1: Use http_request to fetch the site's homepage.
2. Step 2: Parse the response body to find the <script> tag containing the console.log call.
3. Step 3: Use a regular expression to extract the JSON object within the console.log() parentheses.

HTTP Request:

GET / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0

Extraction Logic (Regex):
console\.log\s*\(\s*(\{.*?"email":.*?\})\s*\)\s*;

6. Test Data Setup

To simulate a real-world scenario, we must populate the plugin settings with sensitive dummy data.

1. Activate Plugin:

   wp plugin activate accessibe
   

2. Set Sensitive Options:
   We need to identify the exact option name. Based on standard naming conventions, it is likely accessibe_settings.

   wp option update accessibe_settings '{"email":"admin-leak@example.com", "user_id":"acsb-user-12345", "account_id":"acsb-acc-998877", "license_key":"ABC-123-XYZ", "is_disabled": "1"}' --format=json
   

   Note: If accessibe_settings is incorrect, check wp option list | grep accessibe.

7. Expected Results

A successful exploit will return the homepage HTML containing a script block similar to:

<script type="text/javascript">
    /* ... other code ... */
    console.log({"email":"admin-leak@example.com", "user_id":"acsb-user-12345", "account_id":"acsb-acc-998877", "license_key":"ABC-123-XYZ", "is_disabled": "1"});
</script>

The presence of the email, user_id, and account_id in the public HTML response confirms the vulnerability.

8. Verification Steps

1. Verify via Browser Simulation:
   Use the browser_navigate tool to go to the homepage and browser_eval to check if the data was logged or exists in a global variable.

   // Attempt to find the data if it was assigned to a variable, 
   // or just check the page source via http_request as primary.
   browser_eval("document.documentElement.innerHTML.includes('admin-leak@example.com')")
   

2. Confirm Data Match:
   Cross-reference the leaked strings with the values set in the Test Data Setup step using wp option get accessibe_settings.

9. Alternative Approaches

If the data is not in the homepage footer:

1. Check Specific Post: Sometimes plugins only load scripts on single posts/pages. Create a post: wp post create --post_status=publish --post_title='Test Page'.
2. Check JS Localization: If the plugin uses wp_localize_script instead of a direct echo in the footer, the data will be found in a global JS variable (e.g., window.accessibe_params).
   • Use browser_eval("window.accessibe_settings") or browser_eval("window.accessibe_params") to check for the object.
3. Check Conditionals: If the leak only occurs when the widget is "disabled", ensure the is_disabled flag is correctly set in the options array. Use wp option get accessibe_settings to verify the structure.