CubeCart 6.8.1 was released on 21 September 2026, a week after 6.8.0 introduced the Atrium skin. It is a maintenance release: no database changes and no security fixes. That ordinarily makes an upgrade something to schedule rather than rush, but one of the five fixes matters a great deal to a particular kind of store, and it is worth knowing which kind.
Every fully managed CubeCart store we host is already running 6.8.1, so if your store is on one of our managed plans there is nothing for you to do. If you run your own updates, read the first section carefully.
A rounding correction made in 6.8.0 had a side effect on stores that work in tax-inclusive prices, which in practice means most shops selling to consumers in the UK and the EU.
The visible half of the problem is that a discounted line could be shown at its full list price rather than the sale price, on the customer’s receipt, on the order as it appears in the admin panel, and on the printed invoice. The customer was charged correctly. The paperwork disagreed with the charge.
The half that does real damage is quieter. Opening one of those orders in the admin panel and saving it wrote the displayed tax-inclusive figure back into the price column, which stores prices excluding tax. The stored price was then wrong and too high. Nobody had to change anything: opening an order to check it, or to update an address, was enough to inflate it.
Orders already saved that way are not repaired by the upgrade. Installing 6.8.1 stops it happening again, but any order that was already written back has to be corrected by hand.
The exposure is narrow and you can bound it precisely:
That usually leaves a short list. Work through it comparing the stored line price against what the product’s sale price actually was, and against what the customer was charged, which is the figure that was always right. Fix the ones that disagree. If you have any doubt about which orders were opened, the order history and the admin audit log will tell you, which is one of the more useful things CubeCart’s logging gives you.
The maximum quantity for a single basket line rises from 999 to 9999. The more useful part of the change is what now happens when someone asks for more than the limit: the quantity is capped and the customer is told, instead of being silently reset to 1.
The old behaviour was a genuine loss of orders for anyone selling in bulk. A trade customer typing 1500 into a quantity box, seeing it become 1, and having nothing explain why, is a customer who assumes the site is broken. Builders’ merchants, packaging suppliers, anyone selling fixings or consumables by the box: this is your fix.
Search-as-you-type now matches terms typed as one word against product names that contain a separator. Someone typing topsoil finds a product named TOP-SOIL, and rocksalt finds Rock Salt.
This sounds small and is not. Customers do not type the way catalogues are written, and a search that returns nothing is usually the end of the visit rather than the start of a second attempt. If your product names contain hyphens, spaces in compound words, or brand names people run together, this will recover searches you were losing without ever seeing.
If you use Elasticsearch, this only takes effect once the store is reindexed. The change alters how product names are indexed, and an existing index carries on working exactly as it did until you rebuild it. So on an Elasticsearch store the upgrade alone appears to do nothing, and it is worth knowing that before you conclude the fix does not work. We covered the reindexing step and the failure mode to watch for in our article on CubeCart and Elasticsearch.
Both apply only if you have moved to the new Atrium skin.
Modal overlays no longer appear behind the PayPal Commerce Platform buttons, while still sitting below a captcha challenge, which is the ordering you want: the payment buttons must be reachable, and a captcha must be able to sit above everything else. And the product image lightbox no longer opens on small screens, where it added nothing and got in the way of swiping between images.
There are no database changes, so this is a file update and the usual precautions are enough: take a backup you have tested, apply it to a copy of the store first if the store is busy, and check the checkout end to end afterwards. If you run Elasticsearch, plan the reindex as part of the job rather than discovering it later.
Because there are no security fixes in this release, a store that is not tax-inclusive and not on Atrium can reasonably take 6.8.1 at its next convenient maintenance window. A tax-inclusive store should not wait, not because anything is exposed, but because every day on 6.8.0 is another day in which someone might open an order to check it and quietly make it wrong.
Fully managed stores are already on 6.8.1 and no action is needed. If you are on a plan where you manage updates yourself and you would like us to take this one on, open a ticket and we will do it, including the Elasticsearch reindex if your store uses it. If you think an order may have been affected before the upgrade, tell us the order numbers and we will look at what is actually stored against what was charged.