Two miniOrange SAML flaws may let outsiders sign in to WordPress as administrators. Some paid editions may not show an available update in the dashboard.
- Two flaws may let an unauthenticated attacker forge a SAML response and enter WordPress as an existing user, including an administrator.
- Analysis published on 21 August 2026 shows affected paid editions as well as the free plugin; some releases do not show an update inside WordPress.
- Identify the exact edition and version, update manually if necessary, then review unfamiliar administrator sessions and changes.
What happened, who is affected and what should teams do now?
Two flaws in the miniOrange SAML 2.0 Single Sign On plugin for WordPress may let an outsider sign in as an existing site user, including an administrator. The issues are tracked as CVE-2026-61979 and CVE-2026-15981.
WordPress sites using this plugin for enterprise single sign-on should check immediately. The impact is critical because the attacker does not need a prior account and does not need an administrator to click a link.
First identify the exact miniOrange edition and version, compare it with the fixed-version list below and update. Do not rely only on an “up to date” message in WordPress because some old paid editions do not surface the required upgrade.
Seeing “up to date” in WordPress is not enough here: the edition and version line determine whether the site is actually fixed.
What is SAML and why do these flaws matter?
SAML is a way for a website to receive an identity statement from an organisation’s central login system. Instead of storing a separate password for every site, the identity provider sends a signed message saying that the user has authenticated and identifying that user.
The two flaws cause the plugin to accept an invalid statement. One permits the wrong signature method; the other treats an OpenSSL error result as though verification succeeded.
Once the forged statement is accepted, WordPress can create a session for a username chosen by the attacker. If that user is an administrator, the attacker may edit content, install plugins, create accounts or seek access to data.
What is confirmed, and what remains unknown?
The CVE records and Patchstack analysis confirm the authentication bypass in the free edition. DigitalOcean’s security team also reproduced both flaws against Standard edition 16.1.9 and worked with miniOrange to map affected versions across seven product editions.
On 16 August 2026, DigitalOcean detected an attempted administrator session from outside its trusted network and blocked it with an additional control. Patchstack also reports scanning of the SSO endpoints from several network addresses.
This is evidence of attempted real-world exploitation, but public information does not establish a widespread compromise, identify a threat actor or quantify affected sites. It would be inaccurate to assume that every installation has already been breached.
Versions that should be updated
miniOrange distributes seven product lines under one plugin identity, each with a different version range. According to the matrix miniOrange supplied to Patchstack, the releases below are the minimum versions that close both attack paths.
- Free, single site: update to 5.4.5 or later.
- Premium, single site: update to 13.0.4 or later.
- Standard, single site: update to 17.0.6 or later.
- Premium, Enterprise or All-Inclusive multisite: update to 20.2.8 or later.
- Enterprise or All-Inclusive, single site: update to 26.0.3 or later.
- VIP, single site: update to 32.0.8 or later.
- VIP multisite: update to 35.0.7 or later.
Why might WordPress show no update?
The free edition and six paid editions share one plugin slug while using separate version bands. Early vulnerability records described only the free branch, so a scanner could see a paid release such as 16.x or 26.x and incorrectly treat it as newer than a 5.4.x fix.
For some paid branches, miniOrange shipped fixes without a public security notice or an automatic upgrade path in WordPress. A Standard 16.1.9 installation, for example, needs a manual move to the 17.x branch.
The practical lesson is that a scanner and the update screen are supporting signals, not a complete inventory. Operations teams still need the product edition, licence source and actual installed version.
A checklist for today
Before replacing a plugin on a live site, take a backup and test the login journey in a staging environment where possible. Then work through the following steps.
- Record the miniOrange edition, installed version and the SAML configuration used by each site.
- Obtain the current package from the correct miniOrange account or WordPress.org source; be ready to upload paid-edition upgrades manually.
- Retest SSO login, logout, user mapping and administrator permissions after the update.
- Review logs for administrator sessions from unexpected networks, countries or times, and inspect new administrator users, plugins and SAML configuration changes.
- If anything is suspicious, invalidate active sessions, rotate relevant credentials and investigate before removing evidence.
- Restrict the administration area with an additional authentication layer, VPN or trusted-network allowlist where the operating model permits.
Where Friday Works can help
Friday Works can help inventory plugins, review the SAML login path, check versions, administrator privileges, configuration and signs of unexpected change. After the update, we can retest authentication and authorisation so that the fix does not disrupt legitimate users.
This sits within a website and web-application security assessment. It is not a substitute for a full incident-response investigation when there is evidence of data access or system control.
FAQ
Frequently asked questions
Are all WordPress sites affected?
No. This alert applies to sites running miniOrange SAML 2.0 Single Sign On or SAML SP Single Sign On within one of the affected version ranges.
Is the site safe if WordPress says the plugin is current?
Not necessarily. Some paid editions have independent version branches and may not show an automatic upgrade. Identify the edition and compare it with the minimum fixed release.
Should teams review logs after patching?
Yes. A patch blocks future attempts but does not show whether earlier access occurred. Review administrator sessions, new accounts, new plugins and SAML configuration changes.
References
Sources used in this guide
We prioritise official guidance and primary technical sources. Visit each source for full context and the latest updates.