WordPress plugin security: nothing is secure, only fast

Is WordPress less secure than a custom-coded site?

Not in the way the question implies, and the honest answer is more useful than the comparison. A vulnerability appearing is not the variable you control. Both WordPress and the framework this site runs on produced a critical, unauthenticated, remote vulnerability inside the same seven days. What differed was everything that happened afterwards: whether the advisory named your version, whether a database could list it, whether a scanner could see it, and how many steps the fix took.

Those four things are measurable, and they are the ones worth asking a provider about. Platform choice on its own is not a security outcome.

"A vulnerability appearing is not the variable you control. The time between a public exploit and your fix is.

What happened in the WordPress SSO plugin?

Two vulnerabilities in miniOrange's SAML single sign-on plugin came under active exploitation. CVE-2026-15981 is an authentication bypass at CVSS 9.8, critical, affecting free-edition versions up to and including 5.4.4 and fixed in 5.4.5. CVE-2026-61979 is an unauthenticated privilege escalation at CVSS 8.1, high. Checked August 2026.

A note on that second score, because the published numbers disagree. Patchstack assigned the CVE record at 8.1, and their own write-up describes both SAML issues as 9.8. Wordfence separately assigned CVE-2026-15013 at 9.8 for what the records describe as the same mechanism and the same version range. Two numbering authorities, one bug, two scores. We cite the CVE records rather than the article, and note the discrepancy rather than picking the more dramatic figure.

How does a signature check return an error and still pass?

This is the part worth understanding, because it is not exotic. PHP's openssl_verify() is tri-state: it returns 1 for a valid signature, 0 for an invalid one, and -1 when OpenSSL itself errors. The plugin checked the result with a loose boolean test. In PHP, -1 is truthy.

So an attacker sent a deliberately malformed signature, OpenSSL failed, the function returned -1, and the plugin read that failure as a success. The NVD record states the consequence plainly: it became possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, by submitting a crafted SAML response with an attacker-controlled identity and a signature deliberately broken enough to trigger the error path.

The bug is not that the cryptography was weak. It is that the failure case was never distinguished from the success case. That is a category of mistake any codebase can make, ours included, and it is why the rest of this article is about response rather than about blame.

Why did scanners report vulnerable sites as safe?

This is the finding that matters more than either CVE. 7 independently versioned product editions ship under one WordPress plugin slug: free, Standard, Premium, Premium multisite, Enterprise, VIP single site and VIP multisite. The public advisories covered the free edition only.

Patchstack reported on 21 August 2026 that the six paid editions were patched with no public changelog entry and no advisory, so no vulnerability database listed them, and vulnerable sites were reported as unaffected. Checked August 2026. That state ended on 18 August 2026, when miniOrange supplied the full edition and version matrix and Patchstack updated its database.

Sit with what that means for a site owner doing everything right. You run a scanner: it reports clean, because your edition is not in the database it queries. You check the dashboard: it shows no update, because the patched build is on a different version line. You read the advisory: it names versions that look nothing like yours. Three independent checks, all reassuring, all wrong at the same time.

One precision worth keeping. Patchstack's specific finding on updates is that a site running Standard 16.1.9 is not offered the patched 17.0.6, because the WordPress update mechanism does not offer a jump across version lines, so the upgrade is a manual file upload. miniOrange's own documentation does describe paid plugins showing dashboard update notifications in the normal case. The failure is the cross-line jump, not update notices in general.

"The scanner said clean, the dashboard said current, and the advisory named a version series the site had never used.

How long was a working exploit public before anyone noticed?

Eighteen days. A full disclosure with a proof-of-concept and a Docker lab was posted to the Full Disclosure mailing list on 29 July 2026 for the algorithm-confusion variant, including a full chain to administrator. DigitalOcean detected an anomalous WordPress admin session on 16 August and shared a working reproduction on 17 August.

Patchstack published six scanning IP addresses spread across Brussels, Abuja, Frankfurt and two US cloud providers, and characterised the traffic as opportunistic scanning rather than a targeted campaign. No source publishes attack volumes or compromise counts, so we do not either.

What did the vendor's changelog actually say?

For the one edition that did get a public changelog, the entries read: “Removed support of insecure signature algorithms” at 5.4.4, and “Bugfix: Fixed unauthorised access issue in SAML SSO” at 5.4.5.

Neither line says authentication bypass. Neither carries a CVE number or a severity. A site owner scanning a changelog for something alarming would have moved past both. We found no security advisory published by miniOrange on their own site, and their plugin changelog page publishes no per-version entries for the paid editions at all. They did cooperate privately, supplying the complete matrix on 18 August.

The free plugin currently reports 10,000+ active installations on WordPress.org. Install counts for the six paid editions are not published anywhere, so the size of the exposed population is genuinely unknown. Checked August 2026.

