Avada Builder EUVD-2026-96051

Requires a published Avada (Fusion) Builder form that uses AJAX submission AND whose notification email_message template includes an [all_fields] or explicit [field] placeholder - the description states this is the default form configuration, so most deployments are exploitable without operator misconfiguration. The attacker supplies a malicious form-field value carrying the {action_hook,...} dynamic-data token, which the public form-submit endpoint parses from $_POST['formData'] - the exact data the is_content_request_supplied() trust gate fails to inspect. Limiting factors: at least one such public form must exist on the target site; destructive impact beyond content deletion/DoS depends on which non-deny-listed hooks are registered, and full privileged writes/RCE require additional vulnerable third-party hook handlers to be installed. The blind meta-read path is further limited because results are delivered only to the site owner and are not attacker-exfiltrable through the plugin's email or response paths.

This is a genuine high-priority issue, not an inflated high-CVSS score. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes network-reachable, low-complexity, fully unauthenticated exploitation with no user interaction, and the C:N/I:H/A:H impact is corroborated by the description's verified unauthenticated permanent deletion of trashed posts, pages, and comments via the core wp_scheduled_delete hook plus denial-of-service via wp_maybe_auto_update. Exploitation works against the default form configuration, which materially raises real-world risk versus a flaw needing non-standard setup. Countervailing signals temper the urgency: no EPSS probability was supplied, the CVE is NOT on CISA KEV, and no public exploit code is referenced, so there is no evidence of current mass exploitation - the finding originates from Wordfence research rather than observed attacks. The CWE-94 (code injection) classification and 'RCE' tag overstate the guaranteed outcome: the description confirms arbitrary action-hook invocation and destructive state changes, but true remote code execution is conditional on vulnerable non-deny-listed third-party hook handlers being installed. Net assessment: treat as critical-to-patch given the unauthenticated, default-config, irreversible-impact profile and Avada's large install base, while recognizing that worst-case RCE is conditional and active exploitation is not yet confirmed.

An unauthenticated attacker locates a public-facing Avada form that uses AJAX submission and a notification template containing an [all_fields] or [field] placeholder (the default configuration), then submits the form via the public endpoint with a formData value carrying the {action_hook,...} dynamic-data token naming a destructive core hook such as wp_scheduled_delete. Because the is_content_request_supplied() trust gate only inspects $_POST['args']/$_GET['args'] and never the formData the submit endpoint actually parses, the hook fires unauthorized, permanently purging trashed posts, pages, and comments. No public exploit code is identified at time of analysis; the low attack complexity and absence of authentication make weaponization straightforward.