The CVSS 9.8 score attached to CVE-2026-16230 is technically defensible for the worst-case scenario but analytically misleading if you treat it as representative of actual risk across the install base. This is a configuration-dependent vulnerability in Formidable Digital Signatures: exploitation requires a form that accepts anonymous submissions with file upload capability. If your site has no such forms enabled, this vulnerability is not exploitable against you — regardless of the severity score.
The vulnerability mechanism is straightforward: the plugin processes an item_meta[field_id][content] parameter during entry creation and passes it to a delete_saved_image function. An attacker who can submit a form anonymously can control the filename parameter and trigger deletion of files the web server can write to. What the CVE description does not specify is whether the deletion is scoped to the plugin's upload directory or whether path traversal allows deletion of arbitrary files on the filesystem. This distinction is critical — absolute path deletion would enable direct wp-config.php removal (complete compromise), while scoped deletion still enables denial of service or can be chained with other attacks (removing security plugins, deleting .htaccess for privilege escalation).
EPSS scores this at 0.00496, substantially lower than the CVSS severity would predict. This gap likely reflects that most WordPress administrators do not enable anonymous form submissions by default, and many who did have since disabled or abandoned that configuration. Treat the EPSS as a signal about deployment reality: the true attack surface is likely a small fraction of the 60,000+ Formidable Forms installations.
Your practical steps: first, audit whether any Formidable Forms or Digital Signatures forms are configured to accept anonymous submissions. If none exist, deprioritize this CVE. Second, if anonymous forms exist, determine whether file upload fields are present in those forms — the vulnerability requires both conditions. Third, assume path traversal is possible until proven otherwise; treat the deletion primitive as potentially enabling privilege escalation chains, not just DoS. Fourth, apply the patch immediately regardless of configuration, because the underlying API design (accepting user-controlled paths in a file deletion operation) represents a systemic failure regardless of whether your current setup exposes it.
The deeper pattern here is worth noting: this is the same vulnerability genotype that has appeared in multiple WordPress plugins over the past decade — file deletion via user-controlled parameters in form processing pipelines. The ecosystem has not yet built effective tooling to prevent this class of flaw, so treat each instance as a signal that your plugin dependencies warrant closer code review, not just vulnerability patching.