Description

The Avada (Fusion) Builder plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 7.16.1. This is due to the plugin not properly verifying authorization before dispatching a WordPress action hook whose name is taken from an attacker-supplied form-field value (via the notification email_message [field] placeholder and the {action_hook,...} dynamic-data token; the 3.16.1 trust gate is_content_request_supplied() only inspects $_POST['args']/$_GET['args'], never the $_POST['formData'] the public form-submit endpoint parses). This makes it possible for unauthenticated attackers to invoke arbitrary WordPress action hooks (multiple per request), causing state changes up to permanent, irreversible destruction of site content: a verified unauthenticated request permanently deleted trashed posts, pages, and comments via the core wp_scheduled_delete action. Other non-deny-listed hooks extend the impact to denial of service (e.g. wp_maybe_auto_update) and, where vulnerable third-party handlers are installed, further privileged writes. The same unauthenticated dynamic-data pipeline additionally exposes a blind arbitrary user/post-meta read; the read result is delivered only to the site owner and is not attacker-exfiltrable through the plugin's own email/response paths. Exploitation requires a published Avada form with AJAX submission and a notification whose email_message template includes an [all_fields] or explicit [field] placeholder - the default form configuration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-10T05:16:40.850Z",
  "pubdate": "2026-10-10T05:16:40.850Z",
  "executiveSummary": "The Avada (Fusion) Builder plugin for WordPress, in versions up to and including 7.16.1, contains a critical authorization bypass vulnerability.\nThis flaw allows unauthenticated remote attackers to trigger arbitrary WordPress action hooks, leading to unauthorized state changes, irreversible data destruction, and potential denial-of-service conditions.\nThe vulnerability stems from an insecure dynamic-data parsing mechanism that fails to validate user-supplied input before dispatching WordPress action hooks.\nExploitation requires a published Avada form configured with AJAX submission and notification settings that process field placeholders.\nImpact includes the ability to execute core functions such as wp_scheduled_delete, which can permanently remove trashed posts, pages, and comments, or trigger resource-intensive tasks like wp_maybe_auto_update.\nAdditionally, the vulnerability exposes a blind meta-read primitive, though exfiltration through the plugin's native notification system is limited.\nGiven the severity of potential data loss and the lack of authentication requirements, this vulnerability presents a high risk to the integrity and availability of affected WordPress installations.",
  "technicalDetails": "The root cause of this vulnerability is improper authorization verification during the processing of dynamic data tokens within the Avada (Fusion) Builder plugin. Specifically, the plugin's dynamic-data parser processes the {action_hook,...} token, which allows for the dynamic invocation of arbitrary WordPress action hooks.\nWhile version 7.16.1 implemented a trust gate via the is_content_request_supplied() function, this check is insufficient as it only validates input from $_POST['args'] or $_GET['args']. It fails to sanitize or inspect the $_POST['formData'] array, which is the primary vector for the plugin's public AJAX form-submission endpoint.\nAttackers can leverage this bypass by crafting a request containing a malicious notification payload. When a user submits an Avada form, the plugin processes the notification's email_message template. If this template contains an [all_fields] or a specific [field] placeholder, the engine parses the {action_hook,...} token found within the submission data.\nBecause the engine does not verify the authorization level of the request or restrict the available action hooks to a safe allow-list, an attacker can supply the name of any registered WordPress action hook. The plugin then proceeds to execute these hooks using do_action().\nThe attack flow involves the following steps: 1) Identification of a public-facing Avada form on the target site. 2) Crafting an AJAX submission request that injects the {action_hook,...} token into a form field that is processed by the notification engine. 3) The backend receives the request and, failing to perform adequate security checks on the contents of $_POST['formData'], executes the attacker-defined action hooks.\nThis vulnerability is highly dangerous as it allows for the invocation of multiple hooks in a single request. By triggering the wp_scheduled_delete action, an attacker can force the permanent deletion of site content that was previously moved to the trash. Furthermore, invoking administrative or maintenance hooks, such as wp_maybe_auto_update, facilitates a denial-of-service attack by forcing the server to process unnecessary, resource-heavy operations.\nBeyond state-changing actions, the vulnerability also provides a blind arbitrary user or post-meta read primitive. Although the results are directed to the site owner via email and are not directly exfiltrable by the attacker, this exposure violates data privacy and could assist in further reconnaissance."
}