Checkout Files Upload for WooCommerce: Unauthenticated PHP Upload to RCE

Threat Overview

A critical arbitrary file upload vulnerability in the Checkout Files Upload for WooCommerce (checkout-files-upload-woocommerce) plugin allows unauthenticated shoppers and automated bots to upload executable PHP scripts directly to the web server, resulting in immediate Remote Code Execution (RCE).

Tracked as CVE-2026-103688 (CVSS 9.8), the vulnerability affects all versions prior to 2.4.0. Most alarmingly, the flaw is triggered when store operators follow the plugin’s own configuration instructions for accepting flexible customer file uploads during checkout.

The Breakdown: How the Exploit Works

Merchants frequently use Checkout Files Upload for WooCommerce so customers can attach custom artwork, print specifications, or documentation to their orders. In versions prior to 2.4.0, the plugin’s administrative settings explicitly documented that leaving the “Accepted File Types” field blank would allow customers to upload any file format.

When a merchant leaves that setting empty—or fails to enforce a strict server-side allowlist—the plugin’s unauthenticated AJAX upload handler performs zero sanitization or denylist filtering against executable server scripts. An unauthenticated visitor on the public cart or checkout page can upload a .php webshell directly into the publicly reachable WordPress uploads directory and execute it immediately by requesting the file’s URL in a browser.

The Operational Risk: What an Attacker Gains

• Instant Unauthenticated RCE: Attackers execute arbitrary operating system commands as the web server user without logging in or completing a purchase.
• Digital Credit Card Skimming (Magecart): Compromised WooCommerce servers allow attackers to inject stealth JavaScript payment skimmers directly into the live checkout page.
• Full Database & Secret Extraction: Webshell access exposes wp-config.php, database credentials, payment gateway keys, and every historical customer order.
• Lateral Hosting Compromise: On shared or multi-site servers, arbitrary PHP execution threatens every adjacent domain hosted under the same account.

Our Take in Plain English

“When a plugin’s own instructions tell a business owner ‘leave this box blank to accept any file,’ a merchant thinks of PDFs, ZIPs, and design proofs—not a live PHP program that hijacks the server. That is the fundamental trap of traditional WordPress: the folder where public visitors upload files lives inside the exact same runtime engine that executes server code. On a modern pre-rendered edge architecture, your website cannot execute uploaded PHP scripts because there is no PHP engine running on the public web server in the first place.”

The Modern Architectural Remedy

• Legacy Dynamic WordPress: Stores visitor-uploaded files inside a public directory tree served by an active PHP runtime interpreter, turning a single missing extension check into total server compromise.
• Modern Pre-Rendered Edge Architecture: Decouples the static edge frontend from file ingestion, routing customer uploads directly to isolated object storage buckets where script execution is physically impossible.

Immediate Action Items for WordPress Operators

1. Patch Immediately: Upgrade Checkout Files Upload for WooCommerce to version 2.4.0 or later.
2. Enforce an Explicit Allowlist: Never leave accepted file type fields blank; explicitly restrict uploads to safe non-executable extensions (.pdf, .jpg, .png).
3. Disable PHP Execution in Uploads: Configure nginx or .htaccess rules to strictly block PHP execution inside /wp-content/uploads/.
4. Scan Upload Directories: Audit /wp-content/uploads/ for any .php, .phtml, or .phar files uploaded prior to patching.