CVE-2026-8713: Avada Builder Flaw Lets Anyone Delete Your WordPress Files (1 Million Sites at Risk)

If your WordPress site runs the Avada theme, stop reading and check your version right now. A critical flaw in the Avada (Fusion) Builder plugin — tracked as CVE-2026-8713, CVSS 9.1 — lets any unauthenticated attacker delete arbitrary files on your server, including wp-config.php. Once that file is gone, WordPress reverts to its first-time setup screen — at which point the attacker reconfigures your site against a database they control, takes it over completely, and runs whatever code they like. Wordfence publicly disclosed the bug on 2 June 2026; the fix is in Avada Builder 3.15.4. Roughly one million sites were exposed.

Do this in the next 5 minutes

1. Update Avada Builder to version 3.15.4 or later. Plugins → Installed Plugins in WordPress admin, then click "Update Now" on Fusion Builder / Avada Builder.
2. Take a fresh backup of files and database immediately before and immediately after the update — both, so you have a clean rollback point if the update goes sideways.
3. Disable database storage on any Avada Forms you don't actively need it on. Defence in depth, even after patching: if a future bug reintroduces the issue, the cleanup logic has nothing to act on.
4. Check the modification time of wp-config.php. If it's been touched recently and you didn't touch it, treat the site as potentially compromised and follow the IOC section below.

If those four are all you have time for right now, you've done the critical 80% of the response. The rest of this article is for understanding the bug, hunting for prior compromise, and avoiding the next one.

What is CVE-2026-8713?

CVE-2026-8713 is an unauthenticated arbitrary file deletion vulnerability in the Avada (Fusion) Builder plugin — the page builder that ships with one of the most-installed premium WordPress themes on the planet. The flaw was discovered by security researcher daroo through the Wordfence Bug Bounty Program, validated on 15 May 2026, patched by the Avada team on 19 May, and publicly disclosed on 2 June.

Affected and patched versions

Avada Builder version	Status	Action
3.15.3 and earlier	Vulnerable	Update immediately
3.15.4 and later	Patched	No action required (still take a backup)

The headline facts:

• CVSS score: 9.1 (Critical)
• Authentication required: none
• Sites at risk: approximately 1,000,000
• Disclosure: 2 June 2026, via Wordfence
• Reporter: Security researcher daroo, through the Wordfence Bug Bounty Program

How the attack works

The bug sits in the plugin's maybe_delete_files() function, which is responsible for cleaning up files attached to form submissions. The function fails to properly validate the file path it's about to delete, so a relative path containing .. segments — a classic path traversal — can be used to escape the intended directory and target any file on the filesystem.

The attack requires only two things:

• A publicly accessible Avada form on the site — a contact form, a lead form, or any visitor-facing form on the front end.
• That form configured to store submissions in the database — the default for any form set up to keep submissions.

The attacker submits a form entry whose file-attachment path looks like this:

/wp-content/uploads/fusion-forms/../../../wp-config.php

When the plugin's cleanup logic runs, it follows the path traversal up and out of the uploads folder and into the WordPress root, where it deletes wp-config.php. No password, no admin session, no human interaction — the attacker controls the trigger via specific form parameters.

Why deleting wp-config.php is catastrophic

wp-config.php is the file that tells WordPress where its database is, what its keys and salts are, and how to authenticate against it. Delete it and WordPress no longer knows it's installed — visitors hitting the site are served the famous five-minute install screen instead. An attacker who has just deleted your config file is, of course, the first person waiting on that screen. They reconfigure the site to point at their database, become the new "owner" of your WordPress install, and from there can upload PHP, install backdoors, or quietly redirect your traffic. Remote code execution is the realistic endgame.

An attacker can also use the same primitive to delete .htaccess, plugin files, or theme files — whatever harm is most useful to them on a given target.

Who's affected?

Any site running the Avada Builder plugin at version 3.15.3 or earlier, with at least one Avada Form that is publicly reachable and has database storage enabled for submissions. That covers a huge slice of the install base, because Avada Forms is the recommended way to build forms on Avada-themed sites and the database-storage option is on by default for any form set up to keep submissions.

Note that this is the Avada Builder plugin — the page builder that's bundled with the Avada theme. If you run Avada, you almost certainly have it installed.

How to check if your site is vulnerable

1. Log in to your WordPress admin.
2. Go to Plugins → Installed Plugins.
3. Look for "Fusion Builder" or "Avada Builder" and check the version number.
4. If the version is 3.15.3 or lower, you are vulnerable.
5. If the version is 3.15.4 or higher, you are patched.

If you have shell access, you can also check via WP-CLI:

wp plugin get fusion-builder --field=version

How to fix it — right now

1. Update Avada Builder to 3.15.4 or later. The patch is in the official release; no separate hotfix is needed.
2. Take a fresh backup before and after — both of the WordPress files and the database. If anything looks off post-update, you want a known-good restore point.
3. Audit your form storage. If you don't actually need form submissions in the database — many sites just email them — disable database storage on each form. It's defence in depth: even if a future bug reintroduces the issue, there's nothing for the cleanup logic to act on.
4. Check for signs of prior exploitation using the indicators in the next section. Even after patching, a site that was vulnerable for any length of time after disclosure could have been hit.
5. Rotate your database credentials and WordPress salts if you find any evidence of tampering. If wp-config.php was ever deleted and restored, treat the site as compromised until proven otherwise.

