Six Critical WordPress Flaws Landed in Three Weeks. Here Is What You Actually Do.

By Cody Wise, Founder, Wise Media. Published 1 September 2026.

Between 31 July and 27 August 2026, six separate critical vulnerabilities were patched in WordPress plugins and themes that ordinary small business sites are built from. All six are unauthenticated, meaning an attacker needs no account and no password. If you run a WordPress site, your entire job today is to check six version numbers, check your administrator accounts, and check one folder.

Summary

• Six critical flaws, three weeks. WPMU DEV Dashboard, Avada with Fusion Builder, TranslatePress, Pods and GiveWP were disclosed together on 29 August. Forminator was patched a month earlier and drew renewed attention in the same window.
• Five are rated CVSS 9.8. One, GiveWP, is rated 10.0. All are exploitable without logging in.
• The fix is a version number, and the full table is below. Most sites need nothing else.
• The trap is licensing. Avada and Elementor Pro are commercial products. If the licence was never registered on the site, or was registered to someone who has since left, the update button does not work and no host can push the patch for you.
• A version check alone is not proof you are clean. TranslatePress and Pods both lead to administrator takeover rather than file upload, so you also need to check the user list for accounts you did not create.
• Canadian bilingual sites are disproportionately exposed. TranslatePress is the default translation tool on English and French builds, and the vulnerable configuration is the one an agency sets up by default.

Table of contents

1. What actually happened in August 2026
2. The version table: am I affected?
3. What each flaw actually requires to work
4. The licence trap that stops the update button working
5. Check for administrator accounts you did not create
6. What to do if the audit actually finds something
7. Why the patch reached you later than it should have
8. Common mistakes
9. Frequently asked questions
10. The bottom line

What actually happened in August 2026?

On 29 August 2026, The Hacker News published a roundup of five critical WordPress vulnerabilities disclosed by Wordfence and Patchstack across the preceding fortnight. A sixth, in the Forminator forms plugin, had been patched on 31 July and resurfaced in coverage during the same period. A seventh, in Elementor Pro, was patched on 19 August and is serious enough to warrant its own separate runbook.

What makes this cluster different from an ordinary month of WordPress advisories is not the count. It is the layer. These are not obscure plugins with four hundred users. They are the premium page builder, forms, translation, custom-fields and donations layer that a small business WordPress site is literally made of. Between them, the affected products run on well over a million sites.

Several were found by automated systems. Wordfence has been running an AI research agent called Argus, and it is credited in the WPMU DEV, Avada and TranslatePress advisories. That matters for one practical reason: the rate of critical disclosures against commercial WordPress components is going up, not down, and a maintenance habit built for four advisories a year will not survive four in a fortnight.

The version table: am I affected?

This is the whole audit. Open your WordPress dashboard, go to Plugins, and read the version number under each name. For Avada, go to Appearance then Themes. Compare against the “Fixed in” column. If your number is equal to or lower than the “Vulnerable” column, update.

Component	Vulnerable versions	Fixed in	CVE	CVSS
GiveWP	up to and including 4.16.7.1	4.16.7.2 (27 Aug 2026)	CVE-2026-82222	10.0
Avada theme with Fusion Builder	Avada up to 7.16 and Fusion Builder up to 3.16	Avada 7.16.1 and Fusion Builder 3.16.1 (25 Aug 2026)	CVE-2026-18431	9.8
WPMU DEV Dashboard	up to and including 5.0.1	5.0.2 (24 Aug 2026)	CVE-2026-76581	9.8
Pods, Custom Content Types and Fields	up to and including 3.3.9	3.3.9.1 (14 Aug 2026), plus backports to older branches	CVE-2026-19598	9.8
TranslatePress	up to and including 3.3.1	3.3.2 (13 Aug 2026)	CVE-2026-19632	9.8
Forminator Forms	up to and including 1.56.1	1.56.2 (31 Jul 2026)	CVE-2026-15748	9.8
Elementor Pro (separate incident)	up to and including 4.2.1	4.2.2 (19 Aug 2026)	CVE-2026-32475	9.0

Two notes on reading this table. First, the Avada row needs both updates. Patching the theme and leaving Fusion Builder behind does not close the chain. Second, the Pods row is the one most commonly written down wrong: the fix is 3.3.9.1, a point release above the vulnerable 3.3.9, not a jump to 3.4. Pods also backported the fix across five older branches going back to version 2.8, so a site deliberately held on an older major version has a patch available too.

How big are these numbers, in plain language?

