CubeCart Security Releases: What 6.7.3, 6.7.5 and 6.7.6 Fixed

Three of the eleven CubeCart releases between April and August 2026 were driven primarily by security: 6.7.3 on 12 May, 6.7.5 on 8 June and 6.7.6 on 5 August. Between them they fixed ten responsibly disclosed vulnerabilities, including one rated CVSS 9.0.

This article covers what was found, what it actually means for a store owner, and why “authenticated only” is less comforting than it sounds.

The short version

If your CubeCart store is running anything older than 6.7.6, upgrade. That is the entire practical recommendation. Everything below is context for why.

The Release Notes screen in the admin. Security advisories are highlighted at the top of the list. Click for full sized image

All ten vulnerabilities were reported privately and fixed before public disclosure, which is how this is supposed to work. None of them are known to have been exploited in the wild. But the advisories are public now, which means the details are available to anyone who wants them, and old versions get less safe over time rather than more.

Why “authenticated” is not the reassurance it appears to be

Nearly all of these vulnerabilities require an existing back office session. CubeCart’s release notes say so plainly, and it is a genuine and important mitigation: a random visitor cannot reach them.

It stops being reassuring in three common situations.

You have more than one administrator. An authenticated flaw is a privilege escalation route. A member of staff with limited access, or a contractor you gave a login to three years ago and never removed, can potentially use one of these to reach code execution or read data they were never meant to see. Several of the 6.7.5 fixes are exactly this: permission checks that were simply missing, letting a read-only admin trigger bulk customer deletion.

An admin password gets reused or phished. A stolen login normally gets an attacker access to your orders and customers. With an unpatched remote code execution flaw behind it, it gets them the server. That is a materially different incident, and it is the difference between an embarrassing week and a reportable data breach.

You have not enabled two factor authentication. CubeCart has had built in 2FA since 6.6.0. If you have multiple admin accounts and none of them use it, the authentication barrier protecting all of these flaws is one password.

6.7.3: the critical one

Released 12 May 2026 as a security-only release, fixing GHSA-747j-4mmc-cj63, rated CVSS 9.0. This is an authenticated stored remote code execution in the Invoice Editor to order print pipeline.

The mechanism is worth understanding because it explains why the fix has three layers. CubeCart wrote order print artefacts to disk as .php files. An administrator who could edit invoice templates could therefore place PHP into a template, and when an order was printed, that PHP would be written into a file the web server would happily execute. Editing invoice templates is not an unusual permission to hand out, and a sectioned role with documents-edit rights was enough.

The fix:

• Print artefacts are now written as print.<hash>.html rather than .php, so the web server has no reason to execute them.
• files/.htaccess gained a FilesMatch block disabling PHP handlers for any file with a PHP family extension landing in that directory, in case anything ever does.
• Raw PHP open tags are stripped both when a template is saved and again when it is rendered.

Three independent layers, any one of which would break the attack. That is the right response to a flaw of this severity, and it is a good sign about how CubeCart is handling this class of issue.

If you are running any version between 6.6.0 and 6.7.2 and you have ever given a second person access to invoice or document templates, treat this as urgent rather than routine.

6.7.5: seven fixes

Released 8 June 2026, resolving a batch of disclosures across three categories.

Two SQL injections. GHSA-qcx6-cg43-ffmx in the database maintenance tools, where submitted table names reached CHECK, ANALYZE and ALTER TABLE statements; table names are now validated against the live database and safely quoted. GHSA-hvmw-v8gc-4c29 via the download_expire value when updating existing downloads from store settings.

Two cross site scripting flaws. GHSA-43f6-gfcf-wj9c was stored XSS in product description fields, now fixed by passing rich text through an allowlist HTML sanitiser that strips scripts, event handlers and unsafe URI schemes while leaving legitimate formatting intact. Stored XSS on a storefront page is the exact mechanism a card skimming attack relies on, which is why this class of bug matters more on a shop than the word “scripting” suggests. GHSA-v55x-fh73-29vq was XSS through anchor attributes in admin system messages; links are now rebuilt with only a scheme-validated href.

Three broken access control and CSRF issues. GHSA-r376-2wr5-g9qx is the one to pay attention to: a missing delete-permission check on the GDPR customer purge tools meant a read-only administrator could trigger bulk customer deletions. GHSA-8mmq-8hpq-2h23 was a missing delete-permission check on order note deletion. GHSA-cq6g-rf5m-42xg added CSRF protection to the order download-counter reset and stored-card deletion actions.

