WordPress

WordPress plugin security: checks, patching and recovery

In the second half of August 2026, attempts to exploit a critical authentication bypass in a WordPress single sign-on plugin were reported, and a critical remote code execution was disclosed and patched in Next.js. Both landed within ten days of each other. We patched the second one on our own site, which is why this is not an article about how custom code is safe.

The SSO and Next.js figures were read at their primary records on 26 August 2026, the Super Forms and Elementor Pro figures on 5 September, and all of them rechecked on 8 October 2026. Every source is linked. Where two sources disagree, both are given.

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 had a critical, unauthenticated, remote vulnerability in the news within ten days of each other. 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?

About three weeks. A proof-of-concept with a Docker lab for the algorithm-confusion variant, including a full chain to administrator, was public on GitHub from 27 July 2026, and a write-up dated 29 July reached the Full Disclosure mailing list in early August. DigitalOcean detected an attempted WordPress admin session on 16 August and shared a working reproduction on 17 August.

Patchstack published six scanning IP addresses in Belgium, Nigeria, Germany and the US, 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.

The summer attacks invert this, and that case is worse

In July and August 2026 two WordPress plugins were attacked at scale while a fix was already published for both. By early September Wordfence had blocked more than 250,000 attempts against Super Forms and more than 190,000 against Elementor Pro. Neither campaign relied on a hidden edition, a silent changelog or an advisory that named the wrong version. Both vendors did the disclosure work correctly, and attackers sent hundreds of thousands of exploit attempts anyway.

CVE-2026-14894 is an unauthenticated arbitrary file upload in Super Forms, scored CVSS 9.8, caused by a public AJAX endpoint that performed no file-type validation and no capability check. Super Forms 6.3.314 fixed it on 8 July 2026 and Wordfence published the advisory on 9 July. Attacks began on 14 July, five days after that advisory, and were heaviest between 18 and 25 August, peaking above 40,000 requests in a single day. Attackers were still hammering unpatched sites six weeks after the fix shipped.

CVE-2026-32475 is the same class of flaw in Elementor Pro, scored 9.0 on its CVE record and 9.8 by Wordfence, reachable on any site with a published Form widget that has at least one File Upload field not marked as required (the default). Patchstack and Wordfence both published it on 19 August 2026, the day Elementor released 4.2.2. Exploitation started the same day. By 2 September Wordfence had blocked more than 190,000 attempts, most of them between 19 and 23 August, against a plugin Wordfence puts at more than six million installations. Elementor shipped the fix the day the flaw went public, and that did not protect the sites that had not applied the update.

Read against the miniOrange case, these two say something the four questions above do not cover. With the SSO plugin the failure was upstream, because no advisory named the paid editions and a diligent owner could not have found out. With Super Forms and Elementor Pro every signal worked. The version numbers were public and the dashboard offered the update. No edition matrix had to be reconstructed from a third-party article. A patch nobody applied protects a site exactly as much as a patch nobody wrote. That gap is not something a vendor can close on your behalf.

Both flaws also share a shape worth recognising in your own stack. A form that accepts file uploads from the public is a code path where an unauthenticated stranger writes a file to your server, and it turns on validation that is easy to get subtly wrong. Elementor Pro failed on an array-shaped submission where the first element was empty and the second carried the payload, and Super Forms never checked the file type at all. If you run any plugin that accepts public uploads, that is the input worth asking about first.

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.
• ✓
  The free edition needs 5.4.7 or later. 5.4.5 fixed the two bypasses above, but a third flaw, CVE-2026-19842 (CVSS 8.8, published 19 August 2026), stayed open until 5.4.7: the plugin stored a SAML certificate without checking its signature, and an administrator could be led to trust it in one click. The current free release is 6.0.0. 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 happened with Rank Math PRO in October 2026?

Some copies of Rank Math PRO 3.0.123, the paid edition of the Rank Math SEO plugin, contained malware. According to Rank Math's security advisory, the affected files reached users who downloaded or updated between 15 October 2026 at 20:02 UTC and 16 October at 07:12 UTC. Rank Math removed them and released a clean version, 3.0.124. The free Rank Math SEO plugin on WordPress.org was not affected. Wordfence published CVE-2026-111862 for it on 19 October, scored CVSS 9.8, and describes it as a supply-chain compromise.

This is a different failure from the summer cases. There, the risk was a published fix that hadn't been applied. Here, the risk was in the package being delivered: copies obtained during an eleven-hour window carried the malware. Updating promptly is still the right default; this case is about knowing what you installed and when. Version 3.0.123 had been out since 7 October, so the files appear to have been swapped after release. Rank Math hasn't said how that happened, or how many sites received them beyond “a limited number of users”. Its changelog lists the same two fixes for 3.0.123 and 3.0.124 and doesn't mention security, so the advisory is the place to read about it.

The version number alone doesn't tell you whether a site was hit; the CVE record says so directly. What matters is whether you obtained a copy during that window, and whether it was ever activated. Below is a summary. For the complete steps, follow Rank Math's full procedure or ask your host for help.

• ✓
  Obtained an affected copy during the download window and activated it at any time, then or later: Rank Math says to treat the site as compromised. Updating to 3.0.124 alone doesn't complete recovery. Its recommended route is to restore the files and database from a backup made before 15 October at 20:02 UTC, run a security scan, change every password, database credential, API key and set of WordPress salts the site could reach, then install 3.0.124 from your Rank Math account.
• ✓
  Installed but never activated: delete the plugin folder, install 3.0.124 from your Rank Math account and run a security scan.
• ✓
  Downloaded but never installed: Rank Math says there is no sign of compromise from this incident alone.
• ✓
  Cleaning by hand instead of restoring: the order matters, because the malware rebuilds its backdoor when someone visits the site. Rank Math says to delete the whole rank-math-pro folder, remove any wp_options entries matching the malicious keys it lists, and block outgoing connections to rank1cdn.com where your host or firewall allows, before looking for anything else. Its procedure then covers other files, accounts, cron jobs and the server, credential changes, and checks that the site stays clean.
• ✓
  Signs Rank Math lists: administrator accounts named wpsupport_ followed by random characters or using @wp-mail.net addresses, a fake core file at wp-includes/class-wp-cache-util.php, .htaccess rules that run .cache files as PHP, a system cron entry tagged #ms6v46, and connections to rank1cdn.com.
• ✓
  Rank Math says it never sends login or download links by email. Get 3.0.124 by going to rankmath.com yourself, and treat any unsolicited password-reset or download email about this incident as suspect.

The four questions earlier don't cover this kind of case. The advisory named the affected version, and the clean release is dated 16 October. Update records and clean backups are important here, for working out which sites were exposed and for recovering them.

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.

If you want to keep WordPress and need someone to repair it and look after updates, our WordPress website service covers fixes, redesigns and new builds. The written quote names who handles updates, backups and security patches after launch.

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 application can remove the need for particular privileged plugins, but its npm dependency tree and external services also need an inventory. Fewer WordPress plugins does not establish fewer dependencies or lower overall risk. The framework underneath it shipped a 9.5 unauthenticated remote code execution while this article was being researched.

The useful advantage is a controlled release process: inventory dependencies, review updates, test critical flows and deploy a known artifact. WordPress can also use staged releases. Neither a passing build nor an advisory scan proves the absence of malware. Our security repair comparison explains why patching and compromise recovery require different work.

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. Cloudflare pitched EmDash's sandboxed plugins at the same problem, and our EmDash review covers what that sandbox does and doesn't change.

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.