CVSS is a 0 to 10 severity score. Anything from 9.0 up is “critical”. In practice, for a site owner, the distinction that matters is not 9.8 versus 10.0. It is this: every flaw in the table above is unauthenticated. An attacker does not need a stolen password, a compromised staff account, or a phishing email that works. They need your web address.

GiveWP earns its 10.0 because the chain requires nothing at all beyond a site that is doing what GiveWP is installed to do: one published donation form and one active payment gateway. GiveWP is a charity donations plugin. The sites running it are the ones least able to absorb a compromise.

What does each flaw actually require to work?

Every ranking write-up lists the CVEs. Almost none tells you the precondition, which is the thing that decides whether you are actually exposed or merely running the software. Update regardless, because preconditions are read from advisories and advisories get revised. But this is what the researchers published.

• GiveWP (CVE-2026-82222). One published donation form and one active payment gateway. Patchstack describes the chain as a broken “safe unserialize” helper, a donation flow that feeds it attacker-controlled data, and a gadget chain in code GiveWP already ships.
• Avada plus Fusion Builder (CVE-2026-18431). Both must be installed and active in vulnerable versions, and certain administrator-authored content must already exist on the site. Wordfence chained six separate weaknesses to get from unauthenticated request to arbitrary file write to remote code execution.
• WPMU DEV Dashboard (CVE-2026-76581). Only sites connected to WPMU DEV with Hub Single Sign-On enabled and mapped to an administrator. If you have never used Hub SSO, this one is unlikely to reach you. Update anyway.
• Pods (CVE-2026-19598). No special configuration published. This is the broadest of the six. The plugin’s admin AJAX router funnelled every access check through an error function that, on one compatibility path, logged the failure and let execution continue instead of stopping it. The result is that an unauthenticated request could reach administrator-level functions, including one that overwrites any user’s password.
• TranslatePress (CVE-2026-19632). Two conditions together: automatic string saving enabled, and the target administrator’s own profile locale set to a published secondary language on the site. An unauthenticated request could then extract the raw administrator password-reset URL, reset key included.
• Forminator (CVE-2026-15748). A form containing both a File Upload field and a Select field. Insufficient file-type validation then allowed an attacker-controlled upload configuration through the extension blocklist.

The Canadian bilingual build nobody has connected

Read the TranslatePress precondition again, and then think about how a Canadian bilingual site actually gets built.

Quebec’s Charter of the French Language amendments and Law 25 have pushed a steady stream of Canadian businesses into English and French builds over the last three years. TranslatePress is one of the default tools for that job. Automatic string saving is on by default, because turning it off makes the plugin tedious to use. And when an agency builds a French site, setting the administrator’s own profile locale to French is a normal thing to do, because it is how you check the French side looks right.

That is the vulnerable configuration, arrived at by doing the job properly. If you commissioned a bilingual build on WordPress in the last three years, treat TranslatePress as the first version number you check, not the last.

The licence trap that stops the update button working

Here is the part that turns a ten minute job into a two week problem, and it is the reason some sites will still be unpatched at Christmas.

Free plugins from the WordPress.org repository update themselves, and a decent host can push those updates for you. Commercially licensed products cannot be updated that way. Avada, Fusion Builder and Elementor Pro are all commercial. They check a licence or a registration token before they will pull an update, and if that check fails, the update simply does not appear. There is no warning banner that says “you are now unpatchable”. The button is just quietly absent or inert.

Three ways a site ends up in that state, all of them ordinary:

1. The licence belongs to an agency you no longer work with. The site was built on the builder’s licence, handed over, and nobody transferred the key. It kept working, because the site does not stop working. It just stopped updating.
2. A subscription lapsed. Elementor Pro is an annual subscription. When it lapses the site keeps rendering perfectly and updates stop.
3. The theme was never registered. Avada is a one-time purchase through ThemeForest that has to be registered in the dashboard with a valid purchase token before it will pull automatic updates. Support periods on ThemeForest purchases also lapse and can be extended, which is a separate thing from the update path. A site handed over without registration receives nothing.

Check licence status at the same time as version number, on every site, today. On a lapsed or unregistered commercial product your options are to renew or register, or to apply the update manually by replacing the plugin or theme files. If your site is on Avada or Elementor Pro and you cannot find the licence, that is a real problem with a real deadline, and it is worth getting help with rather than leaving. Our website growth and care packages exist substantially because of this failure mode.

This is also the single best argument for the ownership audit we recommend to anyone changing suppliers. If you cannot name who holds the licence for every commercial plugin on your site, you do not fully control your own website.

Check for administrator accounts you did not create

This is the step that separates a real audit from a version check, and it is missing from almost every article written about this cluster.

