A critical bug in Phoca Cart, one of the more established shopping-cart extensions for Joomla, hands any anonymous visitor a way to read the store's database straight from the public shop page. CVE-2026-74251 is an unauthenticated SQL injection rated 9.3 on the CVSS scale by the Joomla security team, which assigned the CVE. There is no login step and, at the time of writing, no public exploit and no report of exploitation in the wild. The vendor shipped a fix the same day the flaw went public, so the window to patch cleanly is open right now.
What an anonymous request can pull out
Two parameters on the public shop listing, a[] for attribute filters and s[] for specification filters, are trusted straight into a database query instead of being bound as data. That single missing safeguard turns a product filter into a query console for anyone who can load the page. Because the shop listing is public, the attacker never authenticates, never needs an account, and never trips a login control.
The technique named in the advisory is time-based blind extraction. The attacker cannot see query output directly, so they ask the database a yes or no question and make it pause before answering when the answer is yes. Measure the delay, repeat a few thousand times, and the contents come out one character at a time. It is slow, it is scriptable, and it is exactly the kind of thing an automated scanner runs unattended.
What sits in a Joomla store database is the reason this matters. Customer names, addresses, and order history live there. So do the Joomla user records, including the hashed passwords for every account on the site, administrators included. A patient extraction of the #__users table gives an attacker offline hashes to crack and a customer list to abuse.
- 1Anonymous request to the public shop page with crafted a[] or s[] filter valuesDetection point
- 2The filter values reach the SQL WHERE clause as code, not as bound data
- 3Timed yes-or-no questions extract customer records and password hashes one character at a timeDetection point
Affected versions and the fix
The flaw affects Phoca Cart from 5.0.0 through 6.1.6. The vendor's release history shows 6.1.7 published on August 16, tagged as a security release, and that is the version to move to. Underneath, this is a textbook CWE-89 SQL injection: user input reaching a WHERE clause as code rather than as a bound value. No exploitation has been reported yet, but an unauthenticated critical on an e-commerce component is the sort of thing that gets scanned for fast once it is public.
Update to 6.1.7, then hunt your logs
Patching is step one, and for most operators it is a routine extension update to 6.1.7. Do it today if your shop is reachable from the internet.
Step two is the part patching does not do for you. Updating closes the hole, but it tells you nothing about whether someone walked through it first. If your store ran an affected version while exposed, review your web server access logs for repeated GET requests to the shop items view carrying a[] or s[] parameters, especially long or oddly encoded values and bursts of near-identical requests, which are the fingerprint of an automated blind-injection run. Time-based extraction also leaves a trail of unusually slow responses on those same requests. If you find that pattern, treat the customer data and every Joomla password hash on the site as potentially exposed, force a password reset across all accounts, and rotate any secrets stored in the database.
If you cannot patch within the hour, a web application firewall rule that blocks array-style a[] and s[] values containing SQL syntax buys time, but it is a stopgap, not the fix.
A root cause that keeps coming back
This is the same failure that produced the supplier SQL injection in ERPNext, the Metabase injection that reached admin access, and the unpatched GeoServer injection we covered earlier this year: user input concatenated into a query string instead of passed as a bound parameter. Parameterized queries have been the standard defense for two decades, and a single unparameterized filter is enough to undo them.
Joomla's extension marketplace keeps surfacing this pattern, from the Fabrik unauthenticated flaw to page-builder uploads that reached the KEV list. The core platform is not the weak point here. The third-party extensions bolted onto it are, and an e-commerce extension is the highest-value target of the lot because of what it stores. If you run a Joomla shop, the practical lesson is to treat every public-facing extension as part of your attack surface and to patch the cart the day a fix lands. Today, that day is here.