Signs your site may have already been hit

If you were running a vulnerable version at any point after public disclosure on 2 June, treat the next checks as mandatory. Exploitation is automated and you cannot assume scanners haven't reached your install yet. Look for any of the following indicators of compromise:

• An unexpected modification time on wp-config.php. Compare it against the file's expected last-touch date:

  stat wp-config.php
  ls -la wp-config.php

  A modification time that doesn't line up with anything you did is a strong signal.
• WordPress showing its install screen unexpectedly to visitors — the famous five-minute install, /wp-admin/install.php, being served where the homepage should be. If anyone has reported this happening, even briefly, treat it as a compromise indicator and start the response process.
• Suspicious entries in your Avada Form submissions table. Query for submissions whose file-attachment paths contain .. sequences or references to anything outside wp-content/uploads/fusion-forms/. For example, in your database client:

  SELECT * FROM wp_fusion_form_entries
  WHERE entry_data LIKE '%..%'
     OR entry_data LIKE '%/wp-config.php%'
     OR entry_data LIKE '%/.htaccess%';

  Adjust the table name to match your prefix.
• Missing or recreated files in the WordPress root — .htaccess, wp-config.php, or sensitive plugin and theme files unexpectedly absent or replaced.
• Unfamiliar admin users, new scheduled tasks, or PHP files in wp-content/uploads/. These would indicate the attacker proceeded past the file-deletion primitive into a full takeover.

If any of those check out as a real compromise indicator, do not try to clean the site in place. Restore from a known-good off-site backup taken before the suspect window, rotate database credentials, regenerate the WordPress salts in your new wp-config.php, and force a password reset for every admin user. Then have someone whose day job is incident response look over the site before declaring it clean.

Why this keeps happening

The "site got hacked because of an outdated plugin" story isn't dramatic, but it's the actual reason most small business WordPress sites get compromised. Security teams across the industry block millions of automated exploit attempts against plugin vulnerabilities every day. The window between a vulnerability being publicly disclosed and being mass-exploited in the wild is now measured in hours, not weeks.

For a managed site, this is a non-event: the plugin updates within hours of the patch being released, the site stays clean, life continues. For an unmanaged site it's the start of a very expensive bad week — and unlike a phishing email, you don't get to choose whether you participate. Bots crawl the WordPress install base looking for vulnerable versions of every plugin disclosed that month. If yours is one of them, you're getting hit. Full stop.

The fix isn't paranoia or panic. It's keeping plugins up to date, following the right advisories (Wordfence, Patchstack, WPScan), backing up off-site, and having someone — yourself, your dev team, or a provider — who treats "a critical CVE just dropped in a plugin we use" as a notification they actually act on within the day. Most small businesses don't have that, and that's the bet attackers are making.

Frequently asked questions

Do I need to patch this even if I'm not using Avada Forms on the site?

Yes — patch it. The Avada Builder plugin is the carrier; even if you've removed the visible forms, having the vulnerable code on disk is still a risk. Updates are the cleanest defence. If you really cannot update right now, removing or deactivating Avada Builder until you can update is the next-best option.

What is the patched version of Avada Builder?

3.15.4, released on 2 June 2026. Any version 3.15.4 or later contains the fix.

How can I tell if my site has already been attacked?

Three things to look for: whether wp-config.php has been modified or recreated recently, whether your form-submissions table contains entries with suspicious file-path values (anything containing .. or paths outside the uploads folder), and whether the WordPress site has ever displayed the "first-time setup" screen unexpectedly. If any of those are yes, treat the site as potentially compromised — restore from a clean off-site backup, rotate database credentials and salts, and have someone audit the install before declaring it safe.

Is the Avada theme itself vulnerable, or just the plugin?

The vulnerability is in the Avada Builder plugin (sometimes referred to as Fusion Builder), which ships alongside the Avada theme. The theme itself isn't the immediate attack vector, but in practice the two are installed together on virtually every Avada-themed site. Update the plugin to 3.15.4 or later.

Is this being exploited in the wild?

Mass-exploitation activity against unpatched WordPress plugins typically begins within days of public disclosure, and automated bots index vulnerable installs at scale. Treat the patch window as closed: assume scanners already know about it and act accordingly.

What is the CVSS score and severity?

CVE-2026-8713 carries a CVSS v3.1 score of 9.1, which is in the Critical severity band. Severity is driven by the combination of unauthenticated access (no login required), remote exploitation (no need for local access), and a realistic path from the bug itself to full site takeover via wp-config.php deletion.

Sources and references

• Wordfence — Critical Unauthenticated Arbitrary File Deletion Vulnerability Patched in Avada Builder (primary disclosure)
• CIRCL Vulnerability-Lookup — CVE-2026-8713
• Cybersecurity News — Critical WordPress Plugin Vulnerability Exposes 1 Million Sites to File Deletion Attacks