Critical CF7 Extensions Flaw: Update Now

If your WordPress site runs the Extensions For CF7 plugin at version 3.4.5 or older, update it to the latest version today, because CVE-2026-94589 lets an anonymous visitor upload files that may be executable, which can lead to remote code execution (an attacker running their own code on your server).

This post is for owners of small WordPress sites who use Contact Form 7 and may have added helper plugins around it. You will learn what the flaw is, how to check whether you are affected, the exact steps to fix it, and how to look for signs that something already slipped in.

What the flaw is, in plain English

The plugin is called Extensions For CF7 (its full name is "Contact form 7 Database, Conditional Fields and Redirection"). It adds extra features to Contact Form 7 forms, including a signature field.

According to the National Vulnerability Database (NVD) record for CVE-2026-94589, versions up to and including 3.4.5 have an arbitrary file upload problem. The weak spot is a function called extcf7_submit. Here is what the record says is wrong, in simpler words:

• The signature field does not properly check what kind of file is being sent. It skips checks on the file extension (like .jpg or .php), the MIME type (the label a file carries about its type), and the file size.
• The folder where files land has no guard that stops PHP files from running.
• A filename-cleaning step can be tricked. A name like shell.php- gets turned into shell.php.

Put together, the record says unauthenticated attackers (people with no account on your site) can upload files that may be executable. That makes remote code execution possible.

The NVD lists the weakness as CWE-434, "Unrestricted Upload of File with Dangerous Type". OWASP explains this whole bug class well if you want more background.

How serious is it?

The record lists a severity of Critical, CVSS 9.8 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). CVSS is a standard 0 to 10 scoring system for vulnerabilities. The vector reads like this:

• AV:N means it can be attacked over the internet.
• AC:L means the attack is not complicated.
• PR:N and UI:N mean no login and no click from a victim are needed.
• C:H, I:H, A:H mean high impact on confidentiality, integrity and availability.

The NVD page was published on 2026-10-10. Its status is shown as "Deferred". That only describes the NVD's own processing of the record. It is not a sign that the issue is minor.

We have no confirmed information from the source about attacks happening in the wild, so we won't claim any. But a flaw that needs no login and is easy to try is the kind that gets tested widely once it is public. Treat it as urgent.

Is this the same as a Contact Form 7 vulnerability?

Not exactly. This is a Contact Form 7 vulnerability in an add-on, not in Contact Form 7 itself. The NVD record names the Extensions For CF7 plugin only. Many people search for "Contact Form 7 vulnerability" and find alarming headlines about the whole ecosystem, so it helps to know which plugin is actually involved.

Here is a quick way to sort out your situation:

The description points at the signature field code. The record does not say whether sites that never use a signature field are safe. So assume any site with the plugin at 3.4.5 or older is exposed.

Step by step: how to fix it

1. Check your version. In your WordPress dashboard, go to Plugins > Installed Plugins and find "Extensions For CF7". The version number sits under its name. If you have command-line access with WP-CLI (a tool for managing WordPress from a terminal), run:

wp plugin list --name=extensions-for-cf7 --fields=name,status,version

2. Back up first. Take a quick backup of your files and database through your host or a backup plugin. If the update breaks a form, you can roll back.

3. Update the plugin. In the dashboard, click Update now under the plugin. Or with WP-CLI:

wp plugin update extensions-for-cf7

4. Confirm the new version. The NVD record does not list a fixed version number. It does link to a vendor code change comparing 3.4.5 and 3.4.6 in the WordPress plugin repository, which suggests the fix landed around that release. Update to the latest version available and read the plugin's changelog on its WordPress.org page to confirm the fix is in your version.

5. If you can't update, take it out of service. Because the plugin's name includes "Contact form 7 Database", it may hold saved form entries. Export any saved entries before you delete anything, since removing the plugin may also remove that data. Then deactivate the plugin and remove it if you can do without it. Deactivating alone may not be enough: the record does not address deactivated plugins, so a deactivated copy may still be exposed. Check what your forms do without it. Removing the plugin is safer than leaving a known critical hole open.

