Avada Theme RCE: Why Patching Just One Half Fails You

On August 25, 2026, ThemeFusion shipped two updates on the same day: Avada 7.16.1 and Fusion Builder 3.16.1. That wasn't a coincidence of release scheduling. CVE-2026-18431, an Avada theme vulnerability with a CVSS score of 9.8, only exists when both products are active on the same site. Update the theme and leave the old plugin in place, or the other way around, and the chain that leads to remote code execution can still be intact.

Wordfence's Alex Thomas, working with the company's Argus research system, found and reproduced the issue on July 30, 2026. Wordfence disclosed it to ThemeFusion on August 5, the vendor acknowledged on August 10, and the fix landed 20 days later. The advisory describes it as arbitrary file write in Avada up to and including version 7.16, present whenever Fusion Builder up to and including version 3.16 is installed and active alongside it. An unauthenticated attacker who reaches the end of the chain can write a PHP file to the server and run it.

Who's exposed: two components, one open question

Two conditions have to be true before this bug matters to you. Avada theme 7.16 or earlier has to be active, and Fusion Builder 3.16 or earlier has to be installed and active alongside it. Fusion Builder is Avada's page-building engine, bundled with the theme and required for most of its layout features, so on the overwhelming majority of Avada sites, it's already there.

Wordfence's advisory adds a third condition: successful exploitation also requires "certain administrator-authored content" to already exist on the site. That phrase appears in the CVE record and in every outlet that has covered this disclosure, and none of them, including Wordfence's own public writeup, spells out exactly what that content is. We looked. We're not going to guess at a specific module, shortcode, or saved layout when the vendor that found the bug hasn't said, because a wrong guess could tell someone running Avada that they're safe when they're not.

What we can say with confidence: don't treat "I don't think I have that content" as a reason to skip the update. The precondition narrows who gets hit by an opportunistic scan, not who's technically vulnerable. Every site running the affected version pair is vulnerable until it's patched.

How the two-part chain works

Wordfence's classification lists this as CWE-862, missing authorization, layered with input validation failures that span both codebases. The advisory describes a chain of several linked weaknesses rather than one missing check, and BleepingComputer's writeup lays out the shape of it: attacker-controlled input enters through a public endpoint that doesn't require login, that input reaches functionality meant to be restricted to higher-privilege users, the request data manipulates state the two components both trust, an administrative file-handling operation processes that state without adequately validating it, and a PHP file with attacker-controlled content ends up written somewhere the web server will execute it.

Each step on its own might pass a routine code review. A public endpoint accepting input is normal. An admin operation that writes files is normal, that's what a page builder does. The vulnerability exists in how the two systems hand data to each other across the boundary between theme and plugin, not in any single obviously broken line.

Why updating only one half isn't enough

This is the detail that gets lost when advisories get summarized down to "update to the latest version." CVE-2026-18431 is filed against both products. Wordfence's vulnerability database lists it under the Avada theme's own advisory page and separately under Fusion Builder's, because the weaknesses that make up the chain live in both codebases, not one.

ThemeFusion's own release announcement for 7.16.1 credits Wordfence and describes the fix as closing "a remote code execution vulnerability in the Fusion Patcher," the theme's built-in mechanism for pushing updates and option changes to installed sites without a full theme reinstall. That's the theme-side half of the chain. The CVE's version ceiling on Fusion Builder, patched separately at 3.16.1, points to the other half sitting in the plugin's own authorization logic.

That's the practical consequence of a cross-component bug: a fix that only touches the theme closes the theme's half of the path and leaves the plugin's half of the path standing, and vice versa. If your update process only tracks one of the two, whichever one gets skipped keeps the chain viable. This is a different failure mode than a typical single-plugin CVE, where updating that one plugin is the entire remediation. Here, remediation is a pair.

Agencies managing client sites on Avada should treat "check the theme version" and "check the Fusion Builder version" as two separate line items, not one. A site can show a current Avada theme version in Appearance > Themes while running a stale Fusion Builder build that was never bundled into the theme's own update package.

How to check both versions and patch

Check both installed versions with WP-CLI in one pass:

wp theme list --fields=name,version,update --search="Avada"
wp plugin list --fields=name,version,status,update --search="fusion-builder"

You need Avada at 7.16.1 or later and Fusion Builder at 3.16.1 or later, with Fusion Builder's status showing active. If either command shows an older version, or shows Fusion Builder installed but inactive when Avada is live, that combination still needs attention: an inactive Fusion Builder isn't part of the exploitable chain, but it's also doing nothing for your site's layout, which usually means something is broken and someone will reactivate it eventually.

Update both from wp-admin if you have an active ThemeForest license connected, or through Appearance > Themes > Add New > Upload Theme for a manually downloaded package. WP-CLI can push the plugin side if it's registered in your update channel:

wp plugin update fusion-builder

There's no configuration workaround here. No admin setting disables the vulnerable path without also disabling functionality Avada sites depend on. Update both.

After patching, check for signs of prior compromise

Patching closes the vulnerability going forward. It does nothing about a file that was already written while the site sat on 7.16 or earlier. Look for PHP files that shouldn't be there:

find wp-content/uploads -name "*.php" -ls
find wp-content/themes/Avada -name "*.php" -newer wp-content/themes/Avada/style.css -ls

Any PHP file inside wp-content/uploads/ is a serious finding on its own; that directory has no legitimate reason to hold executable code. A file inside the Avada theme directory that's newer than your theme's own style.css and wasn't placed there by an official update deserves the same scrutiny.

If either check turns something up, don't stop at deleting the file. A successful arbitrary file write is frequently used to drop a second, quieter foothold, an unfamiliar administrator account, a scheduled cron task, a change to mu-plugins. Our guide on signs a WordPress site has been hacked covers the fuller indicator list, and our PHP backdoors in WordPress piece walks through what these planted files actually look like once they're disguised as something else. If you find anything, follow the WordPress malware removal guide and rotate credentials before you consider the site clean.

Not the same bug as May's Avada Builder disclosure

If Avada sounds familiar from earlier this year, you're not misremembering. Our May 2026 vulnerability roundup covered a different pair of bugs in Avada Builder, CVE-2026-4798 (SQL injection) and CVE-2026-4782 (arbitrary file read), fixed in 3.15.3 and gated behind sites that had WooCommerce active at some point. That's a separate advisory with separate CVE numbers, separate root causes, and a separate patched version line. If you handled that one back in May, it doesn't cover this one. Check your current version against 7.16.1 and 3.16.1 regardless of what you patched five months ago.

Exploitation status

As of this writing, CVE-2026-18431 is not listed in CISA's Known Exploited Vulnerabilities catalog, and no security vendor has published evidence of active exploitation. That can change quickly once technical detail circulates more widely, and a critical unauthenticated file-write bug in a theme with more than a million ThemeForest sales, per Wordfence's own report as cited by BleepingComputer, is exactly the kind of target automated scanners get pointed at once a public writeup lays out the mechanics. Don't wait for a KEV listing to treat this as urgent.

Run a free surface scan to check your installed theme and plugin versions against known vulnerabilities, and set up recurring scans so the next cross-component disclosure doesn't depend on someone remembering to check two version numbers instead of one.

References

• Wordfence Threat Intelligence: Avada <= 7.16 and Fusion Builder <= 3.16 - Unauthenticated Remote Code Execution via Arbitrary File Write
• BleepingComputer: Critical Avada WordPress theme flaw enables zero-click RCE
• Avada: Version 7.16.1 Security Update
• WPScan: Avada <= 7.16 and Fusion Builder <= 3.16 vulnerability detail
• CVEFeed: CVE-2026-18431 detail
• OpenCVE: CVE-2026-18431
• CyberExperts: Critical Avada WordPress theme flaw enables zero-click RCE