Phoca Cart 5.2.4, 6.1.7 and 4.0.13 fix a front-end SQL injection

On 16 August 2026 Phoca shipped three security releases of Phoca Cart, the e-commerce extension for Joomla. The first two went out on the morning: 6.1.7 at 10:23 UTC and 5.2.4 sixteen minutes later. A third, 4.0.13 for the Joomla 4 line, followed that evening at 20:39 UTC. Here is everything Phoca published about what changed.

It did come. Phoca published a news item for the 6.1.7 release the same day, and this time the changelog names the flaw: “Fixed possible unauthenticated SQL Injection”, with a detailed report promised later from an external source. The 6.1.7 GitHub release notes go one step further and credit the report to Toan Le. So this was a timing gap, not a policy, and it is to Phoca’s credit that the record was put straight on the same calendar day.

We have spent a lot of this year reading release notes that never caught up. JoomShaper shipped a critical Helix3 patch under a changelog that said only “Security Update”. Balbooa’s remote code execution fix arrived under a plain “Fixed” heading, with nothing to say it closed a hole being exploited at the time. Cotton Cloud pushed a security release to every site through the update system while its changelog file still held exactly one entry, for a version long past. The Joomla project’s own guidance covers this as rule 17 of the twenty rules for developers handling a security report: do not hide security fixes in vague language. Phoca, eventually, did not.

The five-word package note still matters for one reason: for the first few hours it was the only public statement, and Joomla 4 sites had nothing at all until the evening release. The words a vendor puts in a release note are a poor guide to how urgently you need to update. The version number is the part you can act on.

So we pulled the packages apart to work out what changed. The answer is an unauthenticated SQL injection in the product filter, fixed in the same file on all three lines. The more useful answer, if you manage Joomla sites for other people, is that a large share of the installs affected by this will never be offered the fix by Joomla’s own updater, and will keep reporting themselves as up to date.

TL;DR

• Phoca Cart 5.2.4 (Joomla 5), 6.1.7 (Joomla 6) and 4.0.13 (Joomla 4) fix an unauthenticated SQL injection in the product filter
• The a (attribute) and s (specification) request parameters were concatenated into the WHERE clause of the product listing query inside hand-written quotes, on a public page, with no login and no token
• Injection points in admin/libraries/phocacart/search/search.php, now passed through $db->quote() (six on the 5.x/6.x lines, four on the 4.x line)
• Joomla 3 is the only branch still unpatched. We confirmed the identical vulnerable code in 3.5.8, the newest release offered to that platform, and no fixed release exists for it
• Joomla’s updater will not offer the fix to a Joomla 5 site running Phoca Cart 6.x. The update feed offers it 5.2.4, which is lower than what it has, so Joomla shows nothing
• CVE-2026-74251, published by the Joomla CNA the same afternoon at CVSS 4.0 9.3, Critical. The range it originally stated, 5.0.0 to 6.1.16, was corrected same-day to 5.0.0 to 6.1.6, but the 5.0.0 floor still omits the Joomla 4 and Joomla 3 lines
• This is not our find. Phoca credits the report to Toan Le; we analysed the published diff afterwards

What Phoca Cart 5.2.4, 6.1.7 and 4.0.13 actually changed

A warning for anyone trying to check this themselves, because the obvious method gives the wrong answer. GitHub’s compare view between the two tags is useless here. The 5.2.4 tag points at commit 9549020f, which is the same commit as 6.1.7. Comparing 5.2.3...5.2.4 therefore reports 19 commits and 223 changed files, eight months of unrelated 6.x development, none of which is in the 5.2.4 package that people actually install.

The real 5.2.4 code exists only in the release ZIP. Download both packages, unzip, and diff the trees:

curl -sLO https://github.com/PhocaCz/PhocaCart/releases/download/5.2.3/com_phocacart_v5.2.3.zip
curl -sLO https://github.com/PhocaCz/PhocaCart/releases/download/5.2.4/com_phocacart_v5.2.4.zip
unzip -q com_phocacart_v5.2.3.zip -d v523 && unzip -q com_phocacart_v5.2.4.zip -d v524
diff -rq v523 v524

