Published on 4 September 2026
An attacker who can log in as the administrator of your WordPress site without a password and without valid credentials – that is exactly what two critical vulnerabilities in the widely used plugin miniOrange SAML 2.0 Single Sign On make possible. Security researchers at Patchstack and DigitalOcean have analysed the flaws and documented that attack attempts have already been observed and blocked in the wild. Anyone using the plugin should not wait and see, but act now.
The two vulnerabilities carry the identifiers CVE-2026-61979 (officially rated CVSS 8.1, "High") and CVE-2026-15981 (officially CVSS 9.8, "Critical"). Both allow an attacker to log in as any existing WordPress user – all the way up to administrator. And here is the tricky part: because of the plugin's confusing versioning structure, many operators believe they are up to date when in fact they are not.
The miniOrange SAML 2.0 Single Sign On plugin lets users log in to WordPress via a central authentication service – so-called Single Sign On (a single login for multiple services). Technically, this happens via what are known as SAML assertions, i.e. digitally signed proofs from an identity provider (Identity Provider, or IdP for short) that tell WordPress: "This user is genuine and may enter." The signature is meant to guarantee that these proofs are not forged.
It is precisely this signature verification where the problem lies. In both cases, attackers were able to trick the check and slip the plugin a forged authentication proof, which it wrongly accepted as genuine. The result: a valid WordPress session in the name of a real account – without that account's password.
Patchstack sums up the situation clearly in its report:
„Exploitation has been attempted in the wild. DigitalOcean’s defense-in-depth controls detected and blocked the activity on its infrastructure.“ — Patchstack (with root-cause analysis by DigitalOcean)
In plain terms: there have already been attempts to actively exploit the vulnerability. DigitalOcean's layered protective measures detected and blocked the activity on their infrastructure. This is not proof that third-party sites were successfully compromised – but it is a clear warning sign that the vulnerability is real and of interest to attackers.
The two vulnerabilities arise from two different but related flaws in the signature verification.
With this flaw, the incoming SAML response itself could dictate which method should be used to verify its signature. Instead of the intended, secure RSA method, the algorithm could be switched to HMAC-SHA1 – a verification method that requires a secret password. The plugin then treated the identity provider's public key as this supposed secret. The catch: a public key is by definition public – anyone can know it. This meant an attacker could produce a signature that the plugin accepted as valid. This flaw affects versions up to 5.4.3 in the Free edition and is fixed as of 5.4.4.
The second, even more serious flaw lies in how the verification function openssl_verify() is evaluated. This function returns three possible values: 1 for "signature valid", 0 for "signature invalid", and -1 for "an error occurred during verification". The plugin, however, only checked the return value crudely as "true" or "false". And in the PHP programming language, the value -1 counts as "true". This means: a deliberately faulty signature that triggered an OpenSSL error was interpreted by the plugin as having been successfully verified.
The NIST National Vulnerability Database describes it as follows:
„The SAML Single Sign On – SSO Login plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 5.4.4.“ — NIST NVD / CNA Wordfence
According to the NVD, a WordPress authentication cookie could subsequently be set for an existing account determined by the so-called NameID (the user identifier named in the authentication proof) – the entry ticket to a full session. The prerequisites for the attack: a reachable SAML login and at least one existing target account. A prior WordPress login is not required. CVE-2026-15981 affects the Free edition up to and including 5.4.4 and is only fixed as of 5.4.5.
What makes this especially dangerous: the plugin exists in seven independently versioned editions – from the free version to various paid editions – all of which share the same WordPress.org identifier (slug) but use completely different version numbers. At the time of research, the Free edition stands at version 5.4.7, while paid lines carry numbers such as 16.x, 17.x or 20.x.
This leads to a dangerous fallacy: a vulnerable paid 16.x installation may, on a superficial check against the Free patch 5.4.5, wrongly appear to be "up to date" – when it is not. Patchstack also reports that a vulnerable default installation of the 16.x line showed no update notice in the WordPress dashboard at all. So anyone relying solely on the update display may miss the vulnerability entirely.
Affected are exclusively websites that use the plugin miniOrange SAML 2.0 Single Sign On (also listed as "SAML Single Sign On – SSO Login"). Anyone not using a SAML SSO plugin is not affected by these specific vulnerabilities.
To gauge the scale: at the time of research, WordPress.org shows more than 10,000 active installations for the Free edition. This figure, however, is only a conservative lower bound for the free version – the sources reviewed provide no reliable overall figures on the paid editions and their distribution. There is no verified number of successfully compromised third-party sites, and none is claimed here.
wp-content/plugins/miniorange-saml-20-single-sign-on/.Patches are available – and you should apply them immediately. The relevant minimum levels:
Concrete steps:
/wp-admin – for example through IP restrictions for administration, multi-factor authentication, WAF rules and a separate emergency admin access. These measures do not replace the patch, but they buy time.A note on the temporary source-code hotfixes documented by Patchstack: these are strictly short-term emergency measures for when a timely upgrade is technically impossible. They belong under change management, must be documented and tested – and they never replace the official vendor update.
A successful admin takeover can – depending on the website – open up access to customer, contact, order, membership or employee data. This makes the incident data-protection-relevant as soon as personal data could be disclosed, altered, deleted or rendered inaccessible without authorisation.
An important point of context: the vulnerability alone is not an automatically reportable data breach. Whether a reporting obligation exists is not decided by the CVSS score, but by the specific incident analysis. Controllers must nonetheless document every incident. If a risk to the rights and freedoms of natural persons is likely, the competent supervisory authority must be informed under Article 33 GDPR without undue delay and, where feasible, within 72 hours of becoming aware. Where a high risk is likely, notification of the affected individuals under Article 34 GDPR must additionally be considered.
The European Data Protection Board states the basic rule as follows:
„notification of any personal data breach to the relevant data protection authority (DPA) within 72 hours, unless it is unlikely to result in a risk to individuals“ — European Data Protection Board
Breaches of Articles 32 to 34 GDPR can, under Article 83(4)(a) GDPR, be sanctioned with up to EUR 10 million or up to 2% of the total worldwide annual turnover of the preceding year – whichever is higher. The specific obligation and sanction depend on the individual case. This assessment is general information and not legal advice.
For operators of affected editions, the technical priority is very high. CVE-2026-15981 is rated 9.8, "Critical", exploitable over the network without authentication and automatable. CVE-2026-61979 sits at 8.1 in the "High" range. According to the technical sources, both can enable a login as an existing user, all the way up to administrator.
The risk is aggravated by three factors: the versions diverge across seven lines, at least one affected Standard 16.x line gives no update signal in the dashboard, and Patchstack reports observed scanning as well as blocked exploitation attempts. A public proof of concept for the Free versions also exists – making the barrier for attackers low.
The DigitalOcean researchers describe one specific attempt they fended off:
„The attacker had already used the bypass to obtain a WordPress admin session cookie, but was stalled because the admin panel operations themselves sat restricted behind the trusted network.“ — DigitalOcean security team, as reported by Patchstack
So the attacker had already obtained an admin session cookie – and was only stopped by an additional network restriction. This underlines how valuable layered protective measures (defence in depth) are alongside the actual patch.
Two flaws in signature verification, seven confusingly versioned editions and an unreliable update display – this combination makes the miniOrange SAML SSO vulnerabilities a case you must not put off. Anyone using the plugin should now do three things: determine the exact edition and version, update to the appropriate fix level, and review the logs retrospectively from 16 July 2026. Do not rely on the WordPress dashboard for this – check manually.
If you find signs of unauthorised access, immediately start your incident process and the data-protection assessment under Article 33 and, where applicable, Article 34 GDPR. And if you are unsure whether your installation is affected or whether something has already happened: get professional support before a vulnerability turns into a reportable data breach.