Six more J2Store flaws fixed in 3.3.23, 4.0.23 and 4.1.8

J2Store is one of the most widely installed e-commerce extensions for Joomla, turning ordinary Joomla articles into shop products. In August 2026 J2Commerce fixed five vulnerabilities we reported, across all three supported branches, and published them as CVEs crediting mySites.guru. This post is the second round. Reviewing that fix release turned up six more issues, all reported privately to J2Commerce, all assigned CVE identifiers by the Joomla CNA, and all fixed this morning in J2Store 3.3.23, 4.0.23 and 4.1.8.

The one that matters most needs no login at all: a blind SQL injection in the public product list that reads the shop’s entire database. Every supported branch is affected, so whichever version of Joomla your shop runs, it needs updating today. If you manage more than a handful of shops, read on for how to find every affected one at once.

TL;DR

• mySites.guru found six more security issues in J2Store and reported them privately to J2Commerce. All six are fixed in 3.3.23 (Joomla 3), 4.0.23 (Joomla 4) and 4.1.8 (Joomla 5 and 6)
• Unauthenticated blind SQL injection, scored 8.7 High. The storefront product list reads a filter value from the request without quoting it and concatenates it into a database query. No login, no CSRF token: an anonymous visitor reads the whole database one character at a time, the Super User password hash included
• Arbitrary file read through the download handler, also 8.7 High, returning files from outside the shop’s folders including configuration.php
• An anonymous request that can mark any order as Failed, 8.7 High, plus incomplete CSRF protection across the checkout and profile controllers at 7.1 High, a forgeable order access token at 6.3 Medium, and unescaped request data in the PayPal notify redirect at 5.3 Medium
• Check your checkout overrides before updating. The fix adds an anti-CSRF token to the cart, checkout and profile forms, so custom overrides and add-ons that ship their own copies of those templates need the same token or they return an Invalid Token error
• J2Commerce reports no evidence that any of the six were exploited on a live store
• mySites.guru already flags every connected Joomla shop still running a vulnerable version

Which version you need

Every supported branch is affected, and each has its own fix. The branch you are on follows from your Joomla version rather than from anything you chose:

One thing to check before you update a live shop. The CSRF fix adds an anti-CSRF token to the cart, checkout and my-profile forms, which means any custom template override, or any third-party add-on shipping its own copies of those templates, needs the same token adding to its own forms. J2Commerce names Easy Checkout specifically. Until those are updated to match, the affected actions produce an Invalid Token error for real shoppers, so a shop with heavily customised checkout templates wants a staging run rather than a Tuesday-afternoon click on Update.

The worst one: an anonymous visitor reads your whole database

Start with the one that needs no account, because it is the one an attacker can reach on any J2Store shop today. The storefront product list and the product-tags list both accept a product_types array filter, which the framework populates straight from the request into model state. Both models then built the product_type IN (...) fragment by wrapping each supplied value in literal quotes and joining them together, with no escaping and no check that the values were valid product-type keys at all. A value containing a single quote closes the string early, and an anonymous request controls part of the SQL.

We proved it against a running shop. The injection is blind, so nothing is echoed back on the page, but the query can be made to pause for a chosen number of seconds when a guess is right and stay instant when it is wrong. Used as a timing oracle, that reads the database out one character at a time: every user record, every session, and the Super User’s stored password hash. No login, no token, nothing but a crafted request to a public page.

The download handler that reads any file

The second serious one is an arbitrary file read. getFilePath() built the on-disk path to a purchased digital download by concatenating the configured attachment folder with the product file’s stored save name, normalising the separators but never resolving or rejecting a ../ segment, and never confirming the result stayed inside the attachment folder. A path that climbs out of the web root is served like any ordinary download. We retrieved the site’s configuration.php, which holds the database password and the site secret, and /etc/passwd, to a request holding only an order token.

Reaching it is a chain rather than a single anonymous request, because the traversing path has to be stored first, most plausibly through the admin product-file save actions that the CSRF gap below leaves forgeable. It compounds badly, though, because J2Store’s order access tokens were predictable, which is the next finding.

The other four

Reported and fixed in the same release:

All six findings at a glance. The scores are J2Commerce’s own CVSS 4.0 figures from the advisory, published alongside the release:

The Joomla CNA published all six records later the same day, and every one credits Phil Taylor of mySites.guru as the finder. The scores above are the published records’ own CVSS 4.0 figures. Two came out higher than the draft numbers in the vendor advisory: CVE-2026-82190 moved from 5.1 to 6.3, and CVE-2026-82191 from 4.5 to 5.3. The other four matched.

Why round two exists at all

Round two happened because we retested the August fix release rather than closing the ticket, and it is worth saying why that mattered. Two of these six, the anonymous SQL injection and the file read, were not in the original report and had nothing to do with the CSRF work J2Commerce was fixing. They surfaced only because we went back through the code that shipped alongside the round-one fix.

The vendor’s first fix build had to be rejected, too. It closed the cart CSRF gaps correctly but left both of those criticals open, and it shipped with its version number unchanged, so no Joomla site would ever have been offered it and no scanner would have told the difference between patched and unpatched. The corrected build fixed the version string and closed the rest. A fix release deserves the same scrutiny as the code it fixes, which is the reusable lesson here for anyone shipping security patches.

Joomla 3, and the deadline J2Commerce has already set

Most of the shops these six flaws affect sit on the branch with the least time left. Six in ten of the affected installs we can see are on Joomla 3, which reached its own end of life on 17 August 2023 and has had no free security fixes from the Joomla project since. Paid Extended Long Term Support is the only supported route after that date, and very few of these shops are on it.

On 3 September 2026 J2Commerce set a date for the shop extension too. J2Store 3 stops receiving security patches on 19 October 2026, two years to the day after the company took J2Store over. From that date the 3.x line gets no security fixes, no support and no further releases of any kind, including for anything found afterwards. J2Store 4 has its own date a year later, on 19 October 2027.

A Joomla 3 shop on J2Store 3 therefore has two deadlines stacked on top of each other, one that passed three years ago and one about five weeks out, and 3.3.23 is among the last builds that will ever answer either. That is the real context for the six issues above. Today’s release closes the anonymous database read. It does nothing about the arrangement that produced it, which is a shop extension sitting on a platform the project itself stopped patching for free in 2023.

The measured state of those shops is worse than the deadline alone suggests. Seven in ten of the Joomla 3 installs caught by this release are below 3.3.21, which puts them behind all three of this year’s advisories rather than just this one. For a shop in that position 19 October is close to a formality, because nothing has been applied for months anyway.

Patch now, but plan to migrate

The right move for a shop still on J2Store 3 is patch now, migrate soon. Update to 3.3.23 to close what is open, then use the time it buys to plan the move to J2Store 4, or on to J2Commerce 6, rather than treating the patch as somewhere to stay. We cover that route, and why the shop migration and the Joomla migration are one project rather than two, in J2Store 3 stops getting security fixes on 19 October 2026.

Shops on 4.0.x and 4.1.x have no such deadline. They still need the update today, and 4.1.8 is the branch that continues into Joomla 6.

Was any of this being exploited?

J2Commerce states it has no evidence that any of these six were exploited on a live store, and neither do we. No proof of concept has been published for any of them. This post describes mechanisms rather than requests, and we are holding the exact payloads back until enough sites have updated.

The honest caveat is which one to check for. The anonymous SQL injection is the one worth going back through a busy shop’s logs for, because it is reachable without a login and a timing-based extraction leaves a recognisable run of near-identical requests to the product list. The file read and the order-status change leave much less behind. If you ran an affected build, the highest-value review is recent order-state changes with no matching payment, the same advice as round one, plus any unusual burst of product-list requests.

How mySites.guru helps

You do not have to open each shop by hand. mySites.guru records the exact version of every extension on every Joomla site it monitors, so J2Store installs across your whole account list appear on one screen with their versions, and any shop below the fix version for its branch is flagged automatically. Instead of logging into each site to check whether it is updated yet, you get one filtered list of the ones that are not, and can act on them together.

That matters more here than usual, because the fix version is not one number. A shop on Joomla 3 needs 3.3.23, a shop on Joomla 5 needs 4.1.8, and 4.1.8 sorts above 3.3.23 while 3.3.23 is the newer release on its own branch. Checking that by eye across a list of client sites is exactly the sort of thing people get wrong at four in the afternoon. If you want to see it against your own sites first, the free audit covers it.