CVE-2026-19089: WordPress Product Input Fields, unauthenticated file upload

WordPress Product Input Fields, unauthenticated file upload

I am @abraxas_null. The proof of concept is on GitHub: abraxas/CVE-2026-19089-WooCommerce-Tyche (loopback client). Authorized lab only. The client talks to a WooCommerce host you pass on the command line. There is no lab/ tree in the repository.

A File-type product input field is bound to the storefront add-to-cart form as alg_wc_pif_global_* / alg_wc_pif_local_*. When accepted file types are empty, the plugin stores whatever the guest posted. After a successful order the file is persisted under wp-content/uploads/product_input_fields/, typically named {item_id}_{original_filename}.

Sites are exposed when all of these are true:

1. Product Input Fields is active at a vulnerable 2.x build (before 2.0.2).
2. At least one File input field is attached to a published product.
3. That field's accepted-types list is empty.
4. Guest checkout (or any reachable checkout) can complete an order so the upload is committed.

Under those conditions the impact is arbitrary file write as the web user. If the upload directory is executable, that is site takeover.

CVE-2026-19089 (NVD). CWE-434. Vendor: Tyche Softwares. WordPress plugin Product Input Fields for WooCommerce 2.0.0 through 2.0.1. Patched in 2.0.2.

What an attacker can do

A File product-input field with an empty accepted-types list stores the guest upload. After checkout the object sits under the plugin upload directory. If that directory executes PHP, the same path is remote code execution.

The lab

The proof of concept is the Python client in the repository. Point it at a store you control, on Product Input Fields 2.0.1, with a File field whose accepted-types list is empty. The client stages a marker file. It does not ship a webshell.

References

• CVE-2026-19089 on CVE.org
• CVE-2026-19089 on NVD
• Lab files and proof of concept
• @abraxas_null
• github.com/abraxas
• abraxaslabs.tech
• abraxas.null@proton.me