Product Input Fields for WooCommerce EUVD-2026-55001

Two concrete prerequisites must both hold: (1) the plugin's 'accepted file types' setting for the upload field must be left EMPTY, which the plugin documentation advertises as accepting all files and which disables validation; and (2) the target server must NOT honour the upload directory's access rules - i.e. it must permit execution of uploaded scripts (PHP) in the WooCommerce/WordPress uploads path. Limiting factors: if an admin has specified any allowlist of file types, or if the server enforces standard uploads-directory execution blocks (.htaccess/nginx deny rules), RCE is prevented and the flaw degrades to at most arbitrary file write. No authentication (PR:N) or user interaction (UI:N) is required against a vulnerable configuration.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8 critical) describes trivial, unauthenticated, network-based full compromise, and publicly available exploit code lowers the skill barrier. However, the EPSS probability is only 0.20% (10th percentile) and the CVE is NOT in CISA KEV, so there is currently no public evidence of widespread active exploitation - the signals conflict between theoretical severity and observed activity. Critically, real-world impact is gated by two non-CVSS conditions the raw score ignores: the site admin must have left accepted-types empty, AND the server must execute files in the uploads directory. Both must hold for RCE, so a properly hardened WordPress host reduces this to an arbitrary-file-write rather than code execution. This is a genuine priority for exposed WooCommerce stores running the affected plugin with default/empty config, but the low EPSS and configuration dependency suggest opportunistic rather than mass exploitation so far.

An attacker browses to a WooCommerce product page that exposes a file-upload input field configured with an empty accepted-types list, then submits a POST request uploading a malicious PHP webshell instead of an expected document or image. Because validation is bypassed, the file lands in the uploads directory; the attacker navigates directly to its URL and, on a server that executes PHP there, gains arbitrary code execution as the web user. Public exploit code from WPScan documents this path, requiring no authentication or user interaction.