CVE-2026-6070 is a critical, unauthenticated arbitrary file deletion flaw in the WP-BusinessDirectory plugin for WordPress (versions up to and including 4.0.1). Because a public, no-login endpoint accepts a raw filename and fails to strip ../ path-traversal sequences, an attacker can make the server delete files anywhere the web server can reach — including wp-config.php. Deleting wp-config.php is a well-known route to full site takeover, since WordPress then treats the site as a fresh install and lets whoever reaches it first re-run setup. The record was published July 1, 2026 by Wordfence (the assigning CNA) and carries a CVSS 9.1 rating. Update immediately.

What the Vulnerability Is

The root cause is insufficient path validation in the remove() method of the plugin's JBusinessDirectoryControllerUpload class. The task=upload.remove endpoint is reachable without authentication through the plugin's front-end routing system. The _filename parameter is read with a RAW filter — no sanitization at all — and the helper function makePathFile() only normalizes directory-separator characters. It never strips path-traversal sequences (../).

When an attacker combines that with _path_type=2 (which sets the base directory to the plugin's site folder), they can supply a _filename value stuffed with ../ sequences to climb out of the plugin directory and hand an arbitrary path to PHP's unlink(). The result: unauthenticated deletion of any file the web server process can write to, including wp-config.php, wp-config-backup.php, and other critical files. This is classic External Control of File Name or Path (CWE-73).

Why It Matters

  • No login required. The vulnerable endpoint is exposed to anonymous visitors, so exploitation needs nothing but network access to the site.
  • wp-config.php deletion = takeover. Removing wp-config.php drops WordPress into its unconfigured "install" state. An attacker who then re-runs the setup wizard can point the site at their own database and seize full administrative control.
  • Site destruction / denial of service. Even without a full takeover, deleting core files, plugin files, or uploaded content can take a site completely offline.
  • Trivial to automate. File-deletion path-traversal bugs like this are easy to weaponize and mass-scan for; expect opportunistic exploitation across exposed installs.
  • CVSS 9.1. High integrity and availability impact, network attack vector, low complexity, no privileges, no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H).

Am I Affected?

You are exposed if all of the following are true:

  • You run the WP-BusinessDirectory plugin by CMSJunkie on a WordPress site.
  • The installed version is 4.0.1 or earlier.
  • The site is reachable over the network (i.e., essentially any live site).

If you're not sure whether the plugin is installed, check Plugins → Installed Plugins in wp-admin for "WP-BusinessDirectory," or look for a wp-businessdirectory folder under wp-content/plugins/.

What to Do About It: Step-by-Step

Step 1: Back up first — safely

Take a full backup of files and database before making changes, and store it off the server. Verify you already have a known-good copy of wp-config.php, since that file is the prime deletion target.

Step 2: Update the plugin now

In wp-admin go to Plugins → Installed Plugins, find WP-BusinessDirectory, and update to the latest available release (a version above 4.0.1 that includes the fix). At scale, push via WP-CLI:

wp plugin update wp-businessdirectory --path=/var/www/your-site

Step 3: If you can't patch immediately, block the endpoint

Add a WAF/web-server rule that denies requests carrying task=upload.remove, or requests where _filename contains ../ or encoded traversal (%2e%2e, ..%2f). Example NGINX guard:

if ($arg_task = "upload.remove") { return 403; }

Treat this only as a stopgap until the update is applied.

Step 4: Verify critical files still exist

ls -l /var/www/your-site/wp-config.php

If wp-config.php is missing, do not let anyone re-run the WordPress installer — restore the file from backup first, then investigate.

Step 5: Hunt for exploitation

grep -Ei "upload\.remove|_filename=.*\.\./" /var/log/nginx/access.log

Look for unexpected 200s to the plugin's upload routes and for missing files.

Step 6: If compromised, rebuild trust

Restore from a clean backup taken before the earliest suspicious request, rotate all secrets (database password, wp-config.php salts/keys, admin passwords), and review users/roles for rogue admin accounts.

Quick-Win Checklist

  • Confirmed whether WP-BusinessDirectory is installed and its version.
  • Updated WP-BusinessDirectory to a fixed release above 4.0.1.
  • Took and off-server verified a full backup, including wp-config.php.
  • Added a temporary WAF/server rule blocking task=upload.remove and ../ in _filename (if patching is delayed).
  • Verified wp-config.php and core files are present and untouched.
  • Searched access logs for upload.remove and traversal attempts.
  • Rotated secrets and reviewed admin accounts if any sign of compromise.

Sources