Summary
- Two miniOrange SAML flaws can undermine the signature checks used to trust identity-provider assertions.
- Attack attempts have been observed against affected WordPress installations.
- Independently versioned free and paid editions complicated public visibility of which releases were vulnerable and fixed.
Attackers are attempting to exploit authentication flaws in miniOrange’s SAML single sign-on software for WordPress, turning weaknesses in identity assertions into a route towards administrator access.
miniOrange provides SAML integration that allows WordPress sites to rely on enterprise identity providers rather than maintaining separate application passwords. Two vulnerabilities, CVE-2026-61979 and CVE-2026-15981, affect the point at which the plugin decides whether an incoming SAML response can be trusted.
CVE-2026-61979 affects the free edition through version 5.4.3 and was fixed in 5.4.4. The issue involved confusion around signature-algorithm handling that could allow an attacker to create an assertion the plugin accepted despite it not being legitimately signed by the identity provider.
CVE-2026-15981 affects the free edition through version 5.4.4 and was fixed in 5.4.5. That flaw arose from incorrect handling of the result returned by OpenSSL signature verification, allowing certain verification errors to be treated as successful validation.
The practical consequence can be authentication as an existing WordPress user, including an administrator, depending on the site and plugin configuration. Patchstack and DigitalOcean have reported exploitation attempts against affected WordPress installations.
The incident is more consequential than a routine content-management-system plugin flaw because SAML is specifically intended to centralise identity trust. Organisations deploy it to avoid maintaining separate application credentials and to place access decisions behind an identity provider such as Microsoft Entra ID, Okta or Google Workspace.
If the service provider incorrectly validates the assertion returned from that identity process, the strength of the upstream identity platform becomes largely irrelevant. The attacker is not defeating the identity provider itself; the attacker is convincing the application that an invalid assertion is legitimate.
Disclosure was further complicated by miniOrange maintaining multiple independently versioned editions under the same WordPress plugin family. Patchstack’s later analysis of paid editions found separate version ranges, including Standard edition 16.1.9, rather than a single numbering scheme that could be applied across every product line.
That creates a vulnerability-management problem beyond the code defect. Asset inventories and scanning products often map a product name or plugin slug to a public version history. Where several commercial variants share an identity but move through different version numbers, an organisation can believe its tooling understands the vulnerable range when it is actually looking at a different edition.
Patchstack said miniOrange supplied a fuller edition and version matrix after the issue was escalated. Fixes differ between the free and paid lines, making edition-specific verification important rather than relying on one version number across all installations.
The incident also shows how application-layer SSO components become part of the identity perimeter. A SAML plugin may look like a relatively small dependency inside a website, but it makes a high-impact security decision every time it translates an external identity assertion into a local authenticated session.
Where that trust decision fails, the compromise bypasses much of the security investment placed upstream. The relevant patching question is therefore not simply whether WordPress itself is current, but whether the component responsible for validating enterprise identity is running a fixed release for the specific edition in use.
