The plugin used the identity provider's public key as a shared secret — and only the free edition got told

Two vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin for WordPress chain together into an authentication bypass. They are being exploited.

Both are textbook, which is what makes them worth reading rather than just patching.

Bug one: the public key as a shared secret

CVE-2026-61979 lets an attacker choose HMAC-SHA1 as the signature algorithm. When they do, the plugin takes the RSA public key belonging to the identity provider and uses it as the shared secret for the HMAC.

A public key is public. That is its entire job.

So the attacker supplies a value that anybody can obtain, computes a signature that verifies against it, and the plugin accepts the assertion as genuine. This is algorithm confusion — the same shape as the JWT attack where a token signed with alg=RS256 is replayed as alg=HS256 — and it has been a known class of bug for over a decade.

The defence is one line of logic: the verifier, not the token, decides which algorithm is acceptable.

Bug two: minus one is not zero

CVE-2026-15981 is simpler and somehow worse. The plugin treats an OpenSSL verification error — a return value of -1 — as a successful result.

OpenSSL's verification functions return 1 for valid, 0 for invalid, and -1 for an error. Code that checks whether the result is not zero, or that treats anything truthy as success, turns every internal failure into a pass. A malformed signature that OpenSSL cannot even process comes back as approved.

That is the whole bug. It is a comparison.

Chained, they are a front door

Either flaw alone is serious. Together they mean an attacker can forge a SAML assertion asserting they are any user — including an administrator — and the plugin will accept it.

For a WordPress site using SAML for single sign-on, the plugin is the authentication. There is nothing behind it to catch this.

It is already happening

On 16 August, DigitalOcean blocked an anomalous WordPress administrator session originating from an unauthorised network. That was live exploitation, against the Standard edition at version 16.1.9.

The traffic came from six IP addresses across Europe, Africa and the United States. A proof-of-concept for the free edition is publicly available, and Patchstack reports that exploitation attempts and opportunistic scanning are underway.

Six addresses on three continents is not a targeted operation. It is scanning.

The part that should not have happened

Fixes exist for all seven editions:

The vendor's advisory covered only the free edition. Six paid editions had a fix available and no alert telling anyone to apply it.

The customers who paid the most were the ones least likely to hear about it — and the exploitation that has been confirmed so far hit a paid edition. A patch nobody is told about is, from the perspective of an unpatched site, indistinguishable from no patch.

What to do

• Check your edition and version now. The fixed version differs for each of the seven, and the numbering is not comparable between them.
• Update immediately. This is remote, unauthenticated, and being scanned for.
• Then check for accounts you did not create, and for administrator sessions from addresses you do not recognise. A successful bypass leaves a logged-in admin, not a crash.
• Rotate the identity provider's certificate after patching if you believe you were exposed.
• Do not rely on vendor advisories as your only patch signal. This incident is the argument for a feed that watches the CVE, not the newsletter.

What is not established

• How many sites were compromised. One blocked session is confirmed; the total is unknown.
• Who is behind it. No attribution.
• Whether the six addresses are related or independent opportunists working from the same public proof-of-concept.
• Why the advisory omitted the paid editions. miniOrange has not explained it publicly.
• Total install count across the seven editions.