Pie Register Premium EUVD-2026-111559

No special conditions beyond the plugin being installed and active at any version up to and including 3.8.4.0 - exploitation is remote and unauthenticated because the piereg_file_upload AJAX handler enforces neither a nonce nor a capability check, and file-type validation errors from wp_check_filetype/wp_check_filetype_and_ext are never checked before move_uploaded_file() runs. The main limiting factor for full remote code execution (as opposed to mere file upload) is that the written file must land in a web-accessible directory where the server executes PHP; if the upload path is outside the webroot or PHP execution is blocked there, impact is reduced. No user interaction, authentication, or non-default setting is required for the upload itself.

All available signals point to genuine high priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated flaw with high confidentiality, integrity and availability impact (9.8), and the mechanism in the description corroborates it: the piereg_file_upload AJAX handler has no nonce or capability check and ignores the error results of wp_check_filetype/wp_check_filetype_and_ext before calling move_uploaded_file(), so an unauthenticated attacker can drop an executable PHP file. The vuln.today Decision label is act_now, and the response reportedly returns the generated destination filename, removing the usual guesswork of locating the payload - this materially lowers exploitation effort. No EPSS score was supplied, CISA KEV status is not indicated (treat as not listed), and no proof-of-concept or exploit reference appears among the inputs (the two references are a Wordfence advisory and the vendor homepage), so there is currently no evidence of active exploitation or public exploit code despite the act_now label. The practical caveat is that successful RCE depends on the uploaded file landing in a web-reachable, PHP-executing location; the description asserts RCE is possible but does not confirm the exact upload directory, so that final step should be verified against a target deployment.

An unauthenticated attacker sends a crafted POST to the plugin's AJAX endpoint invoking piereg_file_upload with a PHP file, which bypasses the unchecked file-type validation and is written to disk via move_uploaded_file(). The server returns the generated destination filename, so the attacker requests that URL to execute the PHP payload and obtain remote code execution. No public exploit code is identified in the provided data, but the described flow requires no authentication, user interaction, or special tooling.