Critical Cs-Cart Vulnerability: Please Protect Your Store Asap

Hello. We have some urgent news related to a security issue that affects all 4.x.x versions of CS-Cart and Multi-Vendor, including the latest version 4.6.3. It is vital that all store owners are aware of this critical vulnerability and take the necessary steps to protect their stores. When exploited, the vulnerability can allow unauthorized access to the Administration panel, assuming that the intruder knows the name of your admin script.

The vulnerability was found in house (by our own specialists), and to our knowledge it hasn’t been exploited yet. That’s why we aren’t disclosing yet what exactly it is about—that way you will have time to secure your store. Even though your installation of CS-Cart or Multi-Vendor 4.x.x might not be affected (it depends on the server configuration), we highly recommend against ignoring this problem. Please take one of the following measures as soon as possible:

• If you use CS-Cart or Multi-Vendor 4.6.3, install Service Pack 1 that is currently available in your Upgrade Center.
• If you use an older version of CS-Cart or Multi-Vendor 4.x.x, please follow the steps below:

  • Go to the app/Tygh directory of your CS-Cart or Multi-Vendor installation and find the file called Bootstrap.php.
  • Find the following line in that file:
    if (empty($server[‘REQUEST_METHOD’])) {
  • Replace it with the following line and save your changes:
    if (PHP_SAPI === ‘cli’) {
This will close the vulnerability in your store. If you’d like to make it so that File Changes Detector wouldn’t inform you that app/Tygh/Bootstrap.php has been changed, please follow the instruction from this post.

Thanks and fixed!

I have an ERP software that sincronize product and price, and download orders.

After made this change ...the orders dosen`t download...it is obvious

But good to now for who have same settings like me.

Can you please share steps how I find app/Tygh directory

I'm not familiar with coding etc..

Can you please share steps how I find app/Tygh directory

I'm not familiar with coding etc..

app directory is located in the root directory of your CS-Cart installation

Can you please share steps how I find app/Tygh directory

I'm not familiar with coding etc..


The app/Tygh directory is located on the server, in the directory where your CS-Cart or Multi-Vendor store is installed. The exact steps to get to that directory depend on how you usually access the files of your store. Unfortunately, there can't be a single instruction that covers all the possible hostings, enviornments, control panels, etc.

For example, if you installed CS-Cart on a hosting with cPanel, you'll be able to find the mentioned directory in the File Manager. Take a look at this screenshot from this article: you'll see the app directory there, and you'll find Tygh inside it.

If you have FTP access to the files of your store, then you can use an FTP client of your choice to access the files of your store..

If that doesn't help, please contact our technical support via Help Desk, and our specialists will be able to assist.

I'm pretty sure we were hacked by this method. Almost $5000 worth of fraud thank you very much.... and we lost all of it.

After figuring out what was going on in general we knew what to look for but not how they were doing it. Basically they were using stolen CC data, entered the correct AVS/Billing address and processed the order but I found one log in in the logs (just a few days ago) where they logged in as the admin user from an IP other than mine. I think they were editing the orders and changing the addresses to ship to the fraudulent address....ship and billing addresses were always the same yet I could see in the CC processing logs where the REAL billing address was submitted during processing....always different than what we saw in the order.

And yes... we have a different admin url, https and the normal precautions.

I'm pretty sure we were hacked by this method. Almost $5000 worth of fraud thank you very much.... and we lost all of it.

After figuring out what was going on in general we knew what to look for but not how they were doing it. Basically they were using stolen CC data, entered the correct AVS/Billing address and processed the order but I found one log in in the logs (just a few days ago) where they logged in as the admin user from an IP other than mine. I think they were editing the orders and changing the addresses to ship to the fraudulent address....ship and billing addresses were always the same yet I could see in the CC processing logs where the REAL billing address was submitted during processing....always different than what we saw in the order.

And yes... we have a different admin url, https and the normal precautions.

Maybe horse has bolted etc but, add ip restriction so you can only log in from certain ips maybe

How can we get rid of the Core files have changed message when patching manually. Getting the message every time you log on leads to ignoring it which is not secure.

Admin>settings https://prnt.sc/hdf3l4

I'm pretty sure we were hacked by this method. Almost $5000 worth of fraud thank you very much.... and we lost all of it.

After figuring out what was going on in general we knew what to look for but not how they were doing it. Basically they were using stolen CC data, entered the correct AVS/Billing address and processed the order but I found one log in in the logs (just a few days ago) where they logged in as the admin user from an IP other than mine. I think they were editing the orders and changing the addresses to ship to the fraudulent address....ship and billing addresses were always the same yet I could see in the CC processing logs where the REAL billing address was submitted during processing....always different than what we saw in the order.

And yes... we have a different admin url, https and the normal precautions.

Hi, I'm very sorry your store was compromised.

If you can provide us with access logs of your store we will analyse it and try to understand how did the hacker get access to your store.

Please contact us at https://helpdesk.cs-cart.comand we do all we can.

Admin>settings https://prnt.sc/hdf3l4

That just automates ignoring the message, not just ignoring the patch that was made. Worse than seeing it so many times you ignore it but maybe once in a while you'll check to see what files its found. Any patch to core files supplied by cs-cart should include steps so that it is not considered a core file change.

That just automates ignoring the message, not just ignoring the patch that was made. Worse than seeing it so many times you ignore it but maybe once in a while you'll check to see what files its found. Any patch to core files supplied by cs-cart should include steps so that it is not considered a core file change.

Steps to consider core files changes are actually upgrades.

But still you are right about controlling core file changes, that's why this feature was created. Please provide your version of CS-Cart and I will provide you with fix!

Our EZ Admin Helper addon has had the security check action updated to detect whether this patch has been applied or not. It is ez_maint version 4.6.29 and will be automatically updated in your store if you have purchased the addon. If you want to force the update now (rather than at the next auto-upgrade cycle), use the following admin url parameters to force an upgrade:

?dispatch=ez_maint.upgrade.force

The total number of security checks now performed is 16 different checks. EZ Admin Helper is still the easiest way to schedule maintenance activities as well as to check "all files" for add/remove/change on your site. Several other maintenance functions/activities are supported. See the documentation at this link. for an overview of the addon.

Note that this will likely break data feed cron jobs - probably what dukmanel was talking about. With this fix applied the cron on my cPanel server using EasyApache 4 spits out 302 Found full html headers and does not generate the file. This is because php on the command line runs the cgi-fcgi php binary. The test for an empty REQUEST_METHOD works fine in this case. But when testing PHP_SAPI the cron needs to change to run /usr/local/bin/php to use the cli binary. YMMV may vary as to where you have the CLI binary installed depending on your host.

Steps to consider core files changes are actually upgrades.

But still you are right about controlling core file changes, that's why this feature was created. Please provide your version of CS-Cart and I will provide you with fix!

Running 4.4.3 currently.

I did the update today, but had to do a database restore afterwards (for a different issue), now it's saying my last upgrade was Nov 6, 2017 for 4.6.2 - 4.6.3. How would I get the update back in my Upgrade center? Or is the patch still applied because I just did a database restore?

I did the update today, but had to do a database restore afterwards (for a different issue), now it's saying my last upgrade was Nov 6, 2017 for 4.6.2 - 4.6.3. How would I get the update back in my Upgrade center? Or is the patch still applied because I just did a database restore?

The change has nothing to do with the DB, hence the change would remain. But if your restore was for a different version of cs-cart, you'r going to have all sorts of problems. I would run the upgrade again and ignore any file conflicts that it identifies (NOT TESTED you should backup before proceeding).

That just automates ignoring the message, not just ignoring the patch that was made. Worse than seeing it so many times you ignore it but maybe once in a while you'll check to see what files its found. Any patch to core files supplied by cs-cart should include steps so that it is not considered a core file change.


Hello. To prevent the File Changes Detector from displaying app\Tygh\Bosstrap.php as a changed core file, follow these steps:
  • In the directory where CS-Cart or Multi-Vendor is installed, go to var/snapshots.
  • You'll find multiple PHP files with version numbers. Each version number has two files: one ends with .php, and the other with _dist.php.

    For example, if you use CS-Cart 4.4.3 these files will be called 4.4.3_ultimate_dist.php and 4.4.3_ultimate.php, and if you use Multi-Vendor 4.6.1, the files will be called 4.6.1_multivendor_dist.php and 4.6.1_multivendor.php

  • Open the file of your current version without _dist. For example, if you use CS-Cart 4.4.3, it will be 4.4.3_ultimate.php.
  • Find the line that contains /app/Tygh/Bootstrap.php; it should look like this:
    'd2295a521d43e20c64af01823ba1f00c' => '/app/Tygh/Bootstrap.php',
  • Copy the hash of the file (in our example it's d2295a521d43e20c64af01823ba1f00c); we'll need it in the following steps. Note that the hash may differ depending on the version you have installed.
  • Open the file of your current version with _dist. For example, if you use CS-Cart 4.4.3, it will be 4.4.3_ultimate_dist.php
  • Find the line that contains /app/Tygh/Bootstrap.php; it should look like this:
    'b2295a521d43e20c64af01823ba1f00c' => '/app/Tygh/Bootstrap.php',
  • Replace b2295a521d43e20c64af01823ba1f00c (or any other hash that you have in this line) with the hash you got at step 5.
  • Save the file you've just edited (in our example it's 4.4.3_ultimate_dist.php).
Done! Now the File Changes Detector should ignore the change you've made to close the vulnerability.

The change has nothing to do with the DB, hence the change would remain. But if your restore was for a different version of cs-cart, you'r going to have all sorts of problems. I would run the upgrade again and ignore any file conflicts that it identifies (NOT TESTED you should backup before proceeding).

Thanks. My restore was going from 4.6.3 Service Pack 1 to 4.6.3, so it should be ok, then?

Thanks for your help.