IvyForms EUVD-2026-111750

Two-stage prerequisite: (1) a user with the custom 'add_edit_forms' capability must first create and publish a File Upload field that explicitly includes a dangerous extension (e.g., php) in the allowed-extensions list - the plugin's sanitizer lacks a dangerous-extension denylist and its registered wp_check_filetype_and_ext filter overrides WordPress's native MIME/extension checks; (2) after that form is live, exploitation of the upload itself requires NO authentication and NO user interaction via the public /wp-json/ivyforms/v1/form/submission/ REST route. The principal limiting factor is step 1: an attacker must either hold the add_edit_forms capability or compromise an account that does, and a dangerous extension must be deliberately configured - a default form that only permits benign extensions would not be exploitable.

This is a credible, near-term priority rather than inflated CVSS noise, but its real-world risk is gated by a configuration prerequisite that the raw 8.8 score hides. The CVSS vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:H) models the attacker who holds the custom 'add_edit_forms' capability needed to arm the vulnerable form, which is why it shows PR:L; however, the description makes clear that once a malicious form is published, the actual file upload is reachable by any UNAUTHENTICATED visitor over a public REST route, so the practical attack surface is broader than PR:L alone suggests. No EPSS score was supplied and the vulnerability is not listed in CISA KEV, so there is no signal of active or widespread exploitation at this time; there is also no confirmed public exploit. The vuln.today decision label is 'this_week', consistent with a Wordfence-reported, RCE-capable WordPress plugin flaw that warrants prompt patching but is not flagged as an emergency. Net: real CWE-434-to-RCE impact, mitigated in practice by the requirement that a privileged user first configure a dangerous extension; treat as high priority for any site running this plugin, especially multi-author sites where lower-trust users hold form-editing capability.

An authenticated user with the custom 'add_edit_forms' capability (or an attacker who has compromised such an account) creates a File Upload form field that lists a dangerous extension such as 'php' in its allowed-extensions list and publishes the form. Any unauthenticated visitor then POSTs a PHP webshell to the public /wp-json/ivyforms/v1/form/submission/ REST route, bypassing WordPress's native MIME/extension defences (which the plugin deliberately overrides via a wp_check_filetype_and_ext filter), and requests the stored file to execute code on the server. No public exploit code has been identified at time of analysis.