Public Exploit Code Dropped for Gravity Forms, Checkout Files Upload and IvyForms. Check Whether Your Site Is in the Exposed Setup Before You Panic.
On October 30 and 31, one GitHub account posted proof-of-concept exploit code for three WordPress plugins: Gravity Forms, Checkout Files Upload for WooCommerce, and IvyForms. Fixes are out for the last two. None of the three is in CISA's Known Exploited Vulnerabilities catalog, and we found no confirmed exploitation in the wild. Each bug needs a specific setup to work, so the fastest way to know your risk is to check whether you are in that setup.
Gravity Forms, up to 3.1.2
A CVE record published October 30, assigned by Wordfence, describes unauthenticated PHP object injection through a Post Custom Field. It applies when that field uses the List input type and has a content template enabled. The record says no gadget chain exists in the plugin itself, so turning it into code execution needs a chain from another plugin or theme on the same site. CISA's scoring in the record lists exploitation as none, automatable as yes, and technical impact as total.
The PoC's README gives 3.1.3 as the fixed version. Our search could not confirm that against Gravity Forms' own changelog, so check it there. The README also says the author used no live target to validate it, and the helper that generates the payload is deliberately left out. Treat that as a lower-readiness PoC, not a harmless one.
Checkout Files Upload for WooCommerce, before 2.4.0
A CVE record published October 28 describes unauthenticated arbitrary file upload. When an uploader's Accepted file types setting is blank, the plugin skips file-type validation entirely, and the upload handler is reachable by logged-out visitors. Patchstack confirms 2.4.0 as the fix, rates it CVSS 10 and expects it to be exploited. The CVE record's own CISA fields say exploitation was none when published. Those two views disagree, and we do not know which will age better.
The setup that matters: the plugin's default accepted types are jpg, jpeg and png, so a site is exposed only if an administrator blanked the setting or added a script extension. If a script file does land, the plugin keeps the original extension and stores it under wp-content/uploads/woocommerce_uploads/alg_uploads/checkout_files_upload.
IvyForms, up to 1.5.1
Patchstack lists IvyForms 1.5.1 and earlier as an arbitrary file upload bug of medium priority, CVSS 8.8, fixed in 1.5.2, and classes it as authenticated. That matches the CVSS vector the PoC itself uses, which requires low privileges. The PoC's title calls it unauthenticated, and its README describes a second path when an administrator publishes a form whose upload field allows script extensions. We cannot verify that second path. The README cites CVE-2026-109384, which our search did not confirm, so cite the plugin and version when you write the ticket.
Where a script would land if it worked: wp-content/uploads/ivyforms/entry, and version 1.5.1 does not ship a rule blocking execution there.
What to do
From the reports:
- Update. Gravity Forms to 3.1.3 or later (verify against the vendor), Checkout Files Upload to 2.4.0 or later, IvyForms to 1.5.2 or later.
- Never leave Accepted file types blank on a Checkout Files Upload uploader, and remove script extensions from any IvyForms upload field.
- Review Gravity Forms forms for a Post Custom Field set to the List type with a content template.
Ours, not the researcher's:
- Block script execution under wp-content/uploads at the web server for php, phtml, phar and similar extensions. It defuses every file-upload bug in every plugin, including ones nobody has found yet.
- Look for script files where they would land. List files with script extensions under the two directories named above and anywhere else under wp-content/uploads. Any hit you did not put there is an incident.
- Search your access logs back to October 20 for POST requests to admin-ajax.php with the action name alg_ajax_file_upload, and POST requests to wp-json/ivyforms/v1/form/submission. Most hits will be normal customers and form fillers, so look for uploads that name a script file.
- Check for new administrator accounts and unfamiliar plugins, the usual next move after a webshell.
What our edge saw
We ran our edge telemetry check for the plugin paths named in the READMEs, from October 1. Edge blocks: 41,707 documents scanned, no match. Edge canaries: 26,745 scanned, no match. Origin honeypot, which only sees what got past the edge: 1,431 scanned, no match.
That is a measurement, not a reassurance. Our canaries fire only on paths we trap, and we do not trap these plugins' paths, so a clean result says we saw no probing in the places we can see. It does not say nobody is scanning for them.
What we hold, and what we don't
Nothing for the feed. The reports publish no IP addresses, domains or file hashes, and the PoC repositories are third-party exploit code that we are not linking to or redistributing. We read their READMEs and file lists only and ran nothing.
Limits
The version, severity and fix details come from the three PoC READMEs, the CVE records and Patchstack entries as our search returned them. We did not open the vendors' changelogs or Wordfence's advisories, and we did not reproduce any bug. The fixed-release dates of October 20 and 21 are the PoC author's claims.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.