CVE-2026-97670: Avada Builder Auth Bypass Vulnerability

CVE-2026-97670 Overview

CVE-2026-97670 is an authorization bypass in the Avada (Fusion) Builder plugin for WordPress affecting all versions up to and including 7.16.1. The plugin dispatches arbitrary WordPress action hooks whose names derive from attacker-supplied form-field values. The trust gate is_content_request_supplied() only inspects $_POST['args'] and $_GET['args'], never the $_POST['formData'] that the public form-submit endpoint actually parses. Unauthenticated attackers can invoke arbitrary non-deny-listed action hooks per request, triggering state changes including permanent deletion of trashed posts, pages, and comments via wp_scheduled_delete. The flaw is categorized under [CWE-94] (Improper Control of Generation of Code).

Critical Impact

Unauthenticated attackers can trigger wp_scheduled_delete to permanently destroy trashed site content and invoke wp_maybe_auto_update for denial of service.

Affected Products

• Avada (Fusion) Builder plugin for WordPress — all versions through 7.16.1
• WordPress sites running a published Avada form with AJAX submission
• Forms whose notification email_message template includes [all_fields] or an explicit [field] placeholder (the default configuration)

Discovery Timeline

• 2026-10-10 - CVE-2026-97670 published to NVD
• 2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-97670

Vulnerability Analysis

The vulnerability resides in the plugin's dynamic-data pipeline used to render notification email templates. When processing an AJAX form submission, the plugin expands {action_hook,...} dynamic-data tokens embedded in [field] or [all_fields] placeholders. The expansion calls do_action() with a hook name supplied by the attacker through the submitted form data.

The plugin includes a trust gate named is_content_request_supplied() intended to restrict this behavior to privileged contexts. The gate inspects $_POST['args'] and $_GET['args'] only. The public form-submit endpoint parses attacker input from $_POST['formData'], which the gate never examines. Unauthenticated requests therefore bypass the check and dispatch arbitrary hooks.

The same pipeline also exposes a blind arbitrary user and post meta read. The read result is routed only to the site owner through the notification email and is not returned to the attacker through plugin response paths.

Root Cause

The root cause is an input-source mismatch between the authorization check and the request parser. The trust gate validates one request surface while the vulnerable code path consumes a different surface. No allow-list constrains the resulting hook name, so any registered action hook not explicitly deny-listed becomes reachable.

Attack Vector

Exploitation requires a target site with a published Avada form configured for AJAX submission and a notification whose email_message template contains [all_fields] or an explicit [field] placeholder. The default form configuration satisfies these preconditions. An unauthenticated attacker submits a crafted formData payload containing a {action_hook,...} dynamic-data token. The plugin invokes the referenced action hook server-side, including wp_scheduled_delete, which permanently removes trashed posts, pages, and comments. Multiple hooks can be invoked per request. Reference: Wordfence Vulnerability Report.

Detection Methods for CVE-2026-97670

Indicators of Compromise

• Unauthenticated POST requests to the Avada form AJAX submission endpoint containing formData fields with {action_hook,...} tokens
• Unexpected invocations of wp_scheduled_delete, wp_maybe_auto_update, or other core action hooks outside their normal cron schedule
• Trashed posts, pages, or comments missing from the site database without a corresponding administrative action in audit logs
• Spikes in admin-ajax.php or Fusion form endpoint traffic from a single source IP with varying payloads

Detection Strategies

• Inspect webserver access logs for POST bodies to Fusion form endpoints containing the substrings {action_hook or [all_fields] from unauthenticated sources
• Correlate WordPress database audit events (post status transitions to deleted) with HTTP requests to the form submission endpoint
• Deploy a Web Application Firewall rule to flag or block requests whose formData parameter contains dynamic-data tokens referencing core hooks

Monitoring Recommendations

• Monitor the installed Avada plugin version across WordPress estates and alert on any instance at 7.16.1 or earlier
• Enable WordPress action-hook logging on sensitive hooks including wp_scheduled_delete and wp_maybe_auto_update and alert on unscheduled firings
• Track the volume of Fusion AJAX form submissions per source IP and alert on anomalous bursts

How to Mitigate CVE-2026-97670

Immediate Actions Required

• Upgrade the Avada (Fusion) Builder plugin to version 7.16.2 or later on all WordPress installations
• Audit database backups and content state to identify any trashed posts, pages, or comments that were permanently deleted during the exposure window
• Restrict unauthenticated access to the Fusion form AJAX endpoint at the WAF or reverse proxy layer until patching is confirmed

Patch Information

ThemeFusion released Avada 7.16.2, which addresses the authorization bypass by validating the correct request surface before dispatching dynamic-data action hooks. Patch details are available in the Avada Security Update 7.16.2 advisory.

Workarounds

• Temporarily unpublish or disable any Avada forms configured for AJAX submission until the plugin is upgraded
• Remove [all_fields] and explicit [field] placeholders from form notification email_message templates to break the dynamic-data expansion path
• Deploy a WAF rule that rejects POST requests to WordPress endpoints containing {action_hook within the formData parameter