Two files differ. phocacart.xml carries the version bump from 5.2.3 to 5.2.4 and a new creation date, and the rest of its diff is line-ending noise. Everything else is admin/libraries/phocacart/search/search.php.

There is no feature work smuggled in alongside the fix, which makes it a low-risk update to apply. The bundled plugins in the package are untouched and stay at 5.1.1.

The same evening Phoca published 4.0.13, a security release for the Joomla 4 line, and the diff there is the same fix in the same file. The 4.x package differs more broadly, because the component is packaged differently from the 5.x and 6.x builds, but admin/libraries/phocacart/search/search.php has the identical quoting change. The one structural difference: the 4.x file has four injection points rather than six, because the 4.x line predates the multilingual code path that doubles the count on the newer branches.

How does the Phoca Cart SQL injection work?

The vulnerable code is in PhocacartSearch::getSqlPartsArray(), which builds the SQL for filtering products by attribute or specification. Filter values were pasted directly into the query string inside quotes the code wrote itself:

// Before, in 5.2.3 and 6.1.6: single-quote break-out
$inA[] = '(at2.alias = ' . $db->quote($k) . ' AND v2.alias IN (' . '\'' . implode('\',\'', $a) . '\'' . '))';

// Before: double-quote break-out
$inAS[$iA] = 'at2.alias = ' . $db->quote($k) . ' AND v2x' . $iA . '.alias = "' . $v2 . '"';

Note that the array key was already going through $db->quote(). Only the values were left raw. The fix pre-quotes the whole array and quotes the scalar:

$aQuoted = [];
foreach ($a as $vQ) {
    $aQuoted[] = $db->quote($vQ);
}

$inA[] = '(at2.alias = ' . $db->quote($k) . ' AND v2.alias IN (' . implode(',', $aQuoted) . '))';
$inAS[$iA] = 'at2.alias = ' . $db->quote($k) . ' AND v2x' . $iA . '.alias = ' . $db->quote($v2);

The same change is applied six times, covering the attribute and specification paths in both the “match any” and “match all” filter modes, each duplicated for the multilingual and single-language code paths.

Nothing stands between that concatenation and an anonymous visitor. The front-end product listing model reads both parameters straight from the request:

$this->setState('a', $app->getInput()->get('a', '', 'array')); // Attributes
$this->setState('s', $app->getInput()->get('s', '', 'array')); // Specifications

Joomla’s array filter casts the input to an array. It does not sanitise the individual values inside it, so whatever the visitor sends arrives intact at the string concatenation above. The resulting fragment goes into the WHERE clause and the LEFT JOIN of the product listing query. That is a public category or product listing page: no account, no token, no user interaction.

Which Phoca Cart versions are affected?

Everything before the three fixed releases, on every branch. We extracted the newest package offered to each Joomla generation and checked the same function in each:

The Joomla 4 package, 4.0.13, was published the same evening as the 5.x and 6.x releases, so the Joomla 4 line is patched after all. Only the Joomla 3 package, 3.5.8, still has the unquoted concatenation, and the Joomla 3 front-end model has the same unfiltered a and s binding. No fixed release exists for the 3.x branch.

CVE-2026-74251, and where its version range is wrong

The Joomla project’s CNA published CVE-2026-74251 at 12:51 UTC on 16 August 2026, in the gap between the two morning releases and the evening 4.0.13. It scores the flaw CVSS 4.0 9.3, Critical, on the vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, and classifies it as CWE-89. That is the official severity, and it matches what the code does: reachable over the network, no privileges, no user interaction, and high impact on the confidentiality, integrity and availability of the database behind the shop.

The description confirms the mechanism independently of our diff. It names the a[] and s[] GET array parameters on the public shop items page, says they are “concatenated raw into SQL WHERE clauses without parameterization or escaping”, and states the consequence as “full database extraction via time-based blind techniques”.

Two details in the record did not survive checking, and one of them the Joomla CNA fixed themselves within the hour.

The affected range’s top end: 6.1.16, a version that does not exist

