SURIQ
A flaw in WPForms Pro, the paid edition of one of the most widely installed form builders for WordPress, lets an attacker with no account upload a file to the server and, from there, run their own code on the site. It is tracked as CVE-2026-10818, rated 8.1 out of 10, and it affects WPForms Pro 1.10.1.1 along with every earlier release. If you run the plugin, update to 1.10.2 or newer today, then read the hunt steps below, because a patch alone does not tell you whether someone already walked through the door.
What the flaw actually is
WPForms Pro accepts large file uploads by splitting them into chunks and reassembling the pieces on the server. The check that decides whether the finished file is an allowed type runs inside a routine named ajax_chunk_upload_finalize. The problem, per the Wordfence advisory that assigned the identifier, is one of ordering. The plugin writes the reassembled file to disk first and validates its type second. When the type check fails, the plugin rejects the upload but leaves that file on disk instead of removing it.
That gap is the whole bug. A rejected upload is supposed to mean nothing happened. Here it means the file is already written. An unauthenticated visitor can push up a file the server will treat as executable, such as a PHP script, and it stays on disk even though the plugin returns an error. On a PHP application like WordPress, a script an attacker can reach in the browser is code the attacker can run. That is why the record classifies it as an unauthenticated file upload that ends in code execution.
Why high attack complexity is thin comfort
The score is 8.1 rather than a maximum 9.8 because the severity rating marks attack complexity as high. In practice that usually means an attacker has to satisfy a timing or path condition to reach the written file, not that the attack resists automation. WordPress form plugins with large install bases are exactly the targets that get scripted fast. The same file-write-to-takeover shape showed up last month in another WordPress form plugin, in a Joomla upload flaw that reached the exploited list five times, and in a mass campaign that turned unpatched CMS plugins into webshells. What is complex today tends to become a line in a scanner within days of a public advisory. Read the high-complexity rating as a reason it may take a little longer to see hits, not a reason to wait.
Patching closes the hole. It does not evict what is already there.
This is the detail most coverage will skip. Because a failed upload leaves its file on disk, the vulnerable behavior has been quietly creating artifacts for anyone who tried it, rejected or not. Updating the plugin stops new writes. It does nothing about a script that was planted while the site was still on 1.10.1.1 or earlier. If your WPForms Pro site was reachable from the internet before you patched, assume the upload path was probed and verify it, do not hope.
WordPress stores uploads under wp-content/uploads, and WPForms keeps its own subdirectory there. Look for files that do not belong: anything with a .php or other executable extension anywhere in the uploads tree, files with recent modification times you cannot account for, and stray files in the plugin's temporary chunk directory. In your web server access logs, hunt for POST requests to the WordPress admin-ajax.php endpoint carrying the WPForms chunked-upload action from clients that never authenticated. A run of those from one address, especially followed by a GET to a fresh file under uploads, is the sequence that matters.
What to do now
- Update WPForms Pro to 1.10.2 or later. Wordfence marks 1.10.1.1 and every release before it as vulnerable, and the fix arrived in the version that followed. Current branches are further along still, so take the latest version.
- Block script execution in the uploads directory. If your stack allows it, deny PHP execution under
wp-content/uploadsat the web server. That turns a planted script into an inert file even if one slipped through before you patched. - Hunt before you trust the patch. Inspect the uploads tree and access logs as described above. If you find an unexplained script, treat the site as compromised and work it as an incident rather than quietly deleting the file.
- Watch the endpoint going forward. Unauthenticated POSTs to the WPForms chunked-upload handler are worth an alert, and file-integrity monitoring on the uploads directory will catch a new executable the moment it appears.
The fix here is small and the update is easy. The harder question is whether the window before you patched was quiet, and the only way to answer that is to look.