6. Test your forms. Submit a test message through each form that uses the plugin's features, such as redirects or conditional fields. Check that you receive the email.

How to check if something already got in

Updating closes the door. It does not remove anything an attacker may have already left inside. Spend ten minutes looking.

Look for PHP files in your uploads folder. Normal uploads are images, PDFs and similar files. PHP files there are almost never legitimate. From your site's root folder, run:

find wp-content/uploads -type f \( -iname "*.php" -o -iname "*.php[0-9]" -o -iname "*.phtml" -o -iname "*.pht" -o -iname "*.phar" \)

If this lists nothing, that is a good sign. If it lists files you do not recognize, do not open or run them. Note the names and dates, then follow our website hacked guide.

Look for recently changed files. This lists PHP files changed in the last 30 days anywhere in wp-content:

find wp-content -type f -iname "*.php" -mtime -30

Some of these will be normal, like plugin updates you just ran. Look for odd names, files inside the uploads folder, or files you can't tie to any plugin or theme. File dates can be faked by an attacker, so treat this check as a hint, not proof.

Check for other warning signs.

• Admin users you did not create (Users > All Users)
• Spam pages or strange redirects on your site
• Your host emailing you about malware or high resource use
• Search results showing odd pages from your domain

A clean result from these checks is encouraging but not proof. Skilled attackers can hide. If you have doubts, the free website security check is a quick outside look, and a human review goes deeper.

Add a safety net: block PHP in your uploads folder

The NVD record mentions that the upload folder lacked guards against PHP execution. You can add that guard yourself. It will not replace updating, but it limits the damage if a file upload bug shows up in some other plugin later.

Apache (2.4): create or edit wp-content/uploads/.htaccess and add:

<FilesMatch "(?i)\.(php|php[0-9]|phtml|pht|phar)$">
  Require all denied
</FilesMatch>

The (?i) makes the match ignore upper and lower case, so a file named shell.PHP is blocked too. Note that .htaccess rules do nothing when your host sets AllowOverride None, or when the server does not read .htaccess files at all, as with Nginx. On those setups, use the server config or ask your host.

Nginx: add this to your server config, placed above your general PHP handling block, then reload Nginx:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

After changing this, load a page with images to make sure uploads still display. Not sure about your server type or on managed hosting? Ask your host to apply "no PHP execution in uploads". Many can do it quickly. WordPress's own hardening guide covers related protections.

Why a WordPress file upload hack is so damaging

A WordPress file upload hack is dangerous because the uploaded file can be a small program, often called a web shell. If the server runs it, the attacker gets a remote control panel for your site. From there they can read your database, steal customer form submissions, add spam pages, or install more malware.

That is why file upload flaws that need no login score so high. There is no password to guess and no staff member to trick. We cover how to think about this kind of exposure in our guide on whether your website is hackable.

A few habits make these events far less stressful:

• Turn on automatic updates for plugins you trust, or set a weekly reminder to review them.
• Delete plugins you don't use. Deactivated plugins may still be exposed if their files remain.
• Keep regular, tested backups stored away from your web server.
• Give your forms only the features they need. Fewer add-ons means fewer places for bugs to hide.

Key takeaways

• If Extensions For CF7 is at 3.4.5 or older, you are in the affected range for CVE-2026-94589 (CVSS 9.8, Critical). Update now.
• The NVD record lists no fixed version, so update to the latest release and confirm the fix in the plugin's changelog.
• After updating, search wp-content/uploads for PHP files and check for unknown admin users.
• Block PHP execution in your uploads folder as a second layer of protection.
• If you can't update right away, export any saved form entries, then deactivate and remove the plugin. The record does not address deactivated plugins, so a deactivated copy may still be exposed.

What to do next

Updating fixes this one hole. It does not tell you what else is exposed on your site. A Bug Circuit audit (Circuit, $49 one-time) has a real person go through your whole site by hand and deliver a written report with severity, evidence and exact fixes. It is a focused small-site audit, not a multi-week enterprise pentest or a compliance certification. To understand the difference, read how manual and automated testing compare.