Your plugin list said you were patched. For most of these sites it was lying.

Two critical vulnerabilities in the miniOrange SAML Single Sign On plugin let an unauthenticated stranger forge a login and land in your admin panel as any user they like. They score 9.8, they affect over 10,000 installations, and unlike the two flaws we wrote about last week, these are already being scanned for in the wild.

But the part worth your attention is not the cryptography. It is that for most affected sites, every tool you might have checked said you were already patched.

If you use miniOrange SAML SSO, do this now

The plugin is miniOrange SAML 2.0 Single Sign On. It ships as seven separately versioned editions under one WordPress.org listing, so find your edition in this table rather than assuming.

Edition	Vulnerable up to	Fixed in
Free	5.4.4	5.4.5
Premium single-site	13.0.3	13.0.4
Standard single-site	17.0.5	17.0.6
Premium / Enterprise multisite	20.2.7	20.2.8
Enterprise single-site	26.0.2	26.0.3
VIP single-site	32.0.7	32.0.8
VIP multisite	35.0.6	35.0.7

Update to the fixed version for your edition. A cross-edition jump may need a manual upload rather than the usual one-click update.

Then check your logs for administrator sessions from IP ranges you do not recognise. This is an authentication bypass being actively exploited, so the question is not only whether you are vulnerable but whether somebody has already walked in. Updating shuts the door; it does not tell you whether anyone came through it earlier.

If you cannot update immediately, the Patchstack advisory publishes two narrow code hotfixes for the specific files involved. Treat those as a stopgap measured in hours, not a fix.

It is being exploited now

This one was not found by a researcher reading code. It was found because DigitalOcean detected and blocked an attempt to establish a WordPress administrator session from an untrusted network on 16 August, and pulled the thread from there.

Since disclosure, scanning has been observed from six IP addresses across Belgium, Nigeria, the United States and Germany. The pattern reads as opportunistic rather than targeted: somebody throwing the exploit at every site that has the plugin installed, which is exactly what makes it dangerous to an ordinary small business. Nobody chose you.

The two bugs, and why they are worth ten minutes

Both are textbook, and both are the kind of thing that looks fine in review.

The first is signature algorithm confusion. A SAML response arrives carrying a cryptographic signature, and the plugin let the incoming response choose which algorithm to verify itself with. An attacker sets the signature method to HMAC-SHA1, which is a shared-secret scheme rather than a public-key one, and then uses the trusted RSA public key as the shared secret.

Read that again, because the flaw is complete once you see it. A public key is public. It is published, by design, to anybody who asks. If your verification code can be persuaded to treat that published value as the secret both sides share, then the attacker has the secret too, and can sign anything they like.

This family of bug has a long history, and it is always the same root: letting the untrusted input decide how it will be checked. The correct behaviour is for the server to decide the algorithm in advance and reject anything that does not match.

The second is smaller and, if anything, more instructive. PHP's openssl_verify() returns three possible values: 1 for a valid signature, 0 for an invalid one, and -1 when an error occurred. The plugin checked the result loosely rather than strictly.

In PHP, -1 is truthy.

So a signature malformed badly enough to make OpenSSL error out did not come back as invalid. It came back as -1, the loose check read that as success, and the forged assertion was accepted. The verification did not fail open because somebody forgot to verify. It failed open because the answer "I could not tell" was read as "yes".

Anywhere a check can return "valid", "invalid" or "error", collapsing three answers into two is where the vulnerability lives. The fix is a strict comparison against 1, and nothing else.

The real story: one slug, seven editions

Here is what makes this different from an ordinary plugin advisory.

That plugin has one WordPress.org listing slug and seven independently versioned commercial editions sitting behind it. Public advisories covered only the free edition, whose versions run 3.x to 5.x. The six paid editions were patched with no public documentation.

Now look at the version numbers. The free edition is fixed in 5.4.5. Premium runs at 13.x. Standard at 17.x. Enterprise at 26.x. VIP at 32.x and 35.x.

Every paid install carries a version number higher than 5.4.5. So every paid install read as already patched.

If you had run a vulnerability scanner, checked a security dashboard, or looked your plugin up in a database that week, the answer would have come back green. Not because anybody was careless, but because the tooling matches on a slug and a version number, and here that pair does not identify a product. It identifies seven products that happen to share a shelf.

That is not a WordPress problem. It is what happens in any ecosystem where one distribution channel carries multiple independently versioned products, and it is worth carrying into every dependency you manage: a version number is a fact about a release, not a statement about your security. The two are usually correlated. When they come apart, they come apart silently, and the silence looks exactly like safety.

This complicates what we told you last week

We published two pieces this week about critical flaws in WordPress form plugins, Forminator and Elementor Pro. Both ended with the same advice: know exactly what you have installed, and patch fast.

That advice was right and it was not sufficient, and this is the case that shows why. You can know exactly what you have installed, check it diligently against the public record, and still be told you are fine while an unauthenticated stranger logs in as your administrator.

So the honest version is longer:

Know what you have installed. Still first, still the thing most sites cannot answer.

Patch fast. Still true.

And know that a green result is evidence, not proof. Where a plugin has paid tiers, the public advisory may describe only the free one. When an advisory names a product you use, go to the vendor's own release notes for your specific edition rather than trusting the version comparison a database made on your behalf.

What this actually costs a small business

An arbitrary file upload flaw gives somebody code execution, which is bad. An authentication bypass gives them your admin panel, which is worse in a specific way: everything that happens next looks legitimate.

There is no malicious upload sitting in a folder to find. There is a login, from an IP address, doing things an administrator is allowed to do. Changing a bank account on an invoice template. Adding a user. Reading whatever personal data your site holds. If you are a practice or a firm holding client records, that last one is a personal data breach with reporting obligations attached, and "we did not notice" is not a defence that improves anybody's position.

Which is the argument for keeping the number of things that can log in as an administrator as small as you possibly can, and for knowing what every one of them is.

The honest caveat

We have not tested this ourselves and we do not run this plugin. Everything above is from Patchstack's published advisory and we have represented it as accurately as we can, including the parts that are their observation rather than ours.

Our free X-Ray reads what your site exposes from the outside. It cannot tell you which plugin editions you run, and after this week it is worth saying that even the tools which claim they can may be reading a version number that does not mean what it appears to mean. For this one, log in, check your edition against the table above, and then check your logs.

Source: Patchstack, August 2026. CVE-2026-61979 and CVE-2026-15981. Originally surfaced by DigitalOcean blocking an administrator session from an untrusted network.