J2Store 3.3.22, 4.0.22 and 4.1.7 fix five flaws we reported

J2Commerce published a security release for the J2Store Joomla extension on 31 August 2026, fixing five vulnerabilities in com_j2store. We found and reported all five, and the vendor credits mySites.guru in its advisory. The fixed builds are 3.3.22 on the Joomla 3 branch, 4.0.22 on 4.0.x and 4.1.7 on 4.1.x, all published the same day.

The timing is the awkward part. J2Commerce shipped its previous security release ten days earlier, on 21 August, closing six unrelated flaws found by other researchers. Anyone who patched then did exactly the right thing and is still exposed, because 3.3.21, 4.0.21 and 4.1.6 are all affected by this second set.

TL;DR

TL;DR: Five vulnerabilities in the J2Store Joomla extension, all reported by mySites.guru, are fixed in 3.3.22, 4.0.22 and 4.1.7. Three need no login: an anonymous PayPal callback could confirm an unpaid order or fail a real one (8.7), an anonymous request could insert or overwrite any customer’s cart record (8.8), and a crafted link fired script through the product-tags filter (5.3). One needed only an ordinary customer account and returned a guest checkout customer’s name, address and phone (7.1). The worst, scored 9.4, needed only a Joomla backend login of any kind, with no J2Store permission whatsoever, and reached table truncation and traversal-based SQL file execution. Every build below the fix for its branch is affected, including the 21 August security release. The five CVE ids are reserved with the Joomla CNA but not yet published, so these scores are the vendor’s. If you manage Joomla shops, mySites.guru already flags every connected J2Store install below the fix version for its own branch.

What the Five J2Store Flaws Actually Were

All five sit in com_j2store and all five affect every supported branch, because the vulnerable code is shared between them. Ordered by the vendor’s own scoring:

Two of these are worth more than a table row, because the mechanism behind each one is a mistake that is easy to repeat in any Joomla extension.

Any Joomla Backend Login Could Truncate the Store’s Tables

The 9.4 is an authorization check that was never written, sitting behind a framework default that opens rather than closes.

J2Store’s administrator Apps controller accepts an appTask parameter and delegates the work to an app-plugin controller. Nothing along that delegation path checks whether the caller holds any com_j2store permission. That would still be survivable if the framework refused unmatched tasks, but the component’s fof.xml has no <view> ACL entries under its <backend> node at all, and with nothing declared the framework’s default for an unmatched task is allow.

The practical result is a privilege escalation with an unusually low starting point. The only thing standing between an anonymous visitor and this code is Joomla core’s administrator login wall, which is doing its own job and knows nothing about com_j2store permissions. Once any account is through that wall, for any reason, it could reach #__j2store_* table truncation and traversal-based execution of SQL files. An account you created so a client could manage their events calendar was enough to wipe their shop.

The PayPal Callback That Verified Nothing

The 8.7 is the one a shop owner feels in the accounts rather than in the logs.

J2Store’s PayPal IPN listener is supposed to call PayPal back, ask whether a payment notification is genuine, and act on the answer. Before the fix it did three things that each defeated that on their own. It treated an UNVERIFIED response, and in fact anything that was not literally INVALID, as valid. It made the verification request with CURLOPT_SSL_VERIFYPEER disabled. And it stored the verdict in a field that nothing downstream ever read, so order processing continued regardless of what came back.

The amount check had a separate hole. The comparison between what was paid and what was owed only ran when mc_gross arrived as a positive number, and floatval(null) is 0, so simply leaving that field out of the callback body skipped the check completely.

Put together, an unauthenticated request to the callback endpoint could confirm an order that nobody paid for, or push a genuine customer’s paid order into a failed state. If you ran an affected build with PayPal enabled, that is the thing worth auditing before you move on: orders that changed to CONFIRMED or FAILED with no matching PayPal transaction behind them.

Which J2Store Versions Are Affected?

Every build below the fix version for its own branch, on all three branches. There is no lower bound worth quoting, because the vulnerable code predates every version anyone is realistically running.

J2Commerce 6 is a separately rewritten codebase for Joomla 6 and is not covered by this advisory.

The three fixed builds are worth staring at for a second, because they are the reason a lot of tooling will get this wrong.

