Contact Form 7 versions 6.2 through 6.2.3 accept files through a form upload field without checking what type of file it is, and a cleanup bug leaves that file sitting on disk. On a default Debian or Ubuntu Apache server the stored file can be reached and run as PHP.
What happened
The flaw is CVE-2026-114432, published on 8 November 2026 with WPScan as the assigning CNA. Before 6.2.4 the plugin's filename filter was a denylist of eight script extensions with an optional trailing digit: php, phtml, pl, py, rb, cgi, asp and aspx. Anything outside that short list kept its real extension, so a .phar file passed straight through. A second defect meant the temporary upload was not removed afterwards, so the file stayed behind in the uploads directory.
On stock Debian or Ubuntu Apache, directory listing is enabled and .phar maps to the PHP handler. That combination turns an anonymous form submission into remote code execution. On nginx, or Apache with .htaccess overrides switched on, the published record describes the outcome as an arbitrary file written into uploads that can still be served as HTML or SVG from the site's own domain.
The maintainer shipped the fix in 6.2.4 on 29 October, before the CVE became public, and 6.2.4.1 is the current build. The patch reverses the logic entirely, replacing the denylist with a safelist of audio, video, image, pdf and txt.
Who is affected
- Any site running Contact Form 7 version 6.2, 6.2.1, 6.2.2 or 6.2.3.
- Specifically those sites with a published form that contains a file upload field, which is standard on most contact, quote and CV forms.
- Worst case is Debian or Ubuntu Apache hosting where directory listing is on and .phar is handled as PHP.
- The flaw is not on CISA's Known Exploited Vulnerabilities list, and no exploitation was confirmed at publication.
What to do now
Update Contact Form 7 to 6.2.4.1 or later today, then check the uploads directory for files nobody on your team put there.
- Run wp plugin update contact-form-7, or update from Dashboard > Plugins, and confirm the version reads 6.2.4.1 or higher.
- Search wp-content/uploads for .phar, .php and .phtml files, and for anything with a double extension.
- If you find unexpected executables, treat the site as compromised: rotate the wp-config salts, the database password and any API keys stored on that host.
- Until the update is confirmed on every site you manage, disable file upload fields on publicly reachable forms.
What this means for South African businesses
Almost every South African SME website has a contact form, and Contact Form 7 is the most common way that form gets built, so this is not a niche plugin problem. The attack needs no account and no user action, only a site that accepts an upload.
My judgement is that the real exposure here is not the global install count but the hosting underneath: cheap shared Apache hosting with directory listing left on is exactly what most local SME sites run, and that is the configuration where this ends in code execution rather than a stray file. Verifying the patch actually landed is worth more than reading the advisory.
The primary record is published by the CVE Program and can be read in full at the CVE Program record.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.