CVE-2026-6127: Elementor Website Builder XSS Vulnerability

CVE-2026-6127 Overview

CVE-2026-6127 is a Stored Cross-Site Scripting (XSS) vulnerability affecting the Elementor Website Builder plugin for WordPress in versions up to and including 4.0.4. The flaw resides in the _elementor_data meta field, which is registered with show_in_rest but lacks a sanitize_callback. Authenticated attackers with contributor-level access or higher can inject arbitrary JavaScript by sending form-encoded PATCH requests to the WordPress REST API. The injected scripts execute in the browser of any user who views the affected page. The vulnerability is classified under CWE-79.

Critical Impact

Contributor-level users can inject persistent JavaScript that executes against site visitors, including administrators, enabling session theft, account takeover, and further site compromise.

Affected Products

• Elementor Website Builder plugin for WordPress, versions through 4.0.4
• WordPress sites permitting contributor-level registrations or higher with Elementor installed
• Sites exposing the WordPress REST API endpoint for post meta updates

Discovery Timeline

• 2026-05-01 - CVE-2026-6127 published to NVD
• 2026-05-01 - Last updated in NVD database

Technical Details for CVE-2026-6127

Vulnerability Analysis

The vulnerability stems from inconsistent sanitization between JSON and form-encoded REST API request bodies. Elementor registers the _elementor_data post meta field with show_in_rest enabled but omits a sanitize_callback. Instead, the plugin relies on a rest_pre_insert_post filter implemented by the sanitize_post_data function. That filter only inspects JSON-encoded request bodies.

When a contributor submits a form-encoded PATCH request, the plugin's json_decode() call on the raw body returns null. The sanitization branch is skipped entirely, and the unsanitized payload is written to the database via update_post_meta(). The data is later rendered without escaping through multiple widget output paths, including the HTML widget's print_unescaped_setting() function.

Root Cause

The root cause is a missing sanitize_callback on the registered REST meta field combined with content-type-dependent sanitization logic. The plugin trusts that all REST traffic carries JSON bodies. Form-encoded requests bypass the filter because json_decode() cannot parse them, leaving stored data unsanitized before it reaches HTML rendering sinks.

Attack Vector

An authenticated attacker with at least contributor permissions sends a PATCH request to a WordPress REST API endpoint that updates _elementor_data. The request uses Content-Type: application/x-www-form-urlencoded with a payload containing JavaScript inside an Elementor HTML widget configuration. The malicious meta is stored on the post and executes when any user, including higher-privileged administrators, views the rendered page.

The vulnerability mechanism is documented in the WordPress Elementor Post Meta Code and the unsafe rendering sink in the WordPress Elementor Widget Base Code. The fix is published in WordPress Elementor Changeset 3519457.

Detection Methods for CVE-2026-6127

Indicators of Compromise

• Unexpected <script>, onerror, or onload strings stored in the _elementor_data post meta within the wp_postmeta table.
• POST or PATCH requests to /wp-json/wp/v2/pages/<id> or /wp-json/wp/v2/posts/<id> with Content-Type: application/x-www-form-urlencoded from contributor accounts.
• New or modified Elementor HTML widgets containing inline scripts that were not authored by trusted editors.
• Browser security alerts or Content Security Policy violations triggered when administrators preview contributor content.

Detection Strategies

• Audit the wp_postmeta table for entries where meta_key = '_elementor_data' and the value contains <script, javascript:, or HTML event handler attributes.
• Inspect web server access logs for REST API write requests carrying non-JSON content types from non-administrator users.
• Compare post revisions to identify Elementor data changes that introduced raw HTML or scripting payloads after a contributor edit.

Monitoring Recommendations

• Enable verbose logging on the WordPress REST API and forward logs to a centralized analytics platform for anomaly review.
• Alert on contributor-role accounts modifying posts via REST PATCH with form-encoded payloads, which is atypical for the Elementor editor.
• Monitor for sudden spikes in outbound requests from administrator browsers, which can indicate XSS-driven session exfiltration.

How to Mitigate CVE-2026-6127

Immediate Actions Required

• Update the Elementor Website Builder plugin to a version newer than 4.0.4 that includes the fix from changeset 3519457.
• Review all contributor and author accounts and remove any that are unused, suspicious, or unnecessary.
• Audit recent post and page revisions for unauthorized HTML widget content and revert affected entries.
• Rotate administrator session cookies and credentials if any compromise indicators are present.

Patch Information

The vendor addressed the issue in the changeset published at WordPress Elementor Changeset 3519457. Additional details and version coverage are available in the Wordfence Vulnerability Intel #826a2003 advisory. Sites running Elementor 4.0.4 or earlier should upgrade immediately.

Workarounds

• Restrict the contributor role from publishing or editing pages that use the Elementor HTML widget until patching is complete.
• Block form-encoded write requests to the WordPress REST API at the web application firewall, allowing only application/json for REST writes.
• Disable open user registration and require administrator approval for any new contributor accounts.
• Apply a Content Security Policy that prohibits inline scripts on rendered pages to reduce the impact of stored XSS payloads.

# Example WAF rule: block non-JSON REST API writes to Elementor meta
# (ModSecurity-style pseudo-rule)
SecRule REQUEST_URI "@beginsWith /wp-json/wp/v2/" \
  "phase:1,deny,status:415,\
   chain,\
   msg:'Block form-encoded WordPress REST writes (CVE-2026-6127)'"
  SecRule REQUEST_METHOD "@rx ^(POST|PATCH|PUT)$" \
    "chain"
    SecRule REQUEST_HEADERS:Content-Type "!@contains application/json"