The affected range was originally given as 5.0.0 to 6.1.16. The highest tag ever published on the 6.x line is 6.1.7, which is the release with the fix. The last vulnerable 6.x build is 6.1.6. The CNA corrected the record the same afternoon, and it now reads 5.0.0 to 6.1.6, which matches reality on the top end.

The 5.0.0 floor: it leaves out Joomla 4 and Joomla 3 entirely

We extracted 4.0.12 and 3.5.8 and found the identical unquoted concatenation in both. The Joomla 4 line now has a patched release, 4.0.13, but the vulnerable 4.0.12 build is outside the stated range, as is 3.5.8 on a branch with no fix at all. A range starting at 5.0.0 reads as an all-clear for exactly the oldest shops.

Act on the 9.3, and treat the version range as narrower than reality. If you are running Phoca Cart below 5.2.4 on the 5.x line, below 6.1.7 on the 6.x line, below 4.0.13 on the 4.x line, or anything at all on 3.x, you are affected.

Why Joomla’s updater will not offer the fix to some sites

Phoca’s update feed publishes one entry per Joomla generation, each gated by a targetplatform regex:

<version>5.2.4</version>  <targetplatform name="joomla" version="5\.*"/>
<version>6.1.7</version>  <targetplatform name="joomla" version="6\.*"/>

Joomla’s extension update adapter matches that regex against the running Joomla version:

$product == $this->currentUpdate->targetplatform['NAME']
&& preg_match('/^' . $this->currentUpdate->targetplatform['VERSION'] . '/', JVERSION)

A Joomla 5.4.7 site therefore only ever sees the 5.2.4 entry. The 6.1.7 entry is discarded before any version comparison happens. Then Updater::findUpdates() checks that the offered version is actually newer than what is installed, using a gt comparison:

if (version_compare($current_update->version, $data['version'], $operator) == 1) {
    $current_update->extension_id = $eid;
    $retVal[] = $current_update;
}

With 5.2.4 offered and 6.1.5 installed, version_compare('5.2.4', '6.1.5', 'gt') is false. No update row is created. The site reports nothing to update.

So a Joomla 5 site running Phoca Cart 6.x is stranded on a vulnerable version while its update screen looks clean. The extension never appears in the update list at all, and an empty update list is indistinguishable from a patched site. No warning, no flag, no clue that anything is outstanding.

Phoca Cart 6.x installs and runs on Joomla 5 perfectly well, which is how these sites got into this state in the first place. There is no Joomla version gate in the installer, so the manual fix works: download the 6.1.7 package and install it through Extensions, Install, Upload Package File.

Phoca has since confirmed the behaviour is intended. The morning after the release, in the Joomla community chat’s 3rd Party Extension Updates channel, an agency reported a customer running Phoca Cart 6.1.5 on Joomla 5.4.7 who could not see the update. Jan Pavelka, Phoca Cart’s author, answered:

So the feed is working as intended and nobody is going to change it. A Joomla 5 site running Phoca Cart 6.x is expected to be updated by hand, and the empty update screen is the designed outcome.

Phoca also recommends the configuration that produces it. Asked in the same channel whether the 5.x line had a security release too, Pavelka pointed to 5.2.4 and added that “it is recommended to use Phoca Cart 6 on Joomla 5”. That makes the recommended setup for a Joomla 5 shop the one setup Joomla’s updater will never service. Follow the advice and every future Phoca Cart security release reaches the site only if a human goes looking for it.

The Joomla 4 feed entry briefly had a quirk of its own. When 4.0.13 was published, the update feed’s Joomla 4 entry still declared version 4.0.12 while its download URL pointed at the 4.0.13 package, so a site running exactly 4.0.12 was not offered it, because version_compare('4.0.12', '4.0.12', 'gt') is false. Phoca corrected the feed the same day, and the entry now declares 4.0.13. Sites below 4.0.12 get offered and install the 4.0.13 package normally.

The Joomla 4 line is patched, but only if you go and get it

Joomla 4 sites are offered Phoca Cart 4.0.13, which we confirmed contains the fix. The update feed declares the version correctly, so the updater behaves: any Joomla 4 site on 4.0.12 or lower is offered 4.0.13 and installs it from the update screen. There is no manual step on this branch.