The pattern across these three is that CubeCart’s admin permission model had gaps where a destructive action did not check whether the acting administrator was allowed to perform it. If you use sectioned admin roles to give staff limited access, you were relying on a boundary that was not fully enforced.

6.7.5 also allowed coupons to be limited to specific delivery countries, replaced deprecated strftime() usage removed in PHP 8.1, and recoded the database schema-diff tool in maintenance for more accurate comparisons.

6.7.6: two residuals, and a lot else

Released 5 August 2026. Both vulnerabilities here are residuals of earlier fixes that turned out to be incomplete, which is a useful and honest thing for CubeCart to have said out loud.

GHSA-fcv7-88v5-vv5f is ORDER BY SQL injection in the admin Customers and Orders listings. It completes GHSA-rm2f-rpcq-6w9f from 6.7.0, which hardened only the array form of the sort parameter and the single page reported at the time. The underlying lesson is a good one: quote-escaping does nothing in an ORDER BY context, because you are not in a string literal. String-typed sort expressions are now structurally validated in Database::select() instead.

GHSA-5mr8-hgcv-3pcj hardens the Smarty security policy for editable email, document and invoice templates against three separate bypasses of the 6.6.1 and 6.7.0 work:

• Static class access was unrestricted. An empty allowlist was being treated as “allow all”, so a template could call any {Class::method()}. Reach a callback-invoking static method on any loaded class and you are past the function denylist entirely. Access is now restricted to an actual allowlist.
• Callback-taking functions were missing from the denylist, array_walk_recursive among them.
• Both policy checks compared function names case-sensitively, so any change of capitalisation walked straight through.

That third one is the kind of bug that makes a security control look present while doing nothing. A new $glob['smarty_allowed_php'] setting lets an install un-ban a specific function where an extension genuinely needs it, with shell and eval functions exempt from the override.

The non-security fixes in 6.7.6 are worth your attention too

Because 6.7.6 is the current release, here are the ones with direct commercial impact:

Customers could not pay for the last item in stock. Stock is reduced at Pending, so a customer returning to complete payment reloaded their order into an empty basket with an availability error. The basket now credits back the stock the customer’s own pending order is holding. If you sell low stock or one-off items, you have been losing orders to this.

Abandoned cart reminders were going to customers who had already paid. Saved carts are now cleared when payment lands, rather than only when the shopper returns to the receipt page, and the suppression check is anchored to the cart rather than to session activity. If you enabled abandoned cart emails and got complaints, this was why.

The HTML minifier was un-escaping entities in text nodes, which silently defeated |escape in every skin and let broken markup in a short description leak out of its container. This is security-adjacent: an escaping filter that does not escape is a problem well beyond cosmetics.

Featured Products no longer uses ORDER BY RAND(), using a random primary-key pivot instead. On a large catalogue this is a significant performance improvement, because ORDER BY RAND() makes the database sort the entire table to pick one row.

Also: remaining tax-inclusive rounding issues fixed and inclusive totals now shown on order receipts; percentage group and category discounts no longer applied twice on category listings; multi-domain and per-language subdomain stores restored after being broken by the 6.7.2 URL pinning; being logged out of admin after a short time fixed; PHP 8 fatal errors in product CSV import fixed; plugins can now register their own scheduled tasks through a new class.cron.tasks hook rather than sharing the single code-snippets task; and product review JSON-LD no longer hardcodes a five star rating, which had every product reporting a perfect score to search engines.

What to actually do

1. Upgrade to the current release. Nothing else on this list matters as much.
2. Enable two factor authentication on every admin account. It has been available since 6.6.0 and it is the control that most reduces the impact of the entire authenticated-vulnerability class.
3. Audit your admin accounts. Remove logins for people who have left, contractors who finished, and anyone who does not need back office access. Every one of them is an attack path for an authenticated flaw.
4. Review your sectioned admin roles. Given 6.7.5’s missing permission checks, assume any limited-access role was less limited than you thought, and review what those accounts could have reached.
5. Check your backups work. The in-app database backup tool was removed in 6.7.0, so if that was your backup, you do not have one.
6. Use the audit log. Added in 6.7.0, it records admin actions with actor, IP, target and diff. It is the tool you will want if you ever need to answer what happened.

Much of this is not CubeCart specific. Our guide to the website security measures that actually matter covers the same ground for any platform.

If you host your CubeCart store with us, we can run the upgrade for you, on a staging copy first if you want to check your skin and extensions before it goes live. If you are hosting elsewhere and are not sure what version you are on or whether your admin accounts are tidy, get in touch and we will take a look.