A WordPress form plugin lets a stranger delete your site, the moment an admin looks

An unauthenticated stranger can plant a payload in a WordPress site that deletes files on the server, and the trigger is one of your own administrators opening the saved-entries screen. That is the shape of CVE-2026-9843, a path-traversal bug rated 8.1 that Wordfence disclosed on June 20 in a form-database plugin running on more than 70,000 sites. The fix is in version 1.5.2. If you run the plugin, update today and read on for why a deletion bug is worse than it sounds.

The affected add-on, by CRM Perks, is the one whose dashboard label reads Database for Contact Form 7, WPForms and Elementor forms. It saves submissions into the WordPress database so site owners can read them in the admin. Every release through 1.5.1 carries the bug.

What does CVE-2026-9843 let an attacker do?

CVE-2026-9843 lets an unauthenticated attacker submit a form entry crafted so its file reference points outside the intended directory. When an administrator later opens that entry, the plugin removes the referenced file. Wipe wp-config.php and the attacker can seize the whole site.

The weak spot sits in the code that renders a stored submission for an admin, the view_page function. Rather than confining the file reference to the uploads folder, the plugin trusts a value carried inside the saved entry, so a reference that climbs the directory tree resolves to any file the web server is allowed to remove. The CVE record files it under CWE-22, the path-traversal class, and the scoring marks it network-reachable and credential-free to plant, with a high cost to integrity and availability.

The label says unauthenticated. The reality is a stored, deferred attack

That CVSS string hides the most important operational detail. The PR:N means no credentials are needed to plant the payload: anyone who can reach a public form drops it in. But UI:R means the deletion does not fire on submission. It waits, sitting in your entries table, until a logged-in administrator opens it in the dashboard. The admin pulls the trigger without knowing it.

This is not the same threat model as a direct unauthenticated remote code execution, and treating it like one will point your detection at the wrong place. There is no exploit request that both lands and detonates in a single shot. There is a quiet submission, then a delay, then a routine admin click. Defenders who only watch inbound exploit traffic miss it, because the harmful event is an internal admin action against attacker-controlled data. It also hands attackers a social-engineering lever: a submission written to look urgent or abusive is one an admin is more likely to open.

Why arbitrary file deletion means site takeover on WordPress

On most platforms, deleting a file is a denial-of-service problem. On WordPress it is a path to control. Remove wp-config.php and the application no longer believes it is installed, so the next visitor is served the setup wizard. An attacker who reaches that wizard first can point the site at a database they own, create their own administrator, and from the dashboard install a plugin or theme that runs code. File deletion becomes account creation becomes remote code execution.

That chain is why the CVE description ends at remote code execution even though the vector lists confidentiality impact as none. Nothing is read. Something is removed, and the removal reopens the front door. We saw the same end state, reached a different way, in the Joomla JCE flaw that turned three requests into a webshell: a single missing check on a content-management system collapses into full host control.

Who is affected and how to fix it

If your site runs this CRM Perks entries plugin at version 1.5.1 or earlier, you are exposed. It is popular precisely because it captures submissions from several form builders at once, so it shows up on sites whose owners think of themselves as Contact Form 7 or Elementor users, not users of a separate entries plugin. Check your plugin list by what each one does, not the brand you remember installing.

• Update to 1.5.2. CRM Perks shipped the patched release on June 19. This is the whole fix and the first thing to do.

• If you cannot update immediately, deactivate the plugin. The dangerous action is an admin viewing a stored entry, so an active plugin with unread public submissions is the live condition. Deactivating closes it until you can patch.

• Put file integrity monitoring on wp-config.php and core files. The deletion of wp-config.php is a high-signal event with no legitimate cause on a running site. Alert on it directly.

Form-entry plugins are an untrusted-input sink by design

Step back from the single bug and the category risk is clear. An entries plugin exists to persist input that arrives from strangers, then render and process that input inside a privileged admin view. The untrusted data and the trusted context meet by design, every time an admin opens the dashboard. One slipped validation check turns that meeting into an admin-context primitive.

This product line has a history that backs the point. Earlier 2025 and 2026 advisories for the same plugin covered object injection and file deletion through different functions, and 1.5.2 closes yet another route to the same outcome. The lesson is not that this vendor writes uniquely weak code. It is that any plugin storing public submissions for later admin review deserves the scrutiny you would give an upload handler. Treat it as an attack surface, keep it current, and watch the files it could touch. The same instinct applies to the WordPress add-ons that only misbehave for logged-in admins and to file-handling features in newer stacks, such as the Langflow file reader that became server takeover. Where untrusted input meets a privileged read or write, assume the gap until you have checked.