PPOM for WooCommerce CVE-2026-104801

Exploitation requires the PPOM - Product Addons & Custom Fields for WooCommerce plugin (version ≤34.0.10) to be installed and active on a WordPress/WooCommerce store, with the plugin's file-upload addon handling reachable through the cart/order rename_files code path. No authentication, privileges, or user interaction are needed (AV:N/PR:N/UI:N), and the attack works against default configurations exposed to the internet. Practical impact depends on web-process file permissions: the target file (e.g. wp-config.php) must be readable/deletable by the web server user, and file READ further requires the uploads/ppom_files/confirmed/ directory to be web-accessible, which the description states is the default. The main limiting factor is simply that the vulnerable plugin must be present and serving requests.

This is a genuine high-priority issue, not a CVSS-inflated one. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes network-reachable, low-complexity, unauthenticated exploitation requiring no user interaction, which aligns with the description's claim of unauthenticated arbitrary file deletion. The scored impact (C:N/I:H/A:H, base 9.1) actually UNDERSTATES the real risk: the description explicitly states the relocated file is moved byte-identically into the publicly accessible wp-content/uploads/ppom_files/confirmed/ directory, producing arbitrary file READ of any web-readable file - yet the vector sets C:N. This is a conflicting signal and should be treated as a confidentiality impact too (my independent assessment uses C:H). Deletion of wp-config.php further enables a path to remote code execution. No EPSS score, CISA KEV entry, or public exploit was provided in the input, so there is no confirmation of active exploitation - per the precision rules this is 'no public exploit identified at time of analysis'. Even so, the combination of unauthenticated access, trivial complexity, a widely installed WooCommerce plugin, and a Wordfence-published advisory makes mass automated scanning and exploitation realistic once details circulate; teams should patch urgently rather than wait for KEV listing.

An unauthenticated attacker submits a crafted request to the PPOM file-handling flow (cart/order rename logic) containing path-traversal sequences that escape the intended ppom_files upload directory. By targeting wp-config.php they can either relocate it byte-identically into the public uploads/ppom_files/confirmed/ directory to read database credentials and secret keys, or delete it to force WordPress into an installer/reinstall state and pivot to full site takeover and remote code execution. No authentication, user interaction, or special privileges are required; no public proof-of-concept was identified in the provided data.