Four of these flaws end in file upload or code execution. But TranslatePress and Pods both end in administrator takeover. The attacker does not drop a file you can find. They take a legitimate account, or make one. Updating the plugin closes the door. It does not remove anyone already standing inside.

So after you update, do this:

1. Go to Users and filter by Administrator. Read every single one. You are looking for accounts you cannot account for, accounts with unfamiliar email domains, and accounts registered recently.
2. Check the registration date column. If an administrator account appeared in August 2026 and you did not create it, treat the site as compromised rather than clean.
3. Force a password reset on every remaining administrator account, and remove administrator rights from anyone who does not need them. Most sites have two or three more admins than they need.
4. Look in wp-content/uploads/, and specifically in the forms subfolders, for any .php file or any file type your forms do not accept. Uploads folders should contain images and documents, not code.
5. Check that scheduled tasks, users and site settings still look the way you left them.

Do not skip step 1 because the version numbers came back clean. The vulnerable window on these products stretches back through every version ever shipped in the affected range, so “we updated quickly” is evidence of good practice, not evidence of being untouched.

What to do if the audit actually finds something

Every guide tells you to look. Almost none tells you what to do when you find something, which is the only reason anyone is searching in the first place. If you have found an unexplained administrator account, a .php file in your uploads folder, or content on your site you did not publish:

1. Do not delete it yet. Deleting the evidence before anyone has looked at it makes the cleanup harder, not easier, because you no longer know how they got in or what else they touched.
2. Take the site offline or put it behind maintenance mode if it handles payments, donations or personal data. A donation form on a compromised site is a live problem, not a pending one.
3. Change the passwords that are not on the site: your hosting control panel, your domain registrar, your database, and the email account those recoveries point at. Site credentials are rarely the only ones stored on a compromised server.
4. Restore from a backup taken before the earliest date you can place the intrusion, then immediately apply every update in the table above before the site goes back online. Restoring to a pre-patch state and reconnecting it to the internet unpatched simply repeats the event.
5. If the site handles personal information, get advice on your notification obligations. Under Canadian federal privacy law, breaches of security safeguards involving a real risk of significant harm carry reporting and record-keeping duties. This is not something to work out from a blog post, ours included.
6. Then do the full cleanup properly. We have written the complete process in our guide to cleaning up and hardening a hacked WordPress site, which covers file integrity, database inspection and reinfection prevention in detail.

None of the above is legal advice, and this article does not assert anything about the state of any particular website. If personal or payment data may be involved, talk to someone qualified.

Why the patch reached you later than it should have

There is a detail in the Pods story that changes how you should think about the phrase “we keep plugins updated”, and it has had almost no coverage outside the WordPress trade press.

WordPress.org now operates a mandatory hold on plugin and theme releases, an initiative called Protect the Shire. Releases wait, currently for six hours, before they reach users. That hold applies to security patches the same way it applies to a routine typo fix, which is exactly the objection plugin developers and security researchers have raised about it.

When Pods shipped its emergency patches on 14 August, some of the backported releases were delayed further, because it was the weekend of WordCamp US and several members of the Plugins Team were travelling. Lead developer Scott Kingsley Clark, who is the sole primary developer on a plugin running on more than 100,000 sites and is not paid to work on it, took time off his day job to write the fix, then backported it across six versions and tested each against multiple combinations of PHP and WordPress. He told The Repository he was less worried about the fix than about “what other things might be hiding within the codebase.”

Two practical conclusions follow, and they are the reason this section is in the article at all:

• The gap between disclosure and your site being patched is not fully under your vendor’s control, and it is not under yours either. Automatic updates are necessary and they are not sufficient. Someone has to actually check.
• A large share of the WordPress components your business depends on are maintained by one person, unpaid, in their spare time. That is not a criticism of them. It is a reason to know exactly what your site is built from, and to keep the list short.

Common mistakes

• Updating the plugin and stopping there. On the two admin-takeover flaws, updating closes the entry point and leaves any account already created. Check the user list.
• Patching Avada but not Fusion Builder. The chain spans both. Both need their point release.
• Assuming the host handles it. Hosts can push free plugin updates. They cannot update a licensed product on your behalf, and that is precisely where two of the most serious flaws in this cluster live.
• Assuming you are safe because a plugin is deactivated. Deactivated is safer than active, but a deactivated plugin still has files on the server. Delete what you do not use.
• Treating the preconditions as an exemption. “We do not use Hub SSO” is a reason to be less worried, not a reason to skip the update. Advisories get revised as researchers keep looking.
• Not knowing what the site is built from. If nobody at your company can list the plugins on your own website, you cannot run this audit at all, and that is the actual problem to fix.
• Restoring a backup and putting it straight back online. A pre-intrusion backup is still a pre-patch backup. Update before it faces the internet again.

