Contact Form 7 Vulnerability CVE-2026-114432
How to Check Exposure and Patch the File Upload Flaw (6.2 to 6.2.3)
Contact Form 7 6.2-6.2.3 lets anyone upload files (CVE-2026-114432), and RCE is possible. Update to 6.2.4+ before the Nov 19 PoC. Commands, mitigations, FAQ.
Contact Form 7 versions 6.2 through 6.2.3 contain CVE-2026-114432 (CVSS 3.1 score 9.8, Critical), a flaw that lets an unauthenticated visitor upload arbitrary files. On a standard Debian or Ubuntu Apache setup this can lead to remote code execution (RCE). Version 6.2.4 and later (the current release is 6.2.4.1) fix it. WPScan plans to publish a proof of concept (PoC) on November 19, 2026, so update before then.
This article summarizes what could be confirmed as of November 9, 2026 from the WPScan advisory, the CVE record, the official Contact Form 7 release announcement and the WordPress.org plugin page. As of November 9, 2026, exploitation has not been confirmed and the flaw is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. CISA's SSVC assessment does mark it as automatable with total technical impact, so there is no need for alarm, but it is not something to put off. Where the sources are silent, we say so.
Key points in three lines
- Affected: Contact Form 7 6.2 through 6.2.3 (the CVE record says 6.2 up to, but not including, 6.2.4). 6.1.x and earlier are not affected. WordPress.org lists more than 10 million active installations
- What it is: the file upload field lets an unauthenticated visitor upload arbitrary files. Depending on the server this can mean RCE, and even where it does not, arbitrary files can land in the uploads directory
- Do today: update to 6.2.4 or later. You can check in the admin screen under Plugins, and after updating, send a test submission through every form that accepts attachments. WPScan's planned PoC date is November 19
Quick impact table
How serious this is depends on the plugin version and on how the web server is configured. The table below organizes the WPScan and CVE record details. If you do not know your server configuration, assume the worst row (possible RCE) and update quickly.
| Environment / version | Affected? | Likely impact / fixed version |
|---|---|---|
| Contact Form 7 6.2 to 6.2.3 on a standard Debian or Ubuntu Apache setup (directory listing on, .phar mapped to the PHP handler) | Yes | An uploaded file can be located and executed, so RCE is possible. Update to 6.2.4 or later |
| Contact Form 7 6.2 to 6.2.3 on nginx, or Apache with .htaccess overrides enabled | Yes | Arbitrary file placement in the uploads directory. HTML or SVG can be served from the site's own origin, enabling XSS or phishing. Update to 6.2.4 or later |
| Contact Form 7 6.1.x and earlier | Not affected | WPScan and the CVE record both start at 6.2. Staying on an old version is still not recommended for other reasons |
| Contact Form 7 6.2.4 / 6.2.4.1 | Fixed | Fixed in 6.2.4 (2026-10-29). 6.2.4.1 is 6.2.4 plus an update of FormDataTree-PHP to 2.0.10, released the same day |
What is happening
Contact Form 7 is the standard contact-form plugin for WordPress. A form can include a file upload field (the [file] tag) so visitors can attach images or documents. This vulnerability is in how that field is handled. WPScan titles it "Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename".
In plain terms, two weaknesses combine.
- File type and extension checks do not hold: an uploaded file's type and extension are accepted without passing the intended validation. According to the WPScan title, an attacker uses an invalid UTF-8 filename to slip past it
- Temporary files are not deleted properly: files created while the submission is processed stay on disk, so a file that should have been rejected remains on the server
- No authentication needed: the form is public, so any visitor can submit it (the CVSS vector shows PR:N, no privileges, and UI:N, no user interaction)
That alone only means arbitrary files get placed on the server. Whether a placed file is executed depends on the web server configuration. According to the CVE description, a standard Debian or Ubuntu Apache setup is the riskiest, because two things coincide there.
- Directory listing is on: an attacker does not need to know the filename, because the stored file can be found from the directory listing
- .phar is mapped to the PHP handler: files with the .phar extension are executed as PHP
With both in place, an attacker can upload a .phar file, find it through the listing, and run it. The result is remote code execution (RCE).
On nginx, or on Apache with .htaccess overrides enabled, the impact stops at arbitrary file writes into the uploads directory. Even then, HTML or SVG files can be served from the site's own origin, which could enable scripts running on your domain or convincing phishing pages. So "it is not RCE" does not mean "it is safe".
The official severity is CVSS 3.1 9.8 (Critical, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), the weakness is CWE-434 (unrestricted upload of file with dangerous type), and the CNA is WPScan. In CISA ADP's SSVC assessment, Exploitation is none, Automatable is yes and Technical Impact is total.
How to check whether you are affected
Work through three steps: (1) the Contact Form 7 version, (2) whether any form has a file upload field ([file] tag), (3) the web server configuration. If (1) is not 6.2 through 6.2.3, this issue does not apply to you.
Step 1: check the plugin version
- In the admin screen, open Plugins, then Installed Plugins, and read the Contact Form 7 version. If an update notice is shown, update
- If you have SSH access, use WP-CLI or read the plugin file directly
# WP-CLI: show version and whether an update is available
wp plugin list --name=contact-form-7 --fields=name,version,update
# Get only the version
wp plugin get contact-form-7 --field=version
# Without WP-CLI: read the plugin header
grep "Version:" wp-content/plugins/contact-form-7/wp-contact-form-7.phpIf it shows 6.2 through 6.2.3, you are affected. If it shows 6.2.4 or 6.2.4.1, you are fixed and can skip step 3. On multisite installs the plugin may be active on only some sites, so check the whole network.
Step 2: find forms that use a file upload field
Which forms can serve as an attack path depends on whether they use an upload field. The CVE description refers to the file field, so a site with no upload field may have a narrower attack path. That is an inference from the description, not a guarantee. Update regardless of whether you use upload fields.
# List the forms
wp post list --post_type=wpcf7_contact_form --fields=ID,post_title
# Check one form for a [file] tag (replace <ID> with a number from the list)
wp post get <ID> --field=post_content | grep "\[file"
# Loop over all forms and print the IDs of those with a file field
for id in $(wp post list --post_type=wpcf7_contact_form --field=ID); do
if wp post get "$id" --field=post_content | grep -q "\[file"; then echo "file field: $id"; fi
doneForms are stored as posts of type wpcf7_contact_form, so WP-CLI's post commands can read them. In the admin screen, open Contact, edit each form, and look for [file ...] or [file* ...] in the form template.
Step 3: check the web server configuration (Apache)
# List loaded Apache modules (look for php-related modules)
apachectl -M
# Search the configuration for .phar handling (Debian / Ubuntu)
grep -rn "phar" /etc/apache2/
# Check whether directory listing (Indexes) is enabled
grep -rn "Options" /etc/apache2/ | grep -i indexesThese are rough guides. Output differs by distribution and by how PHP was installed, so if you are unsure how to read it, simply apply the mitigations below together (disable directory listing and the .phar handler, and block PHP execution in uploads). On shared hosting you often cannot view or change these settings. In that case, update the plugin and watch the provider's announcements.
What to do, by environment
If you can update from the admin screen
- Take a backup of the site first, both files and database. The hosting provider's backup feature or a plugin is fine
- In Plugins, then Installed Plugins, click Update Now on Contact Form 7. Confirm the new version is 6.2.4 or later (6.2.4.1 is the current release)
- If no update button appears, go to Dashboard, then Updates, to refresh the update information. If it still does not appear, consider a manual update
- Then continue with the post-update checks below
If you manage the site with WP-CLI or SSH
# Back up the database first
wp db export backup-before-cf7-update.sql
# Update Contact Form 7
wp plugin update contact-form-7
# Confirm the version afterward (6.2.4 or later)
wp plugin get contact-form-7 --field=versionIf you manage several sites, run the same commands per site or use WP-CLI aliases. Restarting PHP-FPM is normally unnecessary, but on sites with object or page caching, check that the form pages are not serving stale content.
If a web agency or maintenance vendor handles the site
When you ask a vendor to do the update, a message like the following avoids misunderstandings. Put the version, the deadline and the items to report back in from the start.
Subject: [Urgent] Please update Contact Form 7 (CVE-2026-114432)
Hello,
Contact Form 7 versions 6.2 through 6.2.3 have a vulnerability
(CVE-2026-114432, CVSS 3.1 score 9.8) that lets an unauthenticated visitor
upload arbitrary files. Please update the plugin on our site to 6.2.4 or later
(the current release is 6.2.4.1).
WPScan plans to publish a PoC on November 19, so we would like this done before then.
Please also report back on the following.
1. The Contact Form 7 version on our site (before and after)
2. Whether any form uses a file upload field (the [file] tag)
3. The result of checking the uploads directory (for example
wp-content/uploads/wpcf7_uploads) for unexpected files
4. The result of a test submission after the update (including a form with an attachment)
5. Whether automatic updates are enabledIf your vendor tests on a staging site first, ask whether that schedule still beats November 19.
If you use shared hosting or a VPS
- Shared hosting: updating the plugin is your job. Server settings (directory listing, the .phar handler) are managed by the provider and often cannot be changed by you. Update the version, then check the provider's announcements and whether a WAF is available
- A Debian or Ubuntu VPS or dedicated server: this is closest to the configuration in the CVE description. Besides updating, review the Apache settings using the mitigations below
- nginx: according to the CVE description this means arbitrary file placement rather than RCE. You still need to update, and you should also confirm PHP cannot run from the uploads directory
- If a manual update is needed: when the admin screen cannot update the plugin, download it from WordPress.org and replace wp-content/plugins/contact-form-7. Back up first and keep the original file permissions and ownership
Mitigations while you cannot update yet
Updating is the priority, and the following only bridge the gap. Mitigations are not a substitute for the fix, so skip them wherever you can update. They are general guidance, so test them in your own environment before relying on them.
- Pause forms with a file upload field: remove the [file] tag. If there is no upload field, the attack path described in the CVE may be narrower
- Block PHP execution under uploads: deny php and phar with <FilesMatch> on Apache or a location block on nginx
- Disable Apache directory listing: Options -Indexes
- Remove the .phar handler mapping: do not let .phar files run as PHP if you do not use them
- WAF: restrict upload-related behavior with your service's rules
An Apache example follows. Put it in the .htaccess under wp-content/uploads or in the virtual host configuration. If the server does not allow AllowOverride, .htaccess will have no effect.
# Add to wp-content/uploads/.htaccess or the virtual host <Directory>
Options -Indexes
<FilesMatch "\.(php|phar|phtml|php[0-9])$">
Require all denied
</FilesMatch>An nginx example follows. After changing the configuration, check the syntax before reloading.
# Add inside the server { } block
location ~* /wp-content/uploads/.*\.(php|phar|phtml)$ {
deny all;
}
# Test and reload
# sudo nginx -t && sudo systemctl reload nginxBefore removing the .phar handler, confirm nothing else on the server uses it. On Debian and Ubuntu the configuration is split across files, so use the grep in the earlier section to find it. If you use a WAF, an attacker who can reach the origin server directly can bypass it, so also review who can reach the origin.
Checks after updating
Test submissions with attachments
According to secondary sources summarizing the release notes, in 6.2.4 wpcf7_antiscript_file_name() changed from a blocklist to a safelist approach. That moves from "reject dangerous extensions" to "accept only allowed extensions", which is the safer direction. A form that collects files with unusual extensions might stop accepting them after the update. After updating, check the following.
- From each form with an upload field, send a test submission with the kinds of files people actually attach (PDF, images, Office files and so on)
- Confirm the completion message appears, the email arrives and the attachment is included
- If you accept unusual extensions, check whether they are still accepted. If not, review how your process handles file types
- If you use anti-spam plugins or CAPTCHA, test through that path as well
Looking for traces
Updating blocks future attacks but does not remove files already placed. Exploitation has not been confirmed as of November 9, 2026, but as a precaution check the uploads directory for unexpected files. Contact Form 7's temporary storage defaults to wp-content/uploads/wpcf7_uploads. The following is a general procedure, and finding nothing is not proof that all is well.
# Find files created since October 1 with executable or servable extensions
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phar" -o -name "*.phtml" -o -name "*.html" -o -name "*.svg" \) -newermt 2026-10-01
# List what remains in the temporary storage directory
ls -la wp-content/uploads/wpcf7_uploads/Decide whether a file you find is legitimate (for example an SVG logo you added) by its creation time and contents. If you find a .php or .phar you do not recognize, preserve a copy and the access logs before deleting it, then move on to a full server check (admin account changes, modified files, password changes). If in doubt, consult your maintenance vendor or a security specialist.
Timeline
| Date | Event |
|---|---|
| 2026-10-29 | Contact Form 7 6.2.4 released (the fix). 6.2.4.1, with FormDataTree-PHP updated to 2.0.10, followed the same day |
| 2026-11-05 | WPScan publishes the advisory |
| 2026-11-08 | CVE-2026-114432 published (06:00 UTC) |
| 2026-11-19 (planned) | WPScan plans to publish a PoC, to give users time to update |
About a week passed between the fixed release and the advisory, which gave users some time to update. Since the PoC date has been announced, it is safest to assume exploit code will circulate after November 19. Until then, you can update calmly.
Checklist for today
- Checked the Contact Form 7 version (6.2 through 6.2.3 is affected)
- If affected, took a backup and updated to 6.2.4 or later (6.2.4.1 is the current release)
- Sent test submissions with attachments and confirmed the email and attachment arrive
- Identified which forms use a file upload field ([file] tag)
- Checked the uploads directory for unexpected .php, .phar, .html or .svg files
- If you cannot update yet, paused upload fields or blocked PHP execution under uploads
- If a vendor handles the site, requested the update and agreed on a completion report
- Set a goal of finishing the update before November 19 (the planned PoC date)
- Reviewed the automatic update settings
Related articles
Other vulnerabilities from the same week are in the November 9 vulnerability digest, and earlier ones in the November 7 vulnerability digest. For a similar WordPress case, see the WordPress wp2shell unauthenticated RCE guide; for update practice, WordPress maintenance in practice; for form spam, contact form spam protection; and for assessment costs, vulnerability assessment and penetration test pricing.
FAQ
Are older versions such as 6.1 affected?
WPScan and the CVE record both start at 6.2, so 6.1.x and earlier are not affected. Staying on an old version can still bring other vulnerabilities and compatibility problems, so we recommend updating. Check the WordPress and PHP version requirements first.
Am I safe if I do not use a file upload field?
The CVE description refers to the file field, so a site without one may have a narrower attack path. That is an inference from the description, not a guarantee. You might also have missed a form setting, so we recommend updating to 6.2.4 or later whether or not you use upload fields.
Should I turn on automatic updates?
For a small site, automatic plugin updates can reduce delays like this one. They also carry the risk of breaking display or submission after an update, so for important features such as forms, plan to test after updates. In the WordPress admin, Plugins lets you toggle automatic updates per plugin (the screen varies by WordPress version).
Can I tell whether I was already compromised?
Not conclusively, but you can look for unexpected .php, .phar, .html or .svg files under uploads (by default wp-content/uploads/wpcf7_uploads) and for suspicious POST requests in the web server access log. Exploitation has not been confirmed as of November 9, 2026, so finding nothing is reassuring but not proof. If you find something suspicious, preserve it before deleting and consult a specialist.
Should I update to 6.2.4 or 6.2.4.1?
Both are fixed. 6.2.4.1 is 6.2.4 with FormDataTree-PHP updated to 2.0.10, released the same day (2026-10-29). The current release on WordPress.org is 6.2.4.1, so updating from the admin screen brings you to it.
If I use nginx, is RCE not possible?
According to the CVE description, on nginx the impact is arbitrary file writes into the uploads directory rather than RCE. HTML or SVG can still be served from the site's own origin, enabling XSS or phishing, so you still need to update.
Sources
Related free tools (no sign-up, instant results)
Feel free to contact us
Contact Us