If your WordPress site uses Avada Forms, check the Avada Builder version, not only the theme version. A critical vulnerability tracked as CVE-2026-97670 affects Avada (Fusion) Builder 3.16.1 and earlier. It is fixed in 3.16.2. Avada also released theme version 7.16.2 as a security update. Keep the theme and its bundled plugins in step.
The issue matters because a visitor can submit a specially crafted value through an exposed Avada form and make WordPress run an action that the visitor should not control. Wordfence verified that one such action permanently deletes posts, pages, and comments already in the trash. No account is needed for that request. This is not a reason to assume every Avada site has been compromised, but it is a reason to check and update promptly.
What has to be in place
Wordfence describes a specific route: a published Avada form using AJAX submission, with a notification email that includes [all_fields] or an explicit [field] placeholder. These are ordinary form settings, not an exotic custom integration. In affected Builder versions, the form processes a dynamic-data token from submitted field data while preparing the notification. The authorization check does not cover that input path properly, so an unauthenticated visitor can name a WordPress action hook.
The documented proof of impact uses wp_scheduled_delete, a core maintenance action. Triggering it can permanently empty the trash. Wordfence also notes denial-of-service possibilities and further effects if another plugin has an unsafe action handler. The published record does not establish that the attacker can directly read the blind meta output from the form response, so I would not describe this as a general data-exfiltration route.
Check the versions before changing anything
- Open Plugins in wp-admin and find Avada Builder or Fusion Builder. If it is 3.16.1 or older, plan the update now.
- Check the Avada theme version under Appearance → Themes. Avada’s 7.16.2 release contains multiple security fixes, so update the theme too, following Avada’s own update instructions.
- Take a restorable backup, preferably test the update on staging, and make sure the contact form still submits and sends its notification afterwards.
Updating the theme alone is not a reliable check for this CVE. The affected component in Wordfence’s advisory is Avada Builder; confirm it shows 3.16.2 or newer after the update. If your site is on a much older Avada release, use the vendor’s older-version update guidance rather than forcing a large jump without a backup.
If an update cannot happen immediately
Temporarily disabling AJAX submission on the affected Avada form, or removing the notification placeholders named above, removes a required condition for the route Wordfence describes. That is a stopgap, not a substitute for patching. Test the form after any temporary change; a contact form that silently stops delivering leads creates another problem.
If you find unexpected missing trash items or other signs of compromise, preserve logs and backups and involve your host or a qualified incident responder before cleaning files. The advisory confirms a damaging action is possible; it does not prove that every vulnerable site was attacked.
For an ordinary site owner, the decision is simple: check the Builder version, update it to at least 3.16.2 alongside the current Avada theme, test the form, and confirm the versions again. You do not need to understand the dynamic-data internals to make the right call.
Sources: Wordfence vulnerability advisory and Avada’s 7.16.2 security release.