Six critical WordPress flaws in ten days. NVD independently scored none of them, and the claim that plugins cause most compromises has no current source

Six products, ten days

Between 21 and 28 August 2026, Wordfence and Patchstack disclosed critical flaws in five WordPress plugins and one theme. A sixth product, miniOrange SAML SSO, sits slightly apart: different firm, earlier disclosure, and the only one of the group with any evidence of attack.

The cluster, with what is sourced and what is not

Product	CVE	Score, and who set it	Fixed in	Active installs
WPMU DEV Dashboard	CVE-2026-76581	9.8, Wordfence	5.0.2, 24 Aug	~350,000, Wordfence estimate
Avada and Fusion Builder	CVE-2026-18431	9.8, Wordfence	7.16.1 and 3.16.1, 25 Aug	Not sourced. Over a million sales
TranslatePress	CVE-2026-19632	9.8, Wordfence	3.3.2, 13 Aug	400,000
Pods	CVE-2026-19598	9.8, Wordfence	3.3.9.1, 14 Aug	100,000
GiveWP	CVE-2026-82222	10.0, Patchstack	4.16.7.2, 27 Aug	100,000
miniOrange SAML SSO	CVE-2026-61979 and CVE-2026-15981	8.1 and 9.8, see below	Seven editions, see below	10,000+ free edition only

Two entries in that table need their caveats stated rather than buried.

Avada's install base is not sourced. Wordfence's advisory says "over a million sales", and sales is the correct word: it is a cumulative purchase counter that never decrements, running since 2012. Avada is not in the WordPress.org theme directory, so no active-install telemetry exists. Avada's own site is not much help either, carrying three mutually inconsistent figures on a single page: 1,070,117 "website owners", "1,050,000+", and "more than 1,000,000 active users". If you see a clean "one million sites affected" figure, it has been manufactured from a sales counter.

Wordfence contradicts itself on Avada's preconditions. Its CVE record states that exploitation "requires ... certain administrator-authored content to be present". Its comment to BleepingComputer was that "any site that has the Avada theme installed is going to be exploitable" and that the prerequisites "don't narrow the pool of potential targets". Both cannot be true, and the CVE record is the more conservative.

Where these scores actually come from

Where a WordPress CVSS score actually comes from

Every CVSS score in this cluster was set by the organisation that found the flaw, acting as its own CVE Numbering Authority. NVD carries all eight with CVSS type Secondary, sourced to security@wordfence.com or audit@patchstack.com, and a status of Deferred or Awaiting Analysis. NVD has independently analysed none of them.

This is the CVE programme working as designed, and it is worth being clear about that. Wordfence and Patchstack do the overwhelming majority of security research in this ecosystem, and self-scoring by a CNA is the normal arrangement. The problem is only in the retelling: by the time a score reaches a newsletter it looks like it has been through NVD, and it has not. One organisation's judgement is being counted as three sources.

Two signals pointing the other way also drop out. CISA's own SSVC triage records exploitation: none for every identifier here, and none of the eight is in the CISA KEV catalogue (checked against version 2026.08.27, 1,685 entries).

The one with real attacks is the one the ecosystem got most wrong

miniOrange SAML SSO is the only product here with named, dated attack evidence, and almost every detail circulating about it is wrong in some direction.

Two CVE identifiers exist for one bug. Patchstack issued CVE-2026-61979 and scored it 8.1, with AC:H. Wordfence issued CVE-2026-15013 for the same signature-algorithm-confusion flaw and scored it 9.8, with AC:L. Patchstack's own database flags the duplication. The widely reported "CVSS 9.8" belongs to the duplicate, and the CNA that coordinated the disclosure scored it nearly two points lower. Report all three numbers, or none.

It is one plugin with seven independently versioned editions, not seven plugins. One WordPress.org slug, and version lines running from 5.4.x for the free edition up to 35.x for VIP multisite. A DigitalOcean investigation confirmed the flaw on Standard 16.1.9, for which no patch exists in that line at all: the fix is a manual cross-line upload to 17.0.6, and the WordPress dashboard shows no available update.

And "under active attack" is thinner than the phrase suggests. The evidence is one anomalous administrator session blocked by DigitalOcean on 16 August, opportunistic scanning from six IP addresses, and a public proof of concept for the free edition. Patchstack itself characterises it as "opportunistic scanning rather than a targeted campaign". No victim count exists.

Why the auto-updater was never going to save you

There is a trap in the documentation worth knowing about. The setting plugins_auto_update_enabled defaults to true, and it is easy to read that as auto-updates being on. The documentation is explicit that it is not: "This does not enable or disable auto-updates. It controls whether to show the user interface elements." Meanwhile the end-user help page never states that plugin auto-updates are disabled by default at all.

Line that up with the table above and the actual supply-chain finding appears. Of the six products, the three the ecosystem's automatic remediation machinery can reach are the WordPress.org-hosted ones, and Pods got a forced push. The three commercial products are precisely where remediation depends entirely on somebody noticing, and the one with real attack telemetry is commercial.

The pattern claim that nobody can source

Here is where this stops being a patch list.

"Around 91% of WordPress vulnerabilities are in plugins" is solid. Patchstack reports 91% of 11,334 for 2025; Wordfence reports 96% of 8,223 for 2024. Two vendors, separate databases, different counting rules, broadly the same answer. Our own count of CVE records by assigning CNA gives 7,359 for January to August 2026, which annualises roughly flat and lands within 2% of Patchstack's own figures for 2025.

"Around 91% of WordPress compromises are caused by plugins" is a different claim, and it is not sourced.

The most recent hacked-site telemetry is Sucuri's 2023 report, published June 2024, covering 39,594 cleaned websites. Its relevant finding is that 13.97% of compromised sites had a vulnerable component present at all, which is a presence figure and not a cause. Sucuri does not attribute compromises to entry vectors, and there has been no edition since.

What both vendors actually name as the rising intrusion source is credentials. Sucuri: "a notable increase in website compromises resulting from stolen credentials". Wordfence: "hosting account credential compromises are a frequent source of intrusion". Wordfence's own 2024 telemetry blocked 48 billion requests targeting vulnerabilities against 55 billion password-hacking attempts.

For context on scale rather than blame: WordPress is 40.7% of all websites and 58.9% of those with a known CMS, measured by W3Techs on 30 August 2026, and that share has fallen every year since peaking at 65.2% in January 2022.

What to do this week

The position

The patching advice here is real and worth acting on today. But the durable lesson is about the numbers, and it applies well beyond WordPress.

An ecosystem's threat picture is largely a picture of where its two commercial research teams chose to look. Patchstack coordinated 63.8% of the vulnerabilities in its own headline count. Wordfence disclosed between a third and a half of each quarter's total and credits the CVE Numbering Authority programme itself for part of the year-on-year rise, which means some of the growth curve is disclosure infrastructure rather than more insecure software. Those are honest, well-run programmes producing genuinely useful data, and the data still cannot answer the question everyone uses it to answer.

This site keeps landing on the same defect from different directions: a version-based scan read as a count of compromised servers, a row count read as a number of patients. Here it is a vulnerability count read as a cause of breaches, and the substitution has been running so long that the only quantified figure underneath it is a decade-old survey of a couple of hundred self-reporting site owners.

Patch the six. Then go and check whether the number you use to justify your WordPress security budget has a source.