CubeCart 6.6.0 was released on 7 April 2026 and it is, without much argument, the largest single release the platform has had since version 6 launched. Around ninety separate changes went in, spanning new features, security hardening, tax corrections, performance work and a long list of admin improvements.
It arrived after a five month gap since 6.5.12, and it opened an extraordinary run: eleven CubeCart releases in four months, ending with 6.7.6 on 5 August. Almost everything in the current CubeCart traces back to this release.
This article covers what actually changed. If you only read one section, make it “Before you upgrade” at the end, because 6.6.0 on its own is not the version you want.
Strip away the technical detail and 6.6.0 does five things that change what your store can do.
You can recover abandoned baskets. CubeCart will now email shoppers who filled a basket and left without paying. Retail abandonment typically runs around 70 percent, so even a modest recovery rate is usually the highest return feature in this entire list. It ships disabled; you turn it on under Scheduled Tasks.
Your back office can be locked down properly. Two factor authentication is built in, per administrator, using either an emailed code or an authenticator app. If anyone other than you has a login, this is the most valuable half hour you will spend after upgrading.
Other software can talk to your store. A REST API covering nine areas of the store means your accounts package, stock system or warehouse tool can read and write CubeCart data without anyone exporting a CSV.
Your shipping quotes can be accurate. A genuine three dimensional box packing algorithm works out which parcels an order actually needs, rather than guessing from total weight.
Your tax figures are correct. Tax rounding was reworked for penny accuracy and the coupon plus tax logic was rewritten from scratch. This one is not optional reading if you sell into multiple tax rates.
CubeCart commissioned a full penetration test for this release and hardened the platform on the back of the findings. Two vulnerabilities were fixed under responsible disclosure:
Additional patches came from further responsible disclosure reports, and card numbers are now automatically obfuscated in the request log. That last one is a small change with real consequences if your logs are ever exposed.
The entry point is api.php at your store root, backed by new classes under classes/api/ providing a router, authentication handler, rate limiter and response builder. Nine resources ship: categories, coupons, customers, files, orders, products, reviews, settings and tax.
Authentication is Bearer token in the form Bearer {api_key}:{api_secret}, with keys created and revoked on a new API Keys screen under Settings. Each key carries per-resource read and write permissions, and every key is tied to an administrator account whose own permissions act as a ceiling. Rate limiting defaults to 60 requests per minute per key.
Treat it as beta. And do not enable it on 6.6.x: the files resource had an authenticated arbitrary file upload to remote code execution vulnerability, fixed later in 6.7.0.
Implemented in classes/totp.class.php as standard RFC 6238 time based one time passwords: six digits, thirty second window, base32 shared secret. Because it is the standard algorithm, any normal authenticator app works, and enrolment is by QR code. The alternative is an emailed one time code, which is easier to roll out but only as strong as the mailbox behind it.
It is opt in per administrator, so you can enable it for yourself without forcing it on everyone at once.
Driven by a new sendAbandonmentEmails scheduled task. The email is built from the saved cart: customer name, store name, item count, the products with options and images, a recovery link back to the basket, and an opt-out link. There is optional support for including a coupon code.
Worth knowing: 6.6.0 shipped this with no maximum cart age and no per-cart send limit. Both were added in 6.6.1.
New in classes/packer.class.php, a proper three dimensional bin packer rather than a weight total. The algorithm is First Fit Decreasing with Extreme Point placement: items are sorted largest by volume first, and each is tried in all six orientations at every extreme point of every open box before a new box is opened. You define your box sizes in the store’s packaging list and shipping modules quote against the boxes actually needed.
CubeCart gained real scheduled tasks managed from the back office. The defaults are exchange rate updates and sitemap rebuilds (both enabled, daily), plus cache clearing, code snippet execution and abandoned cart emails (all disabled until you want them). Each task has its own frequency.
Categories and products can now be restricted to specific customer groups, so they are invisible to everyone else. This is what makes trade and retail from a single store practical without a plugin.
admin/docs/, replacing the legacy wikiSix changes here, and some of your numbers will legitimately differ after upgrading.
If you sell into multiple tax rates or run promotions, test these on a staging copy and tell your bookkeeper the basis changed.
Seven changes, and the first is the one that saves you ongoing work.
priceValidUntil field added and the description markup validatedNine changes, several of which matter on larger stores.
live_from inventory query optimisedglobal.inc.php when the file has actually changedAround fifteen separate improvements, mostly small irritations finally dealt with: a sortable table layout for the administrator list, additional tools in the ACP flyout widget, improved review and address book management, quick-clear shortcuts on log pages, visual “Copied!” feedback on the copy tool, sortable rows no longer losing column widths when dragged, the database table optimise feature restored, single quotes in the SQL Query tool no longer HTML encoded, no more false “Product successfully updated” when nothing changed, and the debug window no longer appearing on top of other content.
magic_quotes ini calls removedTwo follow up releases arrived within eight days, and you should never run 6.6.0 on its own.
6.6.1 (9 April) reworked Smarty template security. The 6.6.0 approach used an allow list which broke legitimate template code in the field. 6.6.1 flipped it to a block list of genuinely dangerous functions, restored the ucfirst modifier, whitelisted module template paths, and crucially gave extensions a way to register their own trusted include paths. If you run custom skins or third party extensions, 6.6.0 alone may break them. It also added the abandoned cart email caps described above.
6.6.2 (15 April) fixed a genuinely serious bug introduced by 6.6.0’s config storage change: the new name value pair config writer used a non-atomic DELETE followed by INSERT, so configuration values could be silently lost. It also stopped the skin setting being permanently overwritten by fallback logic, and extended bulk price updates to cover customer group pricing.
This is a normal pattern for a release of this size and CubeCart turned both fixes around quickly, but it is exactly why we would not have put 6.6.0 on a production store in its first week.
Yes, but not to 6.6.0, and at this point not to 6.6.x at all. Later releases fixed security issues that the entire 6.6 line is exposed to, including a critical remote code execution vulnerability rated CVSS 9.0 that was not fixed until 6.7.3. Go to the current release.
The reason to understand 6.6.0 is that it is where nearly all of the capability in today’s CubeCart came from. Everything the 6.7 series built on top of, it built on this.
If you host your CubeCart store with us and want the upgrade planned properly, run on a staging copy first so you can check your tax and coupon figures before it goes live, just ask.