We patched a critical remote code execution the same week

On 25 August 2026, Next.js disclosed two critical vulnerabilities. The one that applied to this site was CVSS 9.5, critical: an unauthenticated remote code execution in the image optimization API, reachable when an attacker-controlled AVIF image is processed, caused by a flaw in the libheif library underneath sharp. Checked August 2026.

This site was running a vulnerable version with AVIF enabled. Here is the whole remediation: read the advisory, run one install command to move to 16.3.3 and 15.5.24, remove AVIF from the image config to match what the patch does anyway, run the type check and the build, confirm the audit reports no critical findings. Then the same sequence across the other projects we maintain, in priority order by exposure, live commerce first.

We are not claiming that was impressive. We are claiming it was possible. The advisory named the exact patched versions. An automated audit surfaced the problem without anyone having to know it existed. One command applied the fix. A build confirmed nothing broke. None of those four steps were available to a site running a paid edition of the SSO plugin during the same week.

One more detail worth noting, because it is process rather than luck: Vercel pre-announced the release, then moved it forward when a second critical issue was found, so that anyone patching would only have to upgrade once. That is a decision made on behalf of people downstream.

What actually differs, in four measurable things

Strip out the tribalism and the difference between the two responses reduces to four questions you can ask about any dependency in your stack.

• ✓
  Does the advisory name the exact version you are running? Next.js named two patched versions covering every affected release line. The SSO advisories named one edition out of seven.
• ✓
  Can a vulnerability database list your build? npm audit surfaced the Next.js issue automatically. Six paid plugin editions were absent from every database until the vendor supplied a matrix on 18 August.
• ✓
  Will your normal update path deliver the fix? A dependency bump is one command. A cross-line jump from a 16.x edition to a patched 17.x edition is a manual upload the dashboard never offers.
• ✓
  Can you verify the fix landed? A build and an audit either pass or fail. Comparing an unlabelled paid version string against a matrix published in a third-party article is not the same kind of confirmation.

Notice that none of those four is about the language, the framework or the hosting. They are about disclosure discipline and update mechanics, and they vary enormously between vendors inside the same ecosystem.

What should you do if you run this plugin?

• ✓
  Identify your edition, not just your version number. Free, Standard, Premium, Enterprise and VIP use separate version series, so a version alone tells you nothing about whether you are patched.
• ✓
  Free edition is patched at 5.4.5. For the paid lines, compare against the matrix miniOrange supplied on 18 August 2026 rather than assuming the dashboard would have told you.
• ✓
  If the dashboard offers no update and you are on an older line, expect a manual upload. The absence of an update prompt is not evidence that you are current.
• ✓
  Audit for administrator accounts you do not recognise, and for recent logins to accounts that should be dormant. Exploitation was underway before the advisories covered the paid editions, so a clean scan today does not describe last month.
• ✓
  Check the separate OAuth plugin too. CVE-2026-57807 is a CVSS 9.8 authentication bypass affecting that plugin through 38.5.8, disclosed in July.

What to ask a provider about their patch process

A response-time promise is worth very little, because the hard part is finding out at all. Ask about the sequence instead.

• ✓
  How would you find out a dependency in my site had a critical vulnerability? Name the mechanism, not the intention.
• ✓
  Which of my dependencies are covered by automated advisories, and which are not? Paid plugins and closed-source add-ons are the usual blind spot.
• ✓
  What did you patch most recently, and how long did it take from advisory to deploy?
• ✓
  If a fix requires a manual upgrade rather than an automatic one, who does it and when?
• ✓
  How do you verify a patch actually landed in production rather than assuming it did?

"Ask what someone patched last month, not how fast they promise to patch next time.

So is a custom build safer?

On the evidence of this one week, no, and we would be contradicting our own patch notes to say otherwise. A custom Next.js application has fewer moving parts than a WordPress install carrying forty plugins, and a smaller third-party surface is a real advantage over time. It is not immunity. The framework underneath it shipped a 9.5 unauthenticated remote code execution while this article was being researched.

What a smaller surface buys you is that the four questions above have answers. Fewer dependencies, each one publicly versioned, each one covered by an advisory feed, each one updatable by a command that leaves an audit trail. That is not the same as being secure. It is being able to move quickly when you are not.

If you are weighing the platform question more broadly, our guide to WordPress AI plugin advisories covers the same discipline applied to AI and MCP plugins, and how plugin stacks affect site speed covers the performance half of the same trade-off.

Related reading: WordPress AI plugin security advisories applies the same dated, evidence-led method to AI Engine and MCP, and WordPress compared with Next.js sets out the wider trade-off without treating either as a security guarantee.