Cross-Site Request Forgery can trigger unauthorized actions in Elementor Website Builder

Cross-Site Request Forgery (CSRF) vulnerability in Elementor Website Builder allows Cross Site Request Forgery. This issue affects Elementor Website Builder: from n/a through 4.3.1.

• Patchstack identifies Elementor Website Builder releases 4.3.0 through 4.3.1 as vulnerable and identifies 4.3.2 as patched.
• The normalized CNA record represents the custom affected range as from n/a through 4.3.1, with default_status set to unaffected and an explicit status change to unaffected at 4.3.2.
• Because the n/a starting value does not define a concrete lower boundary, installed releases should be checked directly; 4.3.0 and 4.3.1 are the concrete vulnerable branch listed by the advisory.
• The reviewed sources do not independently establish whether later or parallel release branches are affected or unaffected.

Elementor Website Builder contains a Cross-Site Request Forgery (CSRF) weakness classified as CWE-352. Patchstack describes the attacker as unauthenticated, but exploitation requires a logged-in user to interact with attacker-controlled content or a crafted request. The victim's browser may then submit an unintended request in the context of the existing WordPress session. The affected action, endpoint, parameters, and exact request-validation defect in Elementor have not been disclosed, so the precise operation that could be abused remains unknown. The supplied assessment describes network reachability, low attack complexity, no attacker privileges, and required user interaction.

The vulnerability is reachable over the network and the attacker does not need to authenticate. Exploitation requires user interaction, such as a logged-in user clicking a malicious link, visiting a crafted page, or submitting a form. The supplied record does not identify a public exploit. The normalized record does not mark known exploitation, and the CISA enrichment displayed with the record marks exploitation as none, but the Patchstack page separately displays a “Known to be exploited! (KEV)” label. Because these source views conflict, the actual exploitation status should be treated as unresolved, and the absence of a public proof of concept should not be treated as evidence of safety.

Successful exploitation could cause a logged-in user to perform an unintended state-changing action. The supplied assessment describes potentially high confidentiality, integrity, and availability impact, but the actual outcome depends on the specific Elementor action exposed by the defect. Scope is assessed as unchanged, so the expected consequences remain within the affected website and the authority processing the request. The reviewed sources do not establish that data was accessed, content was modified, or service was disrupted.

An affected website may accept state-changing requests under the privileges of a logged-in user even though the user did not intend to perform the action. Depending on the affected action, this could result in unauthorized changes to content, configuration, account-related data, or other plugin-managed state. Such changes could create recovery work, disrupt administrative processes, and require review of audit records. The available sources do not identify a specific breach, victim, or confirmed data compromise, so those outcomes should not be assumed to have occurred.

1. Update the WordPress Elementor Website Builder plugin to release 4.3.2, which the CNA and Patchstack identify as patched.
2. If immediate updating is not possible, Patchstack states that it has a mitigation rule to block attacks until the update is completed. Verify that the rule is enabled and applies to every relevant site.
3. After updating, recheck inventory to ensure that affected releases are not still present in production, staging, or restorable backup environments.
4. Do not infer that every later or parallel release branch is safe solely because 4.3.2 is patched. Verify the status of each branch with current vendor information.

1. Inventory WordPress sites that install the elementor plugin and identify the deployed release.
2. Compare each installed release with the affected and patched boundaries in affected_summary and remediation.
3. Review WordPress and Elementor audit logs for unexpected changes to content, configuration, accounts, or plugin state after users accessed external content or submitted forms.
4. Look for cross-site request patterns or user activity that does not match the user's known intent. This is precautionary monitoring, not a confirmed indicator for this vulnerability.
5. Do not treat the absence of suspicious log events as proof that a site is unaffected or was not exploited.