WordPress Arbitrary File Deletion Bug Hits Formidable Signatures

CVE-2026-16230 carries a CVSS score of 9.8, critical, unauthenticated. The plugin is Formidable Digital Signatures, an add-on for Formidable Forms that lets site owners collect signed consent on a form entry. Every version up to and including 3.0.6 is affected. The fix shipped in version 3.1, disclosed on August 11, 2026.

A 9.8 score on a file deletion bug tends to surprise people who haven't looked closely at the class. Deletion sounds like vandalism: an attacker knocks out a page template or an upload, you restore from backup, you move on. That reaction is exactly why arbitrary file deletion vulnerabilities get under-triaged. This one is a useful case study in why a scanner, and a site owner, should treat a deletion primitive as seriously as a code execution bug the moment it can reach one specific file: wp-config.php.

How the flaw works

The vulnerability sits in the plugin's delete_file function, which handles removing a previously uploaded signature image from a form entry. Wordfence's advisory describes the root cause as insufficient file path validation in that function.

Here's the reachable path. Formidable Forms processes entry submissions through a standard POST flow, and any form built with the digital signature field accepts that POST from anonymous visitors if the form itself allows anonymous submissions, which is the normal, intended configuration for a public consent or agreement form. The plugin exposes a delete_saved_image flag alongside the item_meta[field_id][content] parameter. When that flag is set, delete_file reads the filename out of the content value and deletes whatever it resolves to.

The problem is what "resolves to" means. If the function trusts the filename as handed to it, rather than confirming the resolved path stays inside the signature upload directory, an attacker can supply a value that points somewhere else entirely. No login, no capability check, no unusual endpoint. It's the same POST request a legitimate signer would submit, with one parameter altered.

Formidable's own changelog for 3.1 confirms the shape of the fix: "additional validation has been added to guarantee that only signature files can be deleted, and that only a signature associated with the active entry can be deleted." That's a precise description of what 3.0.6 was missing. It wasn't checking that the target file was (a) actually a signature file and (b) actually tied to the entry being submitted.

Notice what that fix description implies about the original code: it wasn't just a missing path check, it was a missing ownership check. Even a function that correctly confined deletion to the uploads directory would still be broken if it let any visitor delete any other visitor's signature file. The 3.1 fix closes both gaps at once, tying the deletable file to the specific entry the current request is allowed to touch, not just to a directory boundary.

The attack requires nothing beyond what a normal signer could send. There's no admin panel involved, no special request header, no need to guess a nonce or bypass authentication, because the entry-creation endpoint is meant to be open to the public in the first place. That's what separates this from a typical file-deletion bug gated behind a login screen: the entire vulnerable code path is the plugin's intended, documented way of accepting a form submission.

Who is affected

Every site running Formidable Digital Signatures 3.0.6 or earlier is vulnerable, with one condition that determines how exposed you actually are: the form using the signature field has to accept anonymous submissions. That's the default and by far the most common setup for signature forms, since the entire point is usually to let an external party, a client, a vendor, a job applicant, sign something without needing a WordPress account first.

If every form on your site that uses the digital signature field requires a logged-in user to submit, your exposure is narrower. An attacker would need at least a subscriber-level account, and the attack surface shrinks to whatever your registration policy allows. Check your form settings rather than assuming; this is a real, checkable distinction, not a hedge.

Why deletion primitives deserve critical treatment

Security tooling and CVSS scoring both tend to rank confidentiality and code execution above availability. A bug that deletes a file "only" affects availability, in the strict CVSS sense, which is one reason deletion bugs sometimes get quietly filed as denial-of-service and deprioritized. That framing misses the part that matters: on a WordPress install, one specific file turns availability loss into full compromise.

wp-config.php holds the database credentials, authentication salts, and table prefix that every part of WordPress relies on to know it's already installed. Delete that file, and WordPress can no longer find its configuration. The next visit to the site triggers the setup wizard, the same wizard that runs on a brand-new install, asking for database host, name, username, and password.

That's the well-documented escalation route for arbitrary file deletion bugs, not a guaranteed outcome of this specific CVE. It requires the attacker to reach the installer with their own database credentials before a legitimate administrator notices the site is down and restores wp-config.php from a backup or host snapshot.