Why One Version Range Cannot Cover J2Store’s Three Branches

4.0.22 and 3.3.22 both sort below 4.1.7. So the obvious rule, “anything below 4.1.7 is vulnerable”, tells a Joomla 3 shop that correctly installed 3.3.22 that it is still at risk, and keeps telling it that through every future scan, because no build on that branch will ever climb above 4.1.7. The site owner then either ignores the warning or goes looking for an update that does not exist for their branch.

This is not hypothetical for us. It is why the J2Store entries in our Joomla vulnerability rules are three rules rather than one, split on branch boundaries that cannot overlap:

below 3.3.22                 -> Joomla 3 branch
4.0.0 and above, below 4.0.22 -> 4.0.x branch
4.1.0 and above, below 4.1.7  -> 4.1.x branch

We learned that the expensive way on a different extension. Convert Forms fixed one flaw in 4.4.16 for Joomla 3 and 5.2.3 for Joomla 4 and up, and a single range written across both told thirty correctly patched sites they were vulnerable until a customer told us otherwise. Any vendor maintaining a Joomla 3 branch alongside a modern one produces the same trap, and J2Store maintains two of them.

How Do I Find Every Affected J2Store Install?

By hand it means logging into each Joomla site, opening the extensions list, reading the J2Store version, working out which branch it belongs to and comparing it against the right one of three targets. For one shop that is five minutes. For an agency with thirty Joomla sites it is the kind of job that gets postponed, which is precisely what the numbers below show happening.

With mySites.guru, every connected Joomla site reports its full extension inventory, so J2Store installs across the whole account list on one screen with their versions. The three branch rules for this advisory are live now, alongside the three for the 21 August release, so an affected shop is flagged with the fix version for the branch it is actually on rather than the highest number in the advisory. If you want to see that against your own sites before paying for anything, the free audit covers it.

What the Connected J2Store Stores Actually Look Like

This is the part we can measure and most write-ups cannot. Across the Joomla sites connected to mySites.guru that run the J2Store component and reported a readable version in the last thirty days:

The 74% is the figure that should bother anyone running a Joomla shop. Three quarters of the affected stores are not one security release behind, they are two: still below the 21 August build that fixed an unauthenticated file upload the vendor confirmed had already been exploited in the wild. Those shops did not miss this advisory. They missed the last one too, and this one arrived before anybody noticed.

That pattern is why an extension inventory beats a mailing list. A shop owner reading a vendor advisory has to already know they run the extension, already know which branch, and already be reading. An inventory does not require anyone to be paying attention on the day.

Was Any of This Being Exploited?

We have no evidence of exploitation of these five before the fix shipped, and no proof of concept has been published for any of them. This post deliberately describes mechanisms rather than requests.

The honest caveat is that four of the five leave very little behind. A guest address read through the address editor looks like an ordinary page view. A cart row inserted anonymously looks like a cart row. The one that does leave a trace is the PayPal callback, because the order state changes, so that is the one to go back through if you ran an affected build with PayPal enabled.

The 21 August release is a different matter, and worth restating for the three quarters of shops still below it: the vendor confirmed that the file upload flaw in that set had been exploited in the wild before the patch shipped. If a shop is on 3.3.20 or below, 4.0.20 or below, or 4.1.5 or below, treat it as needing a look rather than just an update. Our guide to checking a Joomla site’s database and file integrity covers what to review.

Credit Where It Is Due

Two things J2Commerce did here are worth saying plainly, because plenty of vendors do neither.

They patched the Joomla 3 branch on the same day as the modern ones. J2Store’s users skew heavily toward Joomla 3, as the 68% above shows, and a vendor who fixes only the current branch effectively strands most of their install base. J2Commerce has now done the simultaneous three-branch release twice in ten days.

They also named the reporter. The advisory credits Phil Taylor of mySites.guru with discovery and responsible disclosure of all five issues, and thanks the Joomla Security Strike Team. We have written before about what a good Joomla extension disclosure looks like, and about vendors who shipped our fixes without ever saying where they came from. This one is on the right side of that line.

The five CVE ids are reserved with the Joomla CNA. When the records publish, the scores and affected ranges quoted here may shift, and we will update this post if they do.