A CVSS 10.0 Account Takeover in miniOrange OAuth Client for Joomla, Fixed in 3.2.0

The miniOrange OAuth Client extension lets a Joomla site use an external OAuth provider to log its users in. Every version below 3.2.0 carries a flaw that needs no login, no account and no help from anyone on the site. It is scored CVSS 10.0, the maximum, and it ends with an attacker sitting in your Joomla administrator account.

What the flaw is

The extension works out who a visitor is from a cookie value. That value is set on the visitor’s own machine, so the visitor controls it completely. Change it to name a different account and the extension logs you in as that account. Name an administrator and you are an administrator, with no password and nothing to bypass, because there was never a check to bypass in the first place.

If that sounds familiar, it should. It is the same shape of flaw we found in Gridbox for Joomla back in July, where setting a single cookie, gridbox_username=admin, logged a visitor straight in as a Super User. Trusting a value the browser sends to decide who someone is has a name, improper authentication, and it keeps turning up in Joomla extensions because a cookie reads like server-side state right up until you remember the browser is the thing that writes it.

The Joomla record for this is CVE-2026-77995, published on 24 August 2026 by the Joomla project as the CNA, and credited to Krzysztof Zając of CERT PL. Its own summary is blunt: “The manipulation of a cookie value allows actors to login as arbitrary accounts, including admins.” The affected range is 1.0.0 up to and including 3.1.9, and the fix is 3.2.0.

What to do

Update the miniOrange OAuth Client extension to 3.2.0 or later on every Joomla site that runs it.

Read the version number carefully when you check. miniOrange ships several separately numbered editions of its extensions, so a site showing a two-digit version is not automatically running something newer than 3.2.0. If you cannot tell which edition and version a site is on, treat it as affected until you have confirmed it sits on a fixed release.

If you cannot update a site straight away, disable or remove the extension rather than leaving it in place. An extension that hands out administrator sessions to anyone who asks is worse than no OAuth login at all for the short time it takes to patch.

Then, because the flaw hands out administrator access, check the site was not already used. Look at your Joomla user list for administrator or super user accounts you do not recognise, and at accounts created or changed recently. Check the Joomla action logs and your web server logs for administrator sessions from IP addresses that are not yours. If anything looks off, treat the site as compromised and clean it properly rather than only updating the extension.

The part worth remembering

Days before this Joomla record appeared, the same vendor was in the WordPress security news for two critical unauthenticated authentication bypasses in its SAML Single Sign On plugin, both letting an attacker forge their way into /wp-admin as any user. Different extension, different platform, but the same vendor and the same underlying idea: an authentication extension trusting a value the attacker gets to set. That write-up is worth reading in full, not least for the way one WordPress listing turned out to hide seven separately versioned editions, which is the same version-numbering trap to watch for on the Joomla side.

We saw the WordPress write-up, thought the vendor’s Joomla extensions deserved the same scrutiny, and said so to the Joomla Security Strike Team. Within days a Joomla account-takeover record for the same vendor was public. We cannot claim the two are directly connected, and the credit for finding this one belongs to CERT PL, not to us. But the lesson stands on its own: when one vendor ships a trust-the-client authentication flaw on one CMS, its extensions on the other CMS are worth checking straight away, rather than waiting for a separate disclosure to arrive on its own schedule.

There is a bigger version of this problem sitting behind the specific one. Plenty of extensions ship in both a WordPress and a Joomla edition, built by the same vendor from broadly the same ideas, and it is almost always the WordPress side that gets the security news first. Not because WordPress is more exposed, but because WordPress has Patchstack and Wordfence: funded projects whose whole job is to find these flaws, coordinate the disclosure with the vendor, and push the alert out to the people running the software. Joomla has no equivalent. When a Joomla extension is fixed quietly, there is often nothing between the vendor’s changelog and the next hacked site. So the Joomla edition of a shared flaw tends to arrive later, with less noise around it, on sites whose owners never saw the WordPress headline that would have warned them.

That gap is a good part of why we write these up at all, and why we check a vendor’s Joomla extensions the moment its WordPress ones make the news. We track known security issues across every extension on every site we monitor, because a single vendor’s mistake rarely stays inside one product or one platform, and the sites that get hurt are the ones where nobody was watching the version numbers.

The score

Further Reading

• CVE-2026-77995 at CVE.org, the authoritative record for this flaw
• One slug, seven editions: the miniOrange SAML SSO bug, the WordPress disclosure that prompted the Joomla check
• CWE-287: Improper Authentication at MITRE
• The Joomla Security Strike Team’s vulnerable extensions list