On a site nobody is actively watching, that race favors the attacker. On a well-monitored site, an admin gets an alert or a support ticket within minutes and the window closes fast. The point isn't that this CVE hands over the site automatically. It's that the deletion primitive plus one predictable filename equals a takeover path, which is why a bug like this earns a 9.8 rather than a mid-range score for "some file got deleted."

This is also why scoring deletion bugs by their immediate symptom undersells them. A read vulnerability that exposes wp-config.php is scored as a confidentiality loss and treated as urgent by most teams on sight, because the credentials are visible the moment the file is read. A deletion vulnerability that reaches the same file produces no visible leak at all, just a broken site, and yet it opens a path to the same database credentials by way of the setup wizard asking the attacker to type in new ones. The end state is comparable. The triage instinct usually isn't.

We've written about this same escalation pattern before, in the Perfmatters arbitrary file deletion vulnerability, where a subscriber-level bug reached the same wp-config.php target through a different function. It's worth treating any deletion bug you see, in any plugin, as a candidate for this chain until you've confirmed otherwise.

The fix: realpath() and containment, not string filtering

The naive way to "validate" a filename is to strip suspicious substrings: block ../, run it through basename(), call it done. That approach fails constantly, because there are multiple ways to encode a traversal sequence and multiple filesystem quirks a simple string filter doesn't account for. Compare a stripped-input approach with one that resolves the real path and checks containment:

// Fragile: string filtering
$name = str_replace('../', '', $_POST['filename']);
$name = basename($name);
unlink($upload_dir . '/' . $name);

// Robust: resolve and contain
$target = realpath($upload_dir . '/' . $_POST['filename']);
$base   = realpath($upload_dir);
if ($target === false || strpos($target, $base) !== 0) {
    wp_die('Invalid file path.');
}
unlink($target);

realpath() resolves symlinks and .. segments into an absolute path, or returns false if the path doesn't exist. Checking that the resolved path starts with the resolved base directory catches every traversal encoding at once, because it doesn't matter how the attacker spelled the path, only where it actually points. This is the same class of bug and the same class of fix we walked through for The Events Calendar's path traversal CVE: validate the destination, not the input string.

What to do now

Update Formidable Digital Signatures to version 3.1 or later. That's the fixed release, and there's no configuration workaround that closes this hole while running 3.0.6 or earlier, short of disabling anonymous submissions on every form that uses the signature field.

If you were running an affected version before applying the update, check a few things. Look for missing files in your signature uploads directory, and compare against your form entries to see if any expected signature images are gone. Confirm wp-config.php is present and unmodified; if your host keeps file-integrity or backup history, diff the current file against a known-good backup rather than assuming it's fine because the site is still up. Review each form using the digital signature field and note whether it accepts anonymous submissions, since that's the detail that determines your actual exposure window going forward.

If you find files missing that you didn't expect, or if wp-config.php shows a modification timestamp you can't explain, treat it as a possible compromise rather than a coincidence and work through the steps in our WordPress malware removal guide. Unusual admin accounts, unfamiliar files in the uploads directory, or a site that suddenly shows the WordPress install wizard are all signs worth checking against our guide to spotting a hacked WordPress site.

It's also worth checking whether wp-config.php ever went missing even briefly, not just whether it's intact now. A host with fast automatic recovery, or an admin who caught the outage and restored quickly, can leave the file looking perfectly normal while an attacker still had a window to run the setup wizard against a database they controlled. Server access logs and host-level uptime monitoring are more reliable evidence here than the current state of the file itself. If your hosting provider keeps request logs, look for POST requests to the affected form around the time in question, particularly ones carrying an item_meta parameter with a delete_saved_image flag and a path-like value in the content field.

WP Vanguard's scanner flags plugins running known-vulnerable versions like Formidable Digital Signatures 3.0.6 and earlier, so a delayed update doesn't sit unnoticed on a live site.

References

• CVE-2026-16230 — NVD
• CVE-2026-16230 — THREATINT vulnerability record
• Digital Signature Forms v3.1 changelog — Formidable Forms
• Patchstack: Learn about Arbitrary File Deletion