Three CVEs in miniOrange Extensions for Joomla, All Now Fixed

Start here: which of the three applies to you

The three records scope themselves differently, which is the single most confusing thing about this whole episode. One covers free and paid alike, one is free-only by design, and one has never said what it does to paid customers. So before any of the detail below, work out which line you are on and read one row.

Step 1: are you on a free or a paid build?

The leading digit of the version number tells you, because with miniOrange it identifies the edition, not the age. A one or two segment number in the low range (3.0.2, 6.4, 11.0.2, 1.2.2) is the free edition. Anything in the tens is paid: the 10s are Basic, the 20s Standard, the 30s Premium and the 40s Enterprise. A site reporting 32.0.2 is a Premium build, not something newer than 3.2.0.

Step 2: read your row

The rest of this post is how each record got to that state, in the order it happened, including the two days when a paid install checked against the SAML record was wrongly told it was fine.

The first flaw: CVE-2026-77995 in the OAuth Client

The miniOrange OAuth Client extension lets a Joomla site use an external OAuth provider to log its users in. Every free version below 3.2.0 has 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 about the account takeover

Update the miniOrange OAuth Client extension on every Joomla site that runs it. 3.2.0 is what closes this record, but install 3.2.1 or later instead: the third record below affects 3.2.0 as well, and 3.2.1 closes both.

Read the version number carefully when you check. miniOrange ships the same extension as several separately numbered editions, and the leading digit is the edition, not the age: the 20s are Standard, the 30s are Premium, the 40s are Enterprise. A site showing 32.0.2 is not running something newer than 3.2.0, it is a Premium build. miniOrange have told us the paid OAuth editions were never affected, which is why no fixed build exists for them, though that rests on their assessment rather than on the record.

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 second flaw: CVE-2026-77998 in SAML SSO

On 25 August 2026 the Joomla CNA published a second record against the same vendor: CVE-2026-77998, an unauthenticated authentication bypass in miniOrange SAML SSO for Joomla, scored CVSS 4.0 10.0. This one is a different extension from the OAuth Client above, and if you use miniOrange for SAML single sign-on it matters more to you than the OAuth flaw does.

What goes wrong

PHP’s openssl_verify() does not answer yes or no. It answers one of three things: 1 if the signature is valid, 0 if it is not, and -1 if OpenSSL could not complete the check at all. That third answer is the trap. The extension tests the result as though it were a plain true or false, and in PHP -1 is true.

So an attacker does not need to forge a valid signature. They need to send one broken enough to make OpenSSL give up. They post a SAML response naming whichever account they like, attach a signature value engineered to trigger an OpenSSL error, and the extension reads the resulting -1 as “signature verified”. It then logs them in as the account they named. A Super User account is as easy to name as any other. There is no login step, no credential to guess and nothing for anyone on the site to click.

It is the same shape of mistake as the OAuth flaw above, just one level further in. The OAuth Client trusted a value the browser sent. The SAML extension does check a signature, but then misreads what the check told it, which gets to the same place.

It is already being used on WordPress

This is not a bug sitting in a database waiting for someone to notice it.

miniOrange build the same single sign-on product for WordPress, where the identical misreading of openssl_verify() is tracked as CVE-2026-15981. Patchstack report that it is being exploited, chained with a second flaw in the same plugin. DigitalOcean caught an unrecognised WordPress administrator session on 16 August, attempts and opportunistic scanning are coming from six addresses across Europe, Africa and the United States, and a working proof of concept is public.

The Joomla record is new enough that we have seen no reports of it being attacked. We would not read much comfort into that. The vendor builds both editions from the same ideas, the mechanism is now described in public on both platforms, and attackers already have working code for one of them.

What happened next on the WordPress side is the part worth sitting with, because it is about to be the Joomla story too. Both flaws were fixed back in July. The vendor’s advisory covered only the free edition, so customers on the six paid editions were never told they were affected, and their WordPress dashboards showed no update prompt because paid editions do not update through the plugin directory. Plenty of them did nothing, reasonably enough, because nothing told them to. Those are the sites now being broken into. The bug was patched for a month before anyone got hurt by it, and the patch is not what failed.

The version numbers do not line up

The CVE record says the fix is version 11.0.2, with 6.4 given for the ADFS and Google Apps editions. Joomla sites running this extension do not report versions that look anything like that. Real installs report 9.7, 10.8, 11.2, 22.7, 32.7, 42.5, 42.6, 44.0, 44.1 and similar. Until the day this record was published we had never seen a single site reporting 11.0.2 at all. One has since updated to it.

