Unauthenticated authentication bypass in miniOrange WordPress OAuth Single Sign On, SSO (OAuth Client)

Unauthenticated Bypass Vulnerability in OAuth Single Sign On – SSO (OAuth Client) <= 7.1.2 versions.

The miniOrange WordPress package miniorange-login-with-eve-online-google-facebook has the following supported scope:

• OAuth Single Sign On, SSO (OAuth Client): versions <= 7.1.2 are identified as affected.
• Version 7.1.3 is recorded as unaffected and is the fixed version boundary in the affected data.
• The status of parallel or later branches is not separately established by the record; do not infer coverage beyond the stated boundaries.

The miniOrange OAuth Single Sign On, SSO (OAuth Client) WordPress plugin contains an authentication bypass by spoofing weakness classified as CWE-290. The supplied assessment describes a remotely reachable request that does not require authentication or user interaction and can bypass the plugin's security checks. The public record does not identify the affected endpoint, OAuth parameter, callback, or specific validation that fails, so the exact implementation mechanism and affected OAuth flow remain unknown. The practical result depends on the permissions and services connected to the plugin in each WordPress deployment.

The vulnerability is reachable over the network and requires no account, initial privileges, or user interaction; the recorded attack complexity is low. The supplied record does not identify a public exploit or a specific exploitation campaign. CISA enrichment in GCVE records exploitation as none at the time of that enrichment, but this does not establish that exploitation has never occurred or will not occur later. No named campaign, victim, or specific IOC is provided by the available evidence.

A successful attack could allow an unauthenticated actor to bypass the plugin's login validation. Possible consequences include exposure of protected data, unauthorized changes to data or content, and service disruption, depending on the permissions granted in the deployment. The recorded scope is unchanged, but the final effect on the website and connected systems depends on local configuration. The record does not establish that any data was actually accessed or modified.

An authentication bypass could provide unauthorized access to WordPress resources or data exposed through the plugin. Depending on the permissions granted by the linked sign-on flow, an attacker could potentially read data, change content or configuration, or disrupt service. Because the affected endpoint and exploit sequence are not described, organizations should not assume that every deployment has the same practical impact. The available record does not establish a specific compromise or data breach.

1. Update the WordPress OAuth Single Sign On, SSO (OAuth Client) plugin to version 7.1.3, which is identified as fixed.
2. After updating, verify the effective version on every site and confirm that no affected installation remains in the plugin directory or centralized management system.
3. If immediate updating is not possible, apply Patchstack's mitigation rule to block the relevant requests while the update is pending. This is temporary protection and does not replace the update.
4. Review accounts, content, configuration changes, and OAuth authentication activity since the plugin was installed or last upgraded.
5. The record provides no specific developer configuration workaround, so do not infer endpoint, parameter, or source-code changes as a fix.

1. Inventory WordPress sites that install the miniorange-login-with-eve-online-google-facebook package.
2. Check the installed plugin version and identify deployments within the affected scope described in affected_summary.
3. Confirm that the plugin has been updated to the fixed version and verify the effective version in the WordPress administration interface or centralized plugin-management tooling.
4. Review WordPress access logs, OAuth authentication logs, and administrative activity for unauthorized requests, unusual logins, account changes, or content changes. Treat this as precautionary monitoring, not as a known indicator.
5. Do not treat the absence of suspicious log events as proof of safety; the record provides no specific log pattern or indicator of compromise.