Contact Form 7 flaw lets anyone upload files without login

On 31 October 2026 Patchstack published a vulnerability in the Contact Form 7 form plugin, and on 8 November it was assigned CVE-2026-114432. Versions 6.2 to 6.2.3 are affected. Through a form with a file attachment field, someone without an account can upload a file of any type they like to the server. The fix is in version 6.2.4, released on 29 October. According to wordpress.org, the plugin has more than 10 million active installations.

The flaw only affects sites where at least one form has a file field, for a CV, a photo or a document sent with an enquiry, for example. The worst case, running someone else's code on the server, also depends on how the server is configured. That is why the published scores differ, but every site on 6.2 to 6.2.3 needs the update.

How the vulnerability works

When a visitor submits a form with a file, Contact Form 7 moves the file into the temporary folder wp-content/uploads/wpcf7_uploads/, inside a subfolder named with ten random digits. From there it attaches the file to the email and then deletes it. We compared the code of 6.1.7, 6.2.3 and 6.2.4. Up to 6.1.7 the plugin checked the file's type and size before moving it. From 6.2 onwards it moves the file first and only checks it afterwards.

In versions 6.2 to 6.2.3, a file the plugin has already moved is not marked for deletion if processing stops with an error. Such a file stays in the folder. The title of the WPScan entry says the attack goes through a file name containing invalid characters (invalid UTF-8). The list of blocked extensions in these versions is short (php, phtml, pl, py, rb, cgi, asp and aspx), and Patchstack notes that it misses phar, pht, phps and .htaccess, among others.

Version 6.2.4 marks every moved file for deletion, even when processing stops with an error. It strips invalid characters from file names before handling them. It also replaces the list of blocked extensions with a list of allowed ones (images, audio, video, PDF and TXT). A file with any other extension gets "_.txt" added to the end of its name, so the server treats it as plain text.

The flaw was found by the researchers Shinya Murakami and Jakub Herman. In the CVE record, CISA scores it 9.8 on the CVSS scale, "critical". Patchstack gives it 8.1, noting a high attack complexity because the attacker cannot see the name of the random subfolder. The CVSS score guide explains what these scores mean. As of 8 November, CISA notes that there is no evidence of attacks, but that the attack can be automated. WPScan will publish the proof of concept on 19 November 2026. Update before that date.

Which sites are affected

A site is affected if it runs Contact Form 7 6.2 to 6.2.3 and at least one form has a file field. In the form editor these are the [file] and [file*] tags. The address that forms send their data to accepts requests from anyone, as is normal for a form. It also accepts the number of any form in the list, even one that is not placed on any page. So check every form under Contact > Contact Forms, not only the ones visible on the site.

According to the CVE record, code execution is possible on a stock Debian or Ubuntu Apache configuration, which lists directory contents and runs .phar files as PHP. On other configurations, such as nginx or Apache reading .htaccess files, the attacker can only leave a file in the uploads folder. The record warns that even such a file may be opened from your site's own address, for example as an HTML page or an SVG image with a script inside. If you do not know how your server is configured, treat the site as vulnerable.

Version 6.2 requires WordPress 7.1 and PHP 8.3. A site on older versions has usually stayed on 6.1.x, which is not affected.

Is your site affected?

You can see the version under Plugins > Installed Plugins. In cPanel's Terminal, the command below shows the Contact Form 7 version and whether the plugin is active. The WP-CLI guide explains how to work with WP-CLI.

# cPanel > Terminal, in the site's folder
# Read-only. Shows the Contact Form 7 version.
wp plugin list --fields=name,status,version \
  --skip-plugins --skip-themes | grep -i contact-form-7

If the version is 6.2.4 or later, or 6.1.x or older, this vulnerability does not affect you. If it is 6.2 to 6.2.3, find out which forms have a file field. The next command prints their titles.

# cPanel > Terminal, in the site's folder
# Read-only. Contact Form 7 forms that have a file field.
for id in $(wp post list --post_type=wpcf7_contact_form \
    --post_status=any --format=ids); do
  wp post get "$id" --field=post_content \
    | grep -qE '\[file\*?[[:space:]]' \
    && wp post get "$id" --field=post_title
done

An empty result means no form has a file field. Update anyway, because such a field can be added at any time.

The next two commands look for traces of an attempted attack. The first searches the cPanel logs for requests to the plugin's temporary folder, where an ordinary visitor has no business.

# cPanel > Terminal
# Read-only. Requests to the Contact Form 7 temporary folder.
zgrep -h "/wp-content/uploads/wpcf7_uploads/" ~/access-logs/* \
  ~/logs/*.gz 2>/dev/null | tail -n 20

The second searches the uploads folder for files with a PHP extension that appeared after 6 October, when version 6.2 came out.

# cPanel > Terminal, in the site's folder
# Read-only. Files with a PHP extension in the uploads folder.
find wp-content/uploads -type f \( -iname "*.php*" \
  -o -iname "*.pht*" -o -iname "*.phar" \) -newermt 2026-10-06

Some plugins put an empty index.php in their folders, and that is normal. Look into any other file like that. An empty result from both commands is a good sign, though not proof, because the logs only go back a few weeks.

What to do

1. Back up the files and the database, as described in the backup guide.
2. Update Contact Form 7 to 6.2.4.1 from Dashboard > Updates or Plugins > Installed Plugins. It came out on the same day as 6.2.4 and includes the fix. Then check the version again with the first command. The guide to updating plugins shows how to update without surprises.
3. Send a test enquiry through every form with a file field and check that the email arrives with the attachment. According to the 6.2.4 code, a file with an extension outside the allowed list, such as a Word document or a ZIP archive, arrives with "_.txt" added to the end of its name. The recipient has to remove the addition to open the file. The list can be extended with the wpcf7_file_extension_safelist filter, but that is a job for a developer.
4. If the checks turn up a suspicious file or requests to wpcf7_uploads, look through Users for administrators you do not recognise, change the passwords and work through the guide for a hacked site. If the site is hacked or down right now, see emergency help.

What we do

With vulnerability (CVE) monitoring we track what is installed on your site and match it against the vulnerability (CVE) databases every day. As soon as a vulnerability appears in something you use, we send you an alert and update, trying the update on a copy in staging first. Your site can be hosted anywhere. If you would like us to add it, write to us through the inquiry form.

Sources

• NVD, CVE-2026-114432
• CVE.org, CVE-2026-114432
• WPScan, Contact Form 7 6.2 - 6.2.3, Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename
• Patchstack, Contact Form 7 6.2-6.2.3, Unauthenticated Arbitrary File Upload
• WordPress.org, Contact Form 7
• WordPress.org Plugin SVN, Contact Form 7 6.1.7, includes/file.php
• WordPress.org Plugin SVN, Contact Form 7 6.2.3, includes/file.php
• WordPress.org Plugin SVN, Contact Form 7 6.2.4, includes/submission.php
• WordPress.org Plugin SVN, Contact Form 7 6.2.4, includes/formatting.php
• WP-CLI, wp plugin list
• WP-CLI, wp post list