CVE-2023-6220 is a High severity (CVSS 8.1) arbitrary file upload flaw in the Piotnet Forms plugin for WordPress, in versions up to and including 1.0.28. Unauthenticated attackers could upload files that may lead to remote code execution. Update to a later release and review your uploads folder.
What's affected
The NVD description gives the range directly.
- Affected: Piotnet Forms versions up to and including 1.0.28.
- Fixed: the record does not name a fixed version. Its references include the plugin's source at tag 1.0.29, which suggests 1.0.29 is the first release with changed code in the vulnerable function. I could not retrieve the plugin repository or the Wordfence entry, so confirm the fixed version on the plugin's page or in the Wordfence entry linked in the record.
- Severity: 8.1 High. The vulnerable function is named in the description as
piotnetforms_ajax_form_builder, and the issue is insufficient file type validation.
The record lists no CVSS metric beyond the score in this post, and the kev flag is false.
How to check if you're exposed
Use WP-CLI on each site, or the Plugins page in the dashboard.
wp plugin list --fields=name,status,version | grep piotnetforms
wp plugin update piotnetforms
Next, look for files that should not be in the uploads directory. Uploaded content normally consists of images and documents. Executable server files in that tree deserve a closer look.
find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.phar" )
Review web server logs for POST requests to the WordPress AJAX endpoint around the dates the plugin was exposed, and compare them with form activity you expect. For agencies managing many sites, a plugin inventory across the fleet is the only practical way to find every install.
What to do now
- Update Piotnet Forms to the latest release, and confirm the version is above 1.0.28.
- If you do not use the plugin, deactivate and delete it. A deactivated plugin still sits on disk.
- Scan wp-content/uploads and the rest of the web root for server side script files that you did not add, and remove or quarantine anything suspicious after taking a copy.
- If you find an unexpected script, treat the site as compromised: rotate WordPress salts, database and admin credentials, and restore from a clean backup.
- Block execution of PHP in the uploads directory at the web server level as defense in depth.
Why it matters
The weakness is CWE-434, unrestricted upload of a file with a dangerous type. A form builder has to accept files, so it needs strict checks on type and extension on the server. The advisory text says the check in this function was insufficient, and the endpoint was reachable without logging in.
Upload bugs rate high because the step after upload is easy: if an attacker can place a script on a server that runs PHP, a web request can run it. The record says this "may make remote code execution possible", which is accurate wording. It depends on the upload landing in a place where scripts execute. Server hardening that disables script execution in uploads can break that chain even when the plugin is unpatched.
Quick check
Do I need to be logged in to be attacked?
No. The description says unauthenticated attackers can upload files, so a public form endpoint is enough.
Is deleting the plugin better than updating?
If you do not use it, yes. Removing code you do not need removes the risk for good.
Sources
- Piotnet Forms source at tag 1.0.26
- Piotnet Forms source at tag 1.0.29
- Wordfence entry (listed in the record, not readable when fetched)
Last reviewed: 19 October 2026.
