Checkout Files Upload for WooCommerce lets anyone upload PHP

Q: Where does Checkout Files Upload for WooCommerce keep uploaded files?

In the wp-content/uploads/woocommerce_uploads/alg_uploads/checkout_files_upload/ folder. The plugin moves a file there when an order is created, and until then it sits in a temporary folder on the server. In versions before 2.4.1 the file keeps the extension it was uploaded with.

# TagsSecurityWooCommerce

The WPhost team9 Nov 202610 min read

On 28 October 2026 CVE-2026-103688 was published, a vulnerability in the Checkout Files Upload for WooCommerce plugin, which lets a store's customers attach a file to their order. Every version before 2.4.0 is affected, and 2.4.0 was released on 20 October. When the accepted file types field is left empty, someone without an account can upload any file they like to the server, a PHP script included, and get their own code running. CISA scores the vulnerability 9.8 on the CVSS scale, "critical". According to wordpress.org the plugin has more than 7,000 active installations.

The plugin is used by stores where the customer sends a file along with the order. That might be a photo to print on a mug or a T-shirt, a business card design or a document for a company order. If you sell products like these and removed the format restriction so you could accept anything, check your store today.

How the vulnerability works

In the plugin's settings, the "Accepted file types" field decides which files the upload form takes. By default it holds .jpg,.jpeg,.png. Up to version 2.4.0 the hint next to the field said that leaving it blank makes the form accept all files, and that is exactly how it behaved. We compared the code of 2.3.0 and 2.4.0. With the field empty, the old version does not check the file at all, neither its extension nor its contents.

The form works for visitors without an account too, because a customer has to be able to attach a file before ordering. From the code we reviewed, an uploaded file first sits in a temporary folder on the server. When an order is created, the plugin moves it to wp-content/uploads/woocommerce_uploads/alg_uploads/checkout_files_upload/, keeping the extension it was uploaded with. The order does not need to be paid, since WooCommerce creates it before payment. So a file ending in .php stays in a folder on the site as .php.

Whether an attacker can then run it depends on the server. The CVE record speaks of servers that execute PHP from the uploads directory. WooCommerce places an .htaccess file in woocommerce_uploads that blocks browser access to the folder on Apache, unless the store's file download method is "Redirect only (Insecure)". Nginx does not read .htaccess at all, though, and the file sometimes goes missing when a site is moved. So do not rely on it.

Version 2.4.0 closes the hole. With the field empty, it only lets through the file types WordPress allows in the media library, and PHP is not one of them. Version 2.4.1, released on 5 November, adds more protection. New files are saved under a random name ending in .bin, and on download the plugin serves them in a way that stops the browser from running code in them. Files uploaded before the update keep their names.

The vulnerability was found by the researcher Josef Azizov, and the CVE record comes from WPScan. As of 28 October CISA notes in it that there is no evidence of attacks, but that the attack can be automated and the technical impact is total. The CVE is not in the 6 November edition of CISA's catalogue of vulnerabilities used in attacks either. WPScan will publish the proof of concept on 26 November 2026, and from then on anyone will be able to see how the attack works. Update before that date. The CVSS score guide explains what a 9.8 means.

Which stores are affected

A store is affected if it runs Checkout Files Upload for WooCommerce before 2.4.0 and at least one upload form has an empty "Accepted file types" field. The free version has one form, configured in the File Uploader #1 section. With the paid Pro plugin there can be more forms, each in its own section (File Uploader #2 and so on).

If the field holds a list, such as .jpg,.jpeg,.png,.pdf, the old version checks both the extension and the contents of the file, so this vulnerability does not affect you. Update anyway, because 2.4.1 also adds the file name protection described above.

An empty field is convenient for a store that accepts designs in many formats (PSD, AI, SVG) and does not want to list them all, and the plugin itself suggested exactly that.

Is your store affected?

You can see the version under Plugins > Installed Plugins, and the field under WooCommerce > Settings > Checkout Files Upload, in each form's section. In cPanel's Terminal, the commands below show both. The WP-CLI guide explains how to work with WP-CLI.

Bash

# cPanel > Terminal, in the site's folder
# Read-only. The plugin version and the file types field.
wp plugin list --fields=name,status,version \
  --skip-plugins --skip-themes | grep checkout-files-upload
wp option list \
  --search="alg_checkout_files_upload_file_accept_*" \
  --fields=option_name,option_value

If an alg_checkout_files_upload_file_accept_ row has nothing next to it, that form's field is empty. If the command shows no rows at all, the field has never been saved and the default .jpg,.jpeg,.png applies.