Phoca’s own README is candid about which branches it considers finished. As of the 6.1.7 tag it labels the 3.x, 4.x and 5.x lines “no longer supported”, listing 3.5.8, 4.0.12 and 5.2.4 against them, with only 6.x unqualified. So Phoca backported this fix to three branches it has already declared unsupported, and not to the oldest one. That is a defensible line to draw, and better than nothing, but the news item goes further and recommends against staying on any of them: “The only correct approach is to use the latest version of Joomla 6 and Phoca Cart 6.”

Joomla 4 itself has been out of support for a while: bug-fix support ended in October 2024 and security support in October 2025, and the 4.x series no longer appears on Joomla’s roadmap at all. A Joomla 4 shop therefore has a patch to install in the short term, and a migration to plan in the medium term, because it is running an unsupported CMS with a shopping cart whose developer is pointing everyone at the newest branch.

How the affected Joomla sites break down

Of the Phoca Cart installs visible across the Joomla sites we manage:

• Not one was on a fixed version. Every install we can see predates 5.2.4, 6.1.7 and 4.0.13, which is expected on release day and is why the update path matters
• About two-thirds will be offered a fixed release normally by Joomla’s updater and can be patched from the update screen
• About a third are Joomla 5 sites running Phoca Cart 6.x. These get offered a lower version, so their update screens show nothing at all
• A handful are Joomla 4 sites, which are offered the fixed 4.0.13 release normally by the updater

That means roughly a third of the Phoca Cart installs we can see cannot get this fix through Joomla’s own updater, and none of them will be told they are missing it. If you manage Joomla shops and your process is “check the update screen, apply what is listed”, that process misses close to a third of the affected sites here and gives you a clean bill of health while doing it.

The SQL injection itself is an ordinary bug, competently fixed, in a tightly scoped release. Getting that fix onto the sites that need it is the harder half of the job.

How do I find every Phoca Cart install across my Joomla sites?

The check you need is not “what version of Phoca Cart is this” on its own. It is the extension version and the Joomla version together, because the pair is what decides whether the updater will do anything.

mySites.guru lists every extension across every connected site, so you can search for Phoca Cart once and get back every site running it with its version, alongside the Joomla version for that site. That turns a site-by-site login into a single search. It is part of the subscription rather than a free lookup tool, and if you already manage a batch of Joomla sites it is the difference between knowing which shops are stranded and guessing.

For this specific release, the triage is:

1. Find every site running Phoca Cart, with its Joomla version
2. Joomla 6 sites below 6.1.7, and Joomla 5 sites below 5.2.4 on the 5.x line: update from the Joomla update screen
3. Joomla 5 sites running any 6.x version: download 6.1.7 and install it manually, because the updater will not offer it
4. Joomla 4 sites on 4.0.12 or lower: update from the update screen, which offers 4.0.13 normally
5. Joomla 3 sites: no fix exists, so plan the migration or drop the extension

If a site turns out to have been running a vulnerable version on a public shop for a long time, updating closes the hole but tells you nothing about what happened before. If you need someone to go through a site properly, fix.mysites.guru is a fixed fee of £120 per incident, screened first so you are not charged in the very rare case that it cannot be fixed.

Did mySites.guru find this one?

No. This is Phoca’s own security release. We had no involvement in finding it, no involvement in reporting it, and we learned about it the same way anyone else could, by reading a published diff after the packages went out. Phoca’s release notes credit the report to Toan Le, an external researcher, which the news item matches when it promises a detailed report from an external source.

We say so because we have published a run of Joomla extension SQL injection disclosures this year that we did find, including AcyMailing, DPCalendar and EasyStore, and this post sits close enough to those to be mistaken for one. Credit here belongs to Toan Le for finding it and Phoca for fixing it. We have reported a separate flaw in Phoca Download in the past, which Jan Pavelka fixed the same day, so our experience of Phoca acting quickly on a security report is first hand.

CVE-2026-74251 names no finder, while Phoca’s own release notes do. The Joomla CNA does credit researchers when there is one to credit, so an empty credits field here is likely a data entry gap in the record rather than a signal that nobody reported it.

Severity