The ten minute version

1. Log in to WordPress. Go to Plugins, then Appearance > Themes.
2. Read the version number for each of: GiveWP, Avada, Fusion Builder, WPMU DEV Dashboard, Pods, TranslatePress, Forminator, Elementor Pro.
3. Compare against the table above. Update anything at or below the vulnerable version.
4. For anything that will not update, check the licence or registration status. That is the licence trap, not a broken button.
5. Go to Users, filter to Administrator, and read every account and registration date.
6. Check wp-content/uploads/ for .php files or any file type your forms do not accept.
7. Delete plugins and themes you do not use. Uninstalled beats updated.
8. Write down today’s date and the versions you landed on, so the next round takes five minutes instead of ten.

Frequently asked questions

I updated everything. Am I safe now?

You are protected against future exploitation of these specific flaws. You are not automatically clear of anything that happened before you patched, because two of the six lead to administrator takeover rather than a file you can spot. Update, then read your administrator user list and check your uploads folder. If both are clean and your site behaves normally, that is a reasonable place to stop.

My site is small and nobody knows about it. Does this really apply to me?

Yes. None of these attacks involve a human choosing your business. They involve automated scanning for a version number across the whole internet, which costs the attacker essentially nothing. A five page site for a Calgary trades company and a national retailer look identical to a scanner. Obscurity has never been a defence in WordPress security and it is less of one every year.

Why can’t my hosting company just update Avada or Elementor Pro for me?

Because they are commercially licensed products, not free repository plugins. The update is gated behind a licence key or a registration token that lives on your site and belongs to whoever purchased it. Your host has no way to supply that. This is why lapsed and unregistered licences are the most common reason a site is still unpatched weeks after a fix ships, and why licence status belongs in your audit alongside version number.

What does CVSS 9.8 or 10.0 actually mean for my business?

It means an attacker needs nothing from you. No password, no clicked link, no employee mistake. For a site owner the practical translation is: this is not a “keep an eye on it” item, it is a today item. The difference between 9.8 and 10.0 matters to researchers. For you, everything from 9.0 up is the same instruction.

I have a bilingual English and French site. What should I check first?

TranslatePress. The published exploit conditions are automatic string saving enabled and the administrator’s profile locale set to a published secondary language, which is close to the default configuration on a properly built Canadian bilingual site. Update to 3.3.2 or later, then read your administrator user list, because this flaw leads to account takeover rather than a file you can find.

How often does this actually happen?

Often enough that reacting to news is the wrong system. Six critical flaws in three weeks is a heavy cluster, but the underlying rate of disclosure against commercial WordPress components is rising, partly because researchers are now using automated tooling to find them. The workable answer is a standing maintenance routine with a named owner and a defined response window, not a fire drill each time a headline appears.

The bottom line

Six critical, unauthenticated flaws were patched across three weeks in the exact layer a small business WordPress site is built from. The remediation is genuinely simple: check eight version numbers, update anything below the line, read your administrator list, and look in one folder. Most sites will finish in ten minutes.

The sites that will not finish in ten minutes are the ones where nobody knows what the site is built from, or where a commercial licence lapsed quietly after handover. Both of those are maintenance problems wearing a security costume, and both are fixable before the next cluster arrives.

Want someone to run the audit for you?

We run version, licence and administrator audits across every site we look after, and we can run one on yours. If you would rather this stopped being your problem permanently, our website growth and care packages cover updates, monitoring and a defined response window, and our website packages cover rebuilds where the underlying stack is the real issue.

Tell us about your site through our intake form and we will come back with a scoped, fixed-price recommendation in Canadian dollars.

Sources

• The Hacker News, “Five Critical WordPress Plugin and Theme Flaws Enable Site Takeover or RCE”, 29 August 2026
• Wordfence advisory, WPMU DEV Dashboard (CVE-2026-76581)
• Wordfence advisory, Avada theme (CVE-2026-18431)
• Wordfence advisory, TranslatePress (CVE-2026-19632)
• Wordfence advisory, Pods (CVE-2026-19598)
• Patchstack, “Unauthenticated PHP Object Injection to Remote Code Execution on GiveWP” (CVE-2026-82222)
• The Repository, “Pods Ships Emergency Patches Across Six Major Versions”, 28 August 2026

This article is general information about publicly disclosed software vulnerabilities. It is not security or legal advice, and it makes no claim about the status of any particular website. Verify every version number against your own dashboard and the vendor’s advisory before acting.