The next commands look for PHP files in the folder where the plugin keeps files from orders, and show the protection WooCommerce placed on the woocommerce_uploads folder. A customer sending you a photo or a PDF has no reason to upload a PHP file.

Bash

# cPanel > Terminal, in the site's folder
# Read-only. PHP files among the files from orders.
find wp-content/uploads/woocommerce_uploads/alg_uploads -type f \
  \( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" \) -ls
# Read-only. WooCommerce's protection for the folder.
cat wp-content/uploads/woocommerce_uploads/.htaccess

An empty result from find is a good sign. If it reports that the folder does not exist, no file has been attached to an order through the plugin yet. The second command should show deny from all. If it shows something else, or the file is missing, the folder can be opened from a browser on Apache.

What to do

Back up the files and the database, as described in the backup guide.
Update Checkout Files Upload for WooCommerce to 2.4.1 or newer from Dashboard > Updates or Plugins > Installed Plugins. The hole is already closed in 2.4.0, but 2.4.1 saves new files under a name the server does not execute. The guide to updating plugins safely explains how to update without surprises.
Review the "Accepted file types" field of every form. Since 2.4.0 an empty field no longer means "all files". If you accept SVG, PSD, AI or another format WordPress does not allow by default, enter every format you accept in the field. Never enter .php, .phtml or .phar. Then place a test order with an attached file to make sure your customers can send what they need.
Run the find command from the previous section again. The update does not touch files uploaded before it. If you find a PHP file, do not open it in a browser, because opening it runs it. Look through Users for administrators you do not recognise, change the passwords and work through the guide for a hacked site.

What we do

With vulnerability (CVE) monitoring we track what is installed on your site and match it against the vulnerability (CVE) databases every day. As soon as a vulnerability appears in something you use, we send you an alert and update, trying the update on a copy in staging first. Your site can be hosted anywhere. If you would like us to add it, write to us through the inquiry form.

Frequently asked questions

What is CVE-2026-103688?

A vulnerability in the Checkout Files Upload for WooCommerce plugin, published on 28 October 2026. When the "Accepted file types" field is empty, the plugin does not check uploaded files, and someone without an account can upload a PHP script. On a server that executes PHP from the uploads directory, that leads to someone else's code running on the site. CISA scores it 9.8 on the CVSS scale, "critical".

Which version of Checkout Files Upload for WooCommerce fixes the vulnerability?

Version 2.4.0, released on 20 October 2026. Version 2.4.1, released on 5 November 2026, adds more protection by saving new files under a random name ending in .bin. Update to at least 2.4.0, and preferably to 2.4.1 or newer.

Is my store affected if the file types field was never changed?

Not by CVE-2026-103688, as long as the "Accepted file types" field holds a list. By default Checkout Files Upload for WooCommerce accepts only .jpg,.jpeg,.png, and then it checks both the extension and the contents of the file. The vulnerability only affects a form with an empty field, but updating to 2.4.1 is worthwhile in every other case too.

Is the Checkout Files Upload for WooCommerce vulnerability already being attacked?

As of 28 October 2026 CISA notes in the CVE-2026-103688 record that there is no evidence of attacks, but that the attack can be automated. It is not in the 6 November edition of CISA's catalogue of vulnerabilities used in attacks either. WPScan will publish the proof of concept on 26 November 2026, so update before that date.

Where does Checkout Files Upload for WooCommerce keep uploaded files?

In the wp-content/uploads/woocommerce_uploads/alg_uploads/checkout_files_upload/ folder. The plugin moves a file there when an order is created, and until then it sits in a temporary folder on the server. In versions before 2.4.1 the file keeps the extension it was uploaded with.

What changes for customers after updating to Checkout Files Upload 2.4.0?

Since 2.4.0 an empty "Accepted file types" field no longer means "all files", only the types WordPress allows by default. If the store accepts SVG, PSD, AI or another format like that, enter every format you accept in the field. Then place a test order with an attached file.

What should I do if I cannot update Checkout Files Upload right away?

Enter in the "Accepted file types" field only the formats you really accept, for example .jpg,.jpeg,.png,.pdf. With the field filled in, even the old versions of Checkout Files Upload for WooCommerce check every file. The other option is to deactivate the plugin until you update, but then customers will not be able to attach files.

What should I do if I find a PHP file in the Checkout Files Upload folder?

Do not open it in a browser, because opening it runs it. Assume the site has been broken into, look through the administrator accounts, change the passwords and clean the site as described in the guide for a hacked WordPress site. Updating to 2.4.1 does not delete files uploaded before it.

Sources