Checkout Files Upload EUVD-2026-111699

Two concrete conditions must both hold for RCE: (1) the plugin's 'accepted file types' setting must be left empty - which the plugin documents as the method to accept all files, so this is a documented/expected configuration rather than an obscure misconfiguration - allowing unauthenticated users to upload arbitrary files including PHP; and (2) the web server must execute PHP from the uploads directory. The key limiting factor is condition (2): on hardened deployments where the uploads directory does not execute PHP (a common WordPress hardening practice), the arbitrary-upload flaw does not escalate to code execution, though malicious files can still be stored. Exploitation is unauthenticated and requires no user interaction when both conditions are met.

Signals are largely consistent in pointing to a serious but conditionally-triggered flaw. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H, base 9.8) describes an unauthenticated, network-reachable path to full compromise, and the vuln.today decision label is 'act_now', reinforcing high priority. However, the EPSS score is low (0.24%, 15th percentile), which is notably at odds with the 9.8 severity; this gap suggests that real-world mass exploitation has not yet materialized and that the 9.8 reflects worst-case impact rather than observed widespread attacks. This is not in CISA KEV, so there is no confirmation of active exploitation. Critically, the CVSS vector encodes AC:L/PR:N, yet the description shows that remote code execution is NOT universal: it requires the plugin's 'accepted file types' setting to be left empty AND the server to execute PHP from the uploads directory - a meaningful real-world limiter that the raw 9.8 score does not reflect. Net assessment: a genuine high priority for sites running this plugin in the vulnerable configuration (treat per the act_now label), but the low EPSS and configuration dependency mean it is likely targeted/opportunistic against specific vulnerable installs rather than indiscriminate at this time.

On a WooCommerce checkout page using this plugin with the 'accepted file types' setting left empty (the documented way to accept all files), an unauthenticated attacker submits a malicious PHP file through the checkout file-upload field. If the server executes PHP from the uploads directory, the attacker then requests the uploaded file directly to trigger remote code execution. No public exploit was identified in the supplied data, though a WPScan advisory documents the issue.