WordPress sites have enough problems already.
Now attackers are actively hammering two vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin that can be chained to bypass authentication and potentially log in as WordPress administrators.
This one is particularly nasty because the attacker does not need to steal an administrator’s password. The authentication mechanism itself can be tricked.
- The Mess: Attackers are exploiting CVE-2026-61979 and CVE-2026-15981 in the miniOrange SAML SSO plugin to forge SAML responses and bypass authentication. The flaws can be chained together to impersonate legitimate users, including administrators.
SAML is supposed to make authentication safer and easier.
One identity provider.
One trusted authentication flow.
The WordPress site accepts a signed assertion and decides who you are.
Nice architecture.
Unless the application lets the attacker influence how that assertion is verified.
That’s essentially what happens here.
The vulnerable plugin accepts the signature algorithm specified in an incoming SAML response instead of strictly enforcing the algorithm configured by the administrator. One vulnerability can then be combined with the second flaw to manipulate the authentication process.
And once the attacker gets authenticated as an administrator, the WordPress part becomes almost secondary.
An administrator can install plugins.
Modify themes.
Change settings.
Create users.
Alter content.
Depending on the hosting environment, malicious code can potentially be introduced into the site itself.
So this isn’t just:
“Someone can log in.”
It can become:
“Someone can become the person who controls the entire website.”
That’s a much bigger problem.
- What Actually Happened: Security researchers detected active exploitation attempts against WordPress sites running vulnerable versions of the miniOrange SAML SSO plugin. The two flaws were being chained to bypass authentication.
The plugin exists specifically to connect WordPress authentication with external identity providers such as Microsoft Entra ID, Okta, Google Workspace and OneLogin.
That makes the vulnerability particularly interesting.
The whole point of SSO is centralized identity.
If the SSO layer can be fooled, the attacker does not necessarily need to attack the identity provider itself.
They attack the application that trusts it.
This is a classic example of why cryptography alone does not make authentication secure.
You can have strong cryptographic algorithms and still build a broken authentication system.
The application has to enforce the expected algorithm.
It has to validate signatures correctly.
It has to verify the issuer.
It has to verify the audience.
It has to validate timestamps and assertions.
And it absolutely has to reject unexpected authentication parameters instead of trusting whatever the client sends.
The server should decide how authentication works.
Not the person asking to be authenticated.
That sounds obvious.
Yet here we are.
- The Damage: A successful authentication bypass can give attackers administrator access to affected WordPress sites, allowing them to modify content, create accounts, install malicious components or potentially compromise the underlying server.
For website owners, the scary part is what happens after the login.
A stolen WordPress administrator session can be bad.
A forged administrator login is worse.
The attacker can potentially establish persistence by creating another administrator account.
They can modify plugins.
They can alter theme files.
They can inject JavaScript.
They can redirect visitors.
They can place malicious downloads on the site.
And if the WordPress installation has excessive filesystem or hosting permissions, the compromise can move beyond WordPress itself.
This is why authentication vulnerabilities deserve incident-response treatment.
If a vulnerable plugin was exposed while exploitation was taking place, administrators should not simply update it and assume everything is fine.
Check the user list.
Look for newly created administrators.
Review login activity.
Inspect modified plugins and themes.
Check scheduled tasks and suspicious PHP files.
Review web-server logs.
Look for unexpected SAML requests.
The attacker may have already been inside before the patch arrived.
- The Fix: Update the miniOrange SAML 2.0 Single Sign On plugin to a fixed version immediately, and if the site was running a vulnerable version during the attack window, audit administrator accounts and WordPress files for compromise.
If you do not actually need SAML SSO, disabling the vulnerable plugin until it can be safely updated is a reasonable temporary measure.
Also review who has administrator privileges.
There is rarely a good reason for ten different people to have WordPress administrator accounts.
And if the site uses external identity providers, make sure the SSO configuration is enforcing the intended signature algorithm and validation rules.
Do not assume that because Microsoft Entra ID or Google authentication is secure, the WordPress plugin consuming those assertions is automatically secure.
The weakest component still wins.
Bugstoday Verdict: SSO is supposed to eliminate password headaches. It should not eliminate the need for authentication checks. If attackers can forge the identity assertion and walk into WordPress as an administrator, the login screen is basically decoration.
