Extra Product Options Builder for WooCommerce < 1.2.176 – Unauthenticated Customer File Disclosure via getpublicfileupload | CVE 2026-19728

Description

The plugin does not verify that the requester is entitled to a customer-uploaded file before serving it, allowing unauthenticated users who obtain a file's stored name to retrieve it.

The plugin writes a deny-all rule into its upload directories, so the disclosure only crosses a boundary on web servers that honour it, such as Apache. Where it is ignored, as on a default nginx setup, the same files are already served at their direct URL and the endpoint exposes nothing further.

Proof of Concept

Affected: 1.2.174. Fixed: 1.2.176.

Setup

1. On a WordPress + WooCommerce install running Extra Product Options Builder for WooCommerce 1.2.174, create a simple product.
2. Edit the product, open the "Advanced Product Options" tab, add a "Signature" field and save.
3. As a logged out visitor, open the product page, draw a signature, add the product to the cart and complete the checkout.
4. On the order confirmation page, view the page source and copy the stored file name out of the signature link, that is the value of the "path" parameter.

Disclosure

5. From a client holding no cookies, request the file:

curl -i "https://example.com/wp-admin/admin-ajax.php?action=rednaowooextraproduct_getpublicfileupload&path=STORED_NAME.png&name=signature"

The signature image is returned with HTTP 200 and Content-Type: image/png. No nonce, no authentication, and no check that the requester placed the order.

Boundary check, which the finding depends on

6. With the same client, request the file directly:

curl -i "https://example.com/wp-content/uploads/rednaowooextraproduct/OrderFiles/STORED_NAME.png"

On Apache, which honours the "deny from all" .htaccess the plugin writes into that directory, this returns 403 while step 5 returns the file. On a default nginx setup, which ignores .htaccess, this returns the same image, so step 5 discloses nothing that was not already reachable.

Fixed build

7. Repeat step 5 against 1.2.176. The response is HTTP 401.
8. The endpoint still serves entitled callers on 1.2.176: the same anonymous request carrying the file token the plugin now issues returns the image, and the legacy route carrying the order's real WooCommerce order key returns it as well.