Security Fix for Stores Running on nginx

PrizeX, BidKing and RaffKing ship a file called nginx.conf.example for stores that run on nginx instead of Apache. The latest release corrects one rule in it. If your nginx server block was copied from an earlier copy of that file, change it now. It takes a few minutes.

Who's affected

• Affected: stores on nginx whose server block was copied from nginx.conf.example in an earlier release.
• Not affected: stores on Apache. They use the shipped .htaccess files, which this doesn't touch.
• Not sure? If you followed our VPS and nginx install guide, your server block came from that file.

What was wrong

The catch-all location / rule in the example could serve an address without .php as the matching PHP file's source text, as a download, instead of running it. That could expose your database password. Forms posted to such addresses were refused with a 405 error.

The corrected rule sends those addresses through PHP, so the page runs as it should. Every deny rule in the file, such as the ones that block .env and connection.php, still applies.

What to do

1. Update your store to the latest release from the admin's Software update page. The release brings the corrected nginx.conf.example. Updating doesn't change nginx's own config, so the next step is still needed.
2. Edit your server block. Open the nginx config for your store, for example under /etc/nginx/sites-available/. Find the location / { … } block near the end and replace it with these two blocks from the new nginx.conf.example:

       location / {
           try_files $uri $uri/ @px_ext;
       }
       location @px_ext {
           if (-f $document_root$uri.php) { rewrite ^ $uri.php last; }
           rewrite ^ /error.php last;
       }

   Keep everything else in the file as it is, including the deny rules above the PHP handler.
3. Test, then reload nginx:

   sudo nginx -t && sudo systemctl reload nginx

   If nginx -t reports an error, fix it before you reload: nginx keeps running the old config until a reload succeeds.
4. Check it. Open your store's sign-in page by its address without .php: your store's address followed by /login. You should see the sign-in page. If your browser downloads a file instead, the old block is still in use, so check you edited the config nginx actually loads.

If you think your config was exposed

We can't tell from here whether anyone fetched files from your store. If you're unsure, treat the database password as known:

1. Change the database user's password on your database server or in your hosting panel.
2. Put the new password on the DB_PASSWORD line of the store's .env file, where it keeps its database details. It's in a prizex_private folder above your site folder, outside the web root, or in the site folder itself where that folder couldn't be made.
3. Open the storefront and the admin to check the store still connects.

If other secrets in that .env file could matter to you, such as API keys, change them at their source too.

Common questions

Is my Apache store affected?

No. The problem was in the nginx example config only. Stores on Apache use the shipped .htaccess files and need no change.

Does updating the store fix my nginx config?

Not by itself. The update brings the corrected nginx.conf.example, but nginx keeps using the server block you copied earlier. Replace its location / block with the two new blocks, test with nginx -t, then reload nginx.

How do I check the fix worked?

After reloading nginx, open your store's sign-in page by its address without .php, such as your store's address followed by /login. You should see the sign-in page. If your browser downloads a file instead, the old block is still in use.

Should I change my database password?

If you think someone could have downloaded your files while the old block was in use, yes. Change the password on your database server, then put the new one on the DB_PASSWORD line of the store's .env file. It's in a prizex_private folder above your site folder, or in the site folder itself where that folder couldn't be made.