Since November 8, 2026, a critical flaw in Contact Form 7, one of the most widely used WordPress plugins, has been officially tracked as CVE-2026-114432. According to WordPress.org, the plugin runs on more than ten million websites. The vulnerability in versions 6.2 to 6.2.3 lets attackers upload arbitrary files to the server without logging in. On certain server configurations, this can lead to remote code execution. The patch has been available since October 29 in version 6.2.4.
The rating is high: the CVE record lists a CVSS 3.1 score of 9.8 (critical). At the same time, the situation is less dramatic than that number suggests, because the worst case requires a server configuration that not every site has. That is still no reason to wait.
What is behind CVE-2026-114432
Contact Form 7 supports forms with file upload fields, for example for job applications or attachments. According to the WPScan advisory, the affected versions do not properly validate the type or extension of uploaded files. On top of that, a flaw in the temporary-file cleanup leaves the uploaded file on disk. WPScan lists the issue as “Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename”.
Plugin developer Takayuki Miyoshi describes it in his release post for 6.2.4 like this: attackers can combine multiple flaws in 6.2 to 6.2.3 to upload files that the validation logic should block and to keep files that should be removed immediately after submission. In theory, every form with an upload field hosted on a server configured to list directory contents publicly can be a target.
The French CERT Santé, which published an alert on November 9, goes into more detail. According to the alert, version 6.2 removed the file type check from the function wpcf7_unship_uploaded_file(). Files land in uploads/wpcf7_uploads/ before any validation, and rejected files are never deleted. The remaining blocklist does not cover the extensions .phar, .pht and .phps or the .htaccess file. A simple unauthenticated POST request to the form’s REST route is enough for the attack.
When an upload becomes code execution
The server configuration is what matters. According to the CVE description, on a stock Debian or Ubuntu Apache configuration that lists directory contents and maps .phar to the PHP handler, the stored file can be located and executed, which leads to remote code execution.
On other configurations, such as nginx or Apache with .htaccess overrides enabled, the description says the impact is limited to an arbitrary file written into the uploads directory. That is not harmless either: such files may be served as active content such as HTML or SVG from the site’s own domain, a possible lever for phishing pages or cross-site scripting on the site’s own origin.
One hurdle for attackers: according to CERT Santé, the randomly named subdirectory where the file lands is not disclosed. That is why Patchstack rated the attack complexity as high. The CVSS score added to the CVE record by CISA, by contrast, assumes low complexity. This is where directory listing comes in: if the server lists directory contents, the random name is no longer an obstacle.
How serious is it?
As of November 9, there is no indication of active exploitation. CISA’s SSVC assessment in the CVE record reads “exploitation: none”, “automatable: yes”, “technical impact: total”. The flaw is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog. CERT Santé also reports no exploitation and no public proof of concept.
That may change. WPScan has announced it will publish the proof of concept on November 19, 2026, to give site owners time to update. From then on, the barrier to automated attacks drops considerably. For a plugin with more than ten million installations and an attack that needs no login, the effort is worth it for attackers.
Affected versions and patch
- Affected: Contact Form 7 6.2 up to and including 6.2.3
- Fixed: from 6.2.4 (released October 29, 2026); the plugin directory currently offers 6.2.4.1
- Requirements for 6.2.4: WordPress 7.1 or later
- Workaround: none, according to CERT Santé; the update is the fix
- Discovered by: Shinya Murakami and Jakub Herman, reported via WPScan
Miyoshi recommends the update for all users, even though the flaw only affects 6.2 to 6.2.3, because the security enhancements apply to all versions.
What site owners should do now
The following steps are based on the vendor and CERT information; steps two to four are general hardening practice, not an official workaround.
- Update to 6.2.4 or later. Even with automatic plugin updates enabled, check that the update has actually been installed.
- Inspect the
wp-content/uploads/wpcf7_uploads/directory. Because rejected files were not deleted in the affected versions, leftovers may be there, especially files with extensions such as.phar,.phtor.phpsand unexpected.htaccessfiles. - Turn off directory listing if it is enabled (on Apache, for example, with
Options -Indexes). - Block PHP execution in the uploads directory and check whether
.pharis mapped to the PHP handler on your server. - Review your own code: with 6.2.4, the second argument of
wpcf7_unship_uploaded_file()is mandatory and a third one was added. Anyone calling the function in custom extensions needs to update it.
Form owners should know about one side effect of the patch: wpcf7_antiscript_file_name() now uses a safelist of allowed file extensions instead of a blocklist. Common image, audio, video, PDF and text formats are included. Anyone who wants to accept ZIP files, for example, has to add them via the new wpcf7_file_extension_safelist filter; otherwise the extension is automatically converted into a safe alternative. Another changelog item fits the picture: text is now cleaned with wp_scrub_utf8() before regular expressions with the UTF-8 modifier are applied.
Our take
The case follows a familiar pattern: a change in a minor version removes a check, several small flaws add up, and a standard server configuration turns the result into code execution in the worst case. We saw something similar recently with the CryptoPayment Gateway flaw CVE-2026-81648, which was actively exploited, and with the WordPress updater that CISA added to its KEV catalog. The SQL injection CVE-2026-123488 in Craft CMS also shows how much time can pass between a patch and a CVE.
For Contact Form 7, ten days passed between the patch and the CVE, and as of today (November 9), ten days remain until the announced proof of concept. Site owners should use that time.