miniOrange ships the same underlying extension as several separately numbered editions, which is the problem Patchstack documented on the WordPress side under the title One slug, seven editions. Their write-up was about exactly this: the bug was fixed, but a large number of sites and enterprise customers had no way of working out whether their build was one of the fixed ones. That same trap has now arrived on the Joomla side.

A site reporting version 44.0 is not “newer than 11.0.2”. It is on a different numbering scheme, and for two days nobody outside miniOrange could say whether it was fixed. So we asked them. Their first answer settled the free editions and left the paid ones exactly where they were. Their second, thirty hours later, finally gave the paid editions a number. The rule survives both: do not read a big version number as reassurance.

What miniOrange told us

On 25 August we put a narrow question to miniOrange through their own support form: for Joomla, what are the exact fixed versions of each of your products affected by this round of vulnerabilities?

They answered the next morning, which is already more than the WordPress side got. Nutan Barad of miniOrange sent this table, prefaced with five words that matter as much as the numbers do: “All are the free versions.”

Three things are worth pulling out of that.

The first is that it confirms both CVE records. The 11.0.2, 6.4 and 3.2.0 figures match what the Joomla CNA published, so if you are on a free edition you now have a number you can act on with some confidence behind it.

The second is that three of those extensions were, at the time, fixed with no CVE at all. The Azure AD, Keycloak and Educational Institutes editions are each given as fixed in 1.2.2, and on 26 August neither published record mentioned any of them, so anyone running one had no advisory to be warned by. That has since been put right: the revision to CVE-2026-77998 later the same evening added all three, at an affected range of 1.0.0 to 1.2.1. They are named again in CVE-2026-78074, where the number moves on to 1.2.3.

The third is the one that mattered most, and it was the sentence above the table rather than anything in it. Every version quoted is for the free edition. The paid editions, the ones on that two-segment numbering line, were left unanswered.

So a site reporting 42.6 or 44.0 was exactly where it had been before we asked. We had read the vulnerable code in a live install on the 42.x line, where the tri-state openssl_verify() return was still being tested for truthiness, so that build was affected and its owner still had no version number to compare themselves against.

That was the WordPress story arriving on Joomla almost word for word. Both WordPress flaws were fixed back in July, the vendor’s advisory covered only the free edition, the paid editions were never told, and those are the sites that got broken into.

So we went back to miniOrange and asked for the paid-edition build numbers.

The paid editions, answered

That gap lasted about thirty hours.

At 12:07 on 26 August, miniOrange emailed its paying Joomla customers directly, under the subject “Urgent! Critical fix released for miniOrange Joomla SAML SP Plugin. Update Now!”. This time the numbers were the ones the free table left out:

David Jardin of the Joomla Security Strike Team posted the same four numbers publicly half an hour later, so this does not rest on a single forwarded email.

Those four rows decode the whole thing. The leading digit is the edition, not the age. A version in the 40s is an Enterprise build, the 30s are Premium, the 20s are Standard, and the low numbers are Basic or free, which share that range. A site on 44.0 was never “newer than 11.0.2”. It was an Enterprise build two releases behind its own line’s fix. Read that way, every version we have seen in the wild falls into place: 22.7 is a Standard build needing 24.2, 32.7 is a Premium build needing 34.2, 42.6 and 44.1 are Enterprise builds needing 44.2.

One of the two gaps has closed

The CVE record moved the same evening. At 22:35 UTC on 26 August, hours after we published the complaint above, CVE-2026-77998 was revised to describe the paid line: SAML SSO Basic affected to 13.1.0, Standard to 24.1.0, Premium to 34.1.0 and Enterprise to 44.1.0, alongside the ADFS and Google Apps editions at 6.3.0 and the three OIDC extensions at 1.2.1. An automated check reading that record now flags a site on 34.1 correctly, which is the outcome that matters. We are spelling that out because the version of this post you may have read a week ago said the opposite.

The paid OAuth Client editions, answered by the vendor

That left one question outstanding for eleven days, and we put it to miniOrange twice. Joomla sites report com_miniorange_oauth versions such as 13.0.0, 21.0.1, 32.0.0, 32.0.2 and 34.0.0, which on the scheme above are Basic, Standard and Premium builds, and the only fixed versions ever published for that extension are the free 3.2.0 for CVE-2026-77995 and 3.2.1 for CVE-2026-78074.

On 4 September miniOrange answered it. Their position is that CVE-2026-77995 “was associated only with the free version of the OAuth Client plugin”, that their investigation “confirmed that the vulnerability was not present in any version of the paid OAuth plugins”, and that this is precisely why no paid security build and no customer communication ever followed. On that account there was never a gap to close: the paid editions were not affected, so there was nothing to publish.

What to do about the SAML bypass

If your site runs a free edition, do not use the 26 August table above as your target. Those numbers close this record and have since been superseded by CVE-2026-78074, so updating to 11.0.2, 6.4 or 1.2.2 today leaves the third flaw open. Go to the table of 23 and take the number there, which closes both.

If it runs a paid SAML SP edition, update it to 13.2, 24.2, 34.2 or 44.2 according to your plan, reading the leading digit of your current version to work out which line you are on. That is the end of it for you, because CVE-2026-78074 does not touch the paid editions.

If your site runs a paid OAuth Client edition, miniOrange say there is nothing for you to do, because the flaw was never in a paid build. There is therefore no number to install. Read what that answer rests on before treating the question as shut.

In the meantime, if the site can function without it, disable or remove the extension. An SSO extension that will log an anonymous visitor in as an administrator is worse than no SSO for the day or two it takes to get a straight answer. If you cannot remove it, restrict access to the Joomla administrator area by IP or by network while you wait.

Then check whether it has already been used, the same way as for the OAuth flaw: unfamiliar administrator or Super User accounts, recently created or modified users, and administrator sessions in your logs from addresses that are not yours.

The third flaw: CVE-2026-78074, an unauthenticated uninstall

On 31 August 2026 the Joomla CNA published a third record against the same vendor, CVE-2026-78074, and it names 23 miniOrange extensions rather than one. Krzysztof Zając of CERT PL found this one too.

This one is a different class of flaw from the two above. A miniOrange endpoint is missing its authentication check, so an unauthenticated visitor can tell the site to uninstall an extension, and the site does it. Any extension, not just a miniOrange one.

Why an uninstall is worse than it sounds

An uninstall does considerably more than switch the extension off. Joomla runs the extension’s own uninstall script and drops the database tables that go with it, so the content and configuration held in those tables goes too, and no amount of reinstalling brings it back without a backup. Point that at a forum, a shop or a form builder and the damage is measured in whatever the last backup missed.

The second-order problem is what an attacker would aim it at first. Nothing restricts the target to the vendor’s own extensions, so a two-factor plugin, an admin-IP restriction, a security extension or a login handler can all be removed by someone with no account on the site. That is a useful thing to do immediately before trying something else.

The record scores it CVSS 4.0 8.8 High under CWE-284: Improper Access Control, below the two 10.0 records above it, and the vector says why: VC:N, no confidentiality impact. The attacker destroys, it does not read.

The 23 extensions and what fixes each

miniOrange released the fix for all of these on 31 August 2026, with Two Factor Authentication following on 1 September. We checked every number below against the extension’s own Joomla Extensions Directory listing rather than accepting the vendor’s list, and the release dates match.

Only the free editions are affected. The CVE says so in its own description, every range it publishes stops on the free numbering line, and miniOrange confirmed it to us in writing. Paid builds on the decade numbering, the 12.x, 21.x, 32.x and 44.x versions, are outside this record.

What to do about the uninstall flaw

Update every miniOrange extension on the site to the version in the table, not just the one you were told about last time. The extension inventory is the quickest way to see which of the 23 you actually run and at what version, because several of them install under a display name that does not match the name in the CVE: the Restrict Files extension reports itself as the Joomla Content Access Manager, and the OAuth Client, the OAuth Server and the Azure AD extension all share one element and are told apart only by that name.

If an extension is installed but not actually used, remove it rather than updating it. Several of these turn up on sites that trialled a single sign-on option years ago and left the component behind, and an unused component is a live endpoint regardless.

Where you cannot update immediately, block unauthenticated access to the component’s endpoints at the firewall or in the web server. Unlike the two bypasses above, there is no compromise to hunt for afterwards. If this one was used against a site you would know, because something would be missing.

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 on 21 August, thought the vendor’s Joomla extensions deserved the same scrutiny, and forwarded it to the Joomla Security Strike Team that evening. Four days later there were two Joomla records. The OAuth one, CVE-2026-77995, was found by CERT PL and the credit there is theirs. The SAML one, CVE-2026-77998, is credited to us alongside Supakiad S. (m3ez). The lesson is the one we acted on: when a 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, 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 scores

CVE-2026-77995, miniOrange OAuth Client

CVE-2026-77998, miniOrange SAML SSO

CVE-2026-78074, 23 miniOrange extensions