Your website was built in 2019 by an agency you stopped working with in 2022. It runs on a commercial WordPress theme the agency chose, bought and installed. Somebody on staff logs into the dashboard most weeks, applies whatever updates are offered, and the site has been fine. Nobody has ever asked where the license for that theme lives, because nothing has ever required an answer.
On August 26 the makers of Avada, one of the most widely sold commercial WordPress themes ever released, published a patch for a flaw that lets an unauthenticated attacker write files to your server and run code on it. If your site is registered, the update appears in your dashboard like any other. If it is not, the dashboard will not mention it, and the site will keep telling you everything is up to date.
What Was Patched
CVE-2026-18431 is rated CVSS 9.8. It affects the Avada theme up to and including version 7.16 and the Fusion Builder plugin up to and including 3.16, and it is fixed in Avada 7.16.1 and Fusion Builder 3.16.1, both released August 26. No login is required to exploit it and no administrator has to click anything, which is why the coverage described it as zero-click.
The vendor's handling of it deserves saying plainly, because vendor behavior is one of the few things you can actually evaluate before you buy: the report reached ThemeFusion on August 10 and a patch existed the following day, with public disclosure held back roughly two weeks. That is the sequence you want.
One more detail is worth noting for what it implies rather than for what it fixes. Wordfence says the issue was found by its automated analysis system, which produced working proof-of-concept code in about two hours. Whatever you think of the marketing around that, the direction is not ambiguous. The interval between a flaw existing in shipped code and somebody having a working exploit for it is getting shorter, and it is getting shorter faster than most association update cycles are getting quicker.
Why This One Is Different From a Plugin Update
Free plugins from the WordPress directory update through a channel that does not care who you are. Commercial themes and plugins do not work that way. Avada requires product registration with a purchase code for one-click updates from the dashboard, which is a normal and reasonable commercial arrangement, and it creates a failure mode that is specific to organizations rather than to individuals.
The failure mode is this: the purchase code belongs to whoever bought it. In an association that is very often the agency that built the site, on an account with an email address at that agency's domain, tied to a person who may no longer work there. The site keeps running perfectly. It simply stops being offered updates, quietly, with no error and no notice, and the gap only becomes visible on a day like August 26.
This is not a complaint about commercial licensing. Paid themes are supported themes, and the money buys the patch that shipped in a day. It is a governance observation: a piece of your security depends on an account you may not control, and almost nobody has that written down.
The Check, in About Fifteen Minutes
Four steps, and the first three need nothing but a dashboard login:
- Read your theme version. Appearance, then Themes. If it says Avada, note the number. 7.16.1 or higher is patched. Anything at or below 7.16 is not.
- Read the Fusion Builder version separately. It appears in the plugin list, and it has its own number. Both halves need to be current, 3.16.1 or higher, because the flaw spans the pair.
- Look at whether the site is registered. Avada shows registration status in its own dashboard section. If it is unregistered, the absence of an available update tells you nothing about whether one exists.
- Find out who holds the license. The purchase code, the account it sits in, the email address on that account, and whether the support period is current. If the answer is that a former vendor holds all four, that is the finding, and it applies to every future patch, not just this one.
If you are on an affected version and cannot update because nobody has the license, the correct answers are to recover the purchase code from the original buyer, or to buy a license in the association's own name. The incorrect answer, which is genuinely common and worth naming, is to download a copy of the theme from a site offering it free. Those copies routinely carry the thing you were trying to avoid.
What to Do If the Version Was Old for a While
A patch stops the flaw from being used again. It does not answer whether anything happened before you applied it, and with an arbitrary file write the honest answer is that you cannot tell from the dashboard. Three things are worth checking, in order:
- New or modified PHP files in the uploads directory. Nothing in that folder should be executable code. A .php file sitting among the images is the classic signature of a file-write flaw being used.
- Administrator accounts you cannot name. Users, filtered to administrators. Every one of them should map to a person you can call.
- Scheduled tasks nobody scheduled. A compromise that survives cleanup usually survives through a cron entry that puts the files back. This is the point where a maintenance provider or a security vendor earns the fee.
About That Install Base
Coverage of this flaw repeated a figure worth handling carefully: Avada has sold more than a million licenses. That is a sales total on a marketplace, not a count of live sites, and the two differ by every site that was rebuilt, abandoned or never launched. Nobody publishes the real number.
The scale still matters, for a specific reason. A flaw in a theme this widely sold is worth automating an attack against, because the attacker does not have to find your association. They scan for the theme and your site answers. Popularity is not a security property in either direction. It buys you a vendor who patches in a day, and it buys everyone else a target list.
If You Are Not on Avada
Then this advisory is not yours. The license question is, because it applies to every commercial component on your site, and most association sites have several: a page builder, a forms plugin, a custom fields plugin, a caching plugin, a slider nobody has looked at since launch. For each one, the question is the same and it takes a spreadsheet rather than a developer: what is it, who bought it, whose email is on the account, when does the support period end, and does the site currently receive updates for it?
That inventory is dull and it is the single highest-value hour of website governance work available to most associations. It converts an invisible dependency into a line item somebody owns.
Have Us Inventory Your Licenses
Give us access to your dashboard, or a list of what is installed. You will get back a written page: every commercial theme and plugin on the site, the version you are running against the current release, whether the site is registered to receive updates for each one, who appears to hold the license, and which of them have open security advisories right now. If everything is current and every license sits in your association's own account, that is what the page will say, and it is worth having before the next patch you are not offered.