miniOrange login plugins need 7.8.1 — and the numbering differs

Two login-integration plugins from "miniOrange," widely used on WordPress sites to let people log in with external accounts like Google, have serious flaws that could let a third party who is not logged in take over the site's administrator account. The identifiers are CVE-2026-12761 and CVE-2026-57807, and both carry a severity of 9.8 out of 10, in the top tier.

Both are "authentication bypass" flaws, where a gap in the identity-verification mechanism lets an attacker impersonate a legitimate user or administrator. Exploitation requires no login, and once administrator rights are seized, the whole site can be taken over. Affected are miniOrange's "Social Login and Register" up to 7.7.0 and "OAuth Single Sign On - SSO" up to 38.5.8, and the vendor has already released fixes. If your site uses either, update to the latest version right now.

What are miniOrange's login-integration plugins

miniOrange is a company that offers many login- and authentication-related extensions (plugins) for WordPress. A plugin is a part that adds functionality to WordPress after the fact. The two at issue here both exist to "let users log in with an external account they already have — Google, Discord, LinkedIn, and so on — instead of creating a site-specific ID and password."

"Social Login and Register" provides social login via Google, Twitter, Discord, and others, while "OAuth Single Sign On - SSO" provides single sign-on (logging in once to use multiple services) integrated with internal systems or external authentication services. Because the job of both is to verify "you are who you say you are" and let you log in, a hole there turns impersonation directly into unauthorized login. Flaws that strike at the login foundation are targeted repeatedly, as with the takeover in ManageEngine's identity product and the authentication bypass in the login platform Casdoor.

What is dangerous, and how far can the damage spread

Both are flaws specialists call "authentication bypass (Improper Authentication)." Login should strictly verify confirmation codes, email verification, responses from external services, and the like, confirming "this really is the right person" before letting them through. But in these two, that verification is too loose, letting an attacker log in as another user or as an administrator without following the proper steps. The U.S. National Institute of Standards and Technology (NIST) classifies these as improper authentication (CWE-287) and authentication bypass via an alternate channel (CWE-288).

What is especially serious is that the administrator account can be seized. A WordPress administrator holds nearly full control of the site — not just editing posts and pages, but installing plugins, executing code, and managing other users. Once seized, the attacker can do virtually anything: deface pages, exfiltrate member data, plant malicious programs, even launch further attacks using the server as a springboard. Exploitation requires no login; the attacker just sends crafted requests to the public login feature. The severity of 9.8 reflects the fact that an administrator can be seized without any special privileges or user action.

Login-integration plugins are used on many sites as the entry point for member registration and account pages. That is exactly why a breach there has broad impact, and moreover attackers can automatically hunt for vulnerable sites and target them indiscriminately. Social login is convenient, but because the authentication exchange with external services is complex, loose verification can easily become fatal.

Who targets these holes, and what happens

The likely exploiters are attackers who deface sites to use as springboards for fake pages and spam, and attackers who seize administrator rights to plant malware and steal members' personal data. Because it can be done without even logging in, they automatically hunt for vulnerable miniOrange plugins and attack them en masse once found. Sites left un-updated after being outsourced make especially easy targets.

The flow of attack goes like this. Attackers exploit the loose parts of identity verification — confirmation codes, email verification, password recovery — to log in as an administrator without following the proper steps, and seize control of the site. The technical details are below, but all it takes is a few requests, with no click or action required from the victim.

As a result, the individuals and businesses running the sites have their admin panel hijacked, their public pages defaced, or the personal data of registered members stolen wholesale. A hijacked site is turned, without the owner's knowledge, into a base for phishing or malware distribution, and visitors can be harmed too. The more a site relies on member registration, the more personal data it holds and the more serious the damage — a pattern shared with the takeover vulnerability in UsersWP, which struck WordPress's membership feature.

What is happening from a technical standpoint

Each of the two flaws, reported in succession, has an identifier assigned.

CVE-2026-12761: Social Login and Register, admin takeover via loose confirmation-code and email verification (severity 9.8)

In "Social Login and Register (Discord, Google, Twitter, LinkedIn)," the validation of the one-time code (OTP, a disposable confirmation number) used for identity verification at login, and the email-address check, are loose, letting an attacker exploit this to establish a legitimate login as someone else — and as an administrator. No login is required (no privileges needed), and no user action either. NIST classifies this as improper authentication (CWE-287). Affected are versions up to 7.7.0, and this flaw itself was closed in 7.8.0. A separate flaw affecting 7.8.0 and earlier was disclosed afterwards, so the version to update to is 7.8.1.

CVE-2026-57807: OAuth SSO, authentication bypass abusing an alternate password-recovery channel (severity 9.8)

In "OAuth Single Sign On - SSO (OAuth Client)," by abusing a channel separate from the intended login flow (the password-recovery mechanism), authentication can be bypassed entirely. An attacker can enter the site impersonating another user or an administrator without a legitimate login. No login is required. NIST classifies this as authentication bypass via an alternate channel (CWE-288). Affected are versions up to 38.5.8, fixed by the vendor in 38.5.8.1. Those numbers belong to the paid build, so they cannot be compared against what your admin panel shows — see the next section. The targeting of "side paths outside the main flow" of authentication also echoes the vulnerability in the login platform authentik.

"Up to 38.5.8" cannot be compared with your admin panel's number

The easiest thing to misread here is CVE-2026-57807's "affected up to 38.5.8, fixed in 38.5.8.1." Those numbers come from miniOrange's paid build, which is numbered on an entirely separate scheme from the free build distributed on wordpress.org. Two numbering lines exist behind one product name, "OAuth Single Sign On - SSO."

The paid build's slug that the advisory points to (miniorange-oauth-oidc-single-sign-on) does not exist on wordpress.org — opening that address just redirects to a search page. The free build on wordpress.org (slug miniorange-login-with-eve-online-google-facebook) currently sits at 7.0.0 (updated July 23, 2026), and no 38.x number appears anywhere in its release history.

So seeing "7.0.0" in your admin panel and concluding "that's below 38.5.8, so I'm affected" is wrong. The reverse — "my number is higher, so I'm safe" — does not hold either. When the schemes differ, comparing magnitudes means nothing. There is only one test that works: is the version you are running the newest one from wherever you got it?

Telling them apart is easy. Open "Plugins" in the WordPress admin panel and see whether an update notice appears for this product. If one does — that is, if it updates from wordpress.org — you are on the free build. The paid build does not go through wordpress.org, so you fetch its latest version from your miniOrange account. Either way the job is the same: get to the newest version from your own source.

Affected versions and countermeasures

The affected versions, and the version to move to, are as follows. Because an administrator can be seized without authentication, update with top priority if you are affected.

As a stopgap if you cannot update immediately, temporarily disabling the affected plugin or temporarily pausing login with external accounts can narrow the entry points. But these are only time-buying measures; fundamentally you need to update to the latest version. It is also reassuring to check whether any unfamiliar administrator accounts have been added.

What is confirmed, and what is still unknown

What you can do right now

The core countermeasure is clear. The top priority is to update Social Login and Register to 7.8.1, and OAuth Single Sign On - SSO to the newest version of whichever build you run. Check for updates from the WordPress admin panel and apply them. Because it can be exploited without authentication to seize an administrator, every bit of delay lengthens your time at risk. For OAuth SSO, holding the advisory's "38.5.8" next to your admin panel's number settles nothing — go by whether an update notice is showing, not by which number is larger.

Around the time you update, it is also reassuring to check whether you have already been taken over. See whether unfamiliar administrator accounts have been added, whether unfamiliar code has been planted in plugins or themes, and whether public pages have been defaced. If worried, consider restoring from a backup or consulting a security professional. Deleting unused plugins and keeping only active ones up to date is the basic principle for protecting WordPress. Flaws in login plugins, like the vulnerability in the form builder Super Forms, recur especially in parts that receive external input.

Frequently asked questions

Summary

This case is about how two miniOrange login-integration plugins, widely used on WordPress sites, could let a third party who is not logged in take over the administrator account due to loose identity verification. Both CVE-2026-12761 and CVE-2026-57807 can be exploited without authentication or user action, at a top-tier severity of 9.8. Because they strike at the login foundation, a breach spreads to member-data leaks and site defacement.

The saving grace is that the vendor has already released fixes. Simply updating Social Login and Register to 7.8.1, and OAuth Single Sign On - SSO to the newest version of your build, prevents it. For the latter, the advisory's "up to 38.5.8" is the paid build's numbering, so do not compare it against your admin panel's number. Working on the assumption that plugins handling login and authentication cause especially large damage when breached, it is worth making frequent updates and checks for suspicious administrator accounts a habit. If there is any new sign of exploitation, we will report it again.

References

• ▸ NVD - CVE-2026-12761 (Social Login and Register)
• ▸ NVD - CVE-2026-57807 (OAuth Single Sign On - SSO)
• ▸ Patchstack - miniOrange Social Login vulnerability database
• ▸ wordpress.org - miniOrange Social Login and Register (current release 7.8.1)
• ▸ wordpress.org - OAuth Single Sign On - SSO, free build (current release 7.0.0)