Blog Detail

CVE-2026-84434: Critical Gravity Forms RCE with Public PoC — Patch Now

Unauthenticated attackers can upload executable files through hidden Gravity Forms upload fields, leading to remote code execution. A public PoC exists and CISA added it to KEV. Treat any internet-facing WordPress site running Gravity Forms <= 3.1.0.4 as exposed.

Trusteed Team

Trusteed Editorial

Written On

Sep 22, 2026

TL;DR

CVE-2026-84434 is a critical arbitrary file upload vulnerability in the Gravity Forms plugin for WordPress, affecting all versions up to and including 3.1.0.4. Unauthenticated attackers can upload executable files through a File Upload field whose Visibility is set to "Hidden," leading to remote code execution (RCE). A public proof-of-concept (PoC) is available on GitHub, and CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog on 2026-09-19. If you run an internet-facing WordPress site with Gravity Forms <= 3.1.0.4, assume you are exposed and patch immediately.

What happened

On September 19, 2026, a critical vulnerability in the Gravity Forms WordPress plugin was publicly disclosed and assigned CVE-2026-84434. The flaw resides in the plugin's upload_file function and stems from a mismatch between the field validation pipeline and the file persistence pipeline. When a File Upload field is configured with Visibility set to "Hidden," extension validation is bypassed, and a rejected file's intact upload state is later passed to upload_file() without re-validation. This allows an unauthenticated attacker to upload files that may be executable, resulting in remote code execution.

The vulnerability carries a CVSS 3.1 base score of 9.8 (CRITICAL) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting a network-reachable, no-privilege, no-interaction issue with high confidentiality, integrity, and availability impact. A public PoC repository exists on GitHub, lowering the barrier for opportunistic exploitation. CISA added the CVE to KEV on 2026-09-19, confirming active exploitation in the wild. EPSS currently sits at approximately 0.0276 (85.6th percentile), indicating that while mass scanning is not yet dominant, targeted abuse is likely given the KEV listing and available PoC.

Why it matters

This is not a theoretical risk. The combination of a critical CVSS score, a public PoC, and a KEV listing means attackers are already exploiting this vulnerability. Gravity Forms is widely deployed on lead-generation, e-commerce, and marketing sites, making the pool of potentially exposed targets large. Because exploitation requires only that a publicly accessible form contains a hidden File Upload field, many sites may be vulnerable without realizing it. The impact is severe: full remote code execution under the web server's user account, leading to webshell persistence, data theft, lateral movement, and potential ransomware or defacement.

Technical details

At its core, CVE-2026-84434 is a logic flaw classified as CWE-434 (Unrestricted Upload of File with Dangerous Type), compounded by insufficient input validation (CWE-20) and a state-management weakness where a rejected artifact is not cleared. Gravity Forms processes file uploads in two stages: validation (checking file extensions against an allow-list) and persistence (writing the file to disk). When a File Upload field has Visibility set to "Hidden," the field does not pass through the same extension checks as a visible field. Additionally, when a file is rejected during validation, the plugin does not fully discard the upload state; that intact state can later be handed to upload_file() without a second validation pass.

An attacker can submit a file with a dangerous extension (e.g., .php), have it rejected by one code path, and still have the underlying upload object reach the persistence function. The file is then written to a web-accessible directory, typically under wp-content/uploads/gravity_forms/. If the hosting environment allows execution of PHP files in that directory, the attacker achieves remote code execution.

The prerequisites are narrow but realistic: the target site must run a vulnerable Gravity Forms version, must expose a form containing a File Upload field with Hidden visibility, and that form must be reachable by unauthenticated users. No account, session, or user interaction is required.

Affected versions and exposure

All versions of Gravity Forms up to and including 3.1.0.4 are affected. The vulnerability is reachable by unauthenticated attackers on any publicly accessible form that includes a File Upload field with Visibility set to "Hidden." Sites that do not use hidden file upload fields are not exploitable, but given the plugin's popularity, many sites may inadvertently meet this condition.

To determine exposure, inventory all WordPress installations running Gravity Forms. Check the plugin version and audit forms for hidden File Upload fields. Pay special attention to internet-facing sites, as they are the primary targets. Hosting providers and managed WordPress services should proactively scan their fleets.

Exploitation steps (defensive summary)

Attackers exploit this vulnerability in a straightforward sequence:

Reconnaissance: Identify WordPress sites running Gravity Forms <= 3.1.0.4 using tools like WPScan, Shodan, or by inspecting page source for Gravity Forms indicators (e.g., gform_wrapper CSS classes or gravityforms script handles).
Identify target form: Browse publicly accessible forms and look for one that contains a File Upload field configured with Visibility set to "Hidden." This may require inspecting the rendered HTML or form source for hidden file input elements.
Craft malicious upload request: Prepare an executable file (e.g., a PHP web shell) and craft an HTTP POST request to the form's submission endpoint, targeting the hidden file upload field parameter.
Bypass validation: Submit the crafted request. Because the hidden field bypasses extension validation, the file's upload state passes intact to upload_file() without re-validation, allowing the executable file to be persisted in the server's upload directory.
Locate uploaded file: Determine the upload path (typically within wp-content/uploads/gravity_forms/) by analyzing server responses or using directory enumeration.
Execute payload: Access the uploaded web shell via its URL to achieve remote code execution on the server.

Defenders should treat any observed sequence matching these steps as active exploitation and initiate incident response immediately.

Indicators of compromise

Detecting CVE-2026-84434 exploitation requires monitoring across network, file system, logs, and process telemetry:

Network: Unexpected HTTP POST requests to WordPress form submission endpoints (e.g., wp-admin/admin-ajax.php or Gravity Forms REST endpoints) containing file upload parameters with executable file extensions (e.g., .php, .phtml, .php5, .phar, .shtml). Outbound connections from the web server to unknown external IPs following form submissions.
File System: Presence of PHP files or other executable scripts in wp-content/uploads/gravity_forms/ or subdirectories. Newly created files with web shell signatures (e.g., eval(, base64_decode(, system(, passthru(). Unexpected changes to wp-config.php, .htaccess, or plugin/theme files.
Logs: Web server access logs showing POST requests to Gravity Forms endpoints followed by GET requests to files in the uploads directory, especially requests returning HTTP 200 for script-like paths. WordPress debug or application logs containing validation-rejection messages immediately followed by successful persistence or upload-complete events for the same request.
Process: Unusual child processes spawned by the web server process (e.g., apache2, nginx, php-fpm) such as bash, curl, wget, or python with suspicious arguments.
Other: New administrative users created without a change ticket. Repeated 404/403 responses for script-like filenames in upload directories, which often indicate an attacker probing for a previously dropped webshell.

Mitigation and workarounds

Upgrade Gravity Forms to a version above 3.1.0.4 as soon as a fixed release is available from the vendor. Because the CVE is in CISA KEV, treat the upgrade as emergency maintenance rather than routine patching.

If an immediate upgrade is not possible, apply these compensating controls:

Disable or remove any File Upload fields whose Visibility is set to "Hidden" on publicly accessible forms, or restrict those forms to authenticated users.
Enforce server-side rules that block execution of scripts inside wp-content/uploads/ (e.g., php_admin_flag engine off or equivalent directives in the web server configuration).
Add a WAF rule that rejects multipart uploads with dangerous extensions to Gravity Forms endpoints.
Restrict filesystem permissions so the web server user cannot write outside expected upload directories, and monitor those directories for new files.
Rotate WordPress salts, database credentials, and any API keys stored on the host if you suspect exploitation, and review administrative accounts for unauthorized additions.
Confirm that backups are current and restorable before making changes, so that remediation does not create new availability risk.

Detection and hunting

Proactive hunting can uncover exploitation attempts or successful compromises. Query web server logs for POST requests to Gravity Forms endpoints with multipart bodies containing file extensions not in the site's allow-list. Look for subsequent GET requests to files in upload directories, especially those returning HTTP 200. On the host, search for recently modified files in wp-content/uploads/ and scan for web shell signatures. Monitor for outbound network connections from the web server to unfamiliar IPs. Use EDR to detect unusual child processes spawned by the web server user. Finally, review WordPress user accounts for unauthorized additions and check for changes to core files.

Patch and remediation guidance

Inventory: Identify all WordPress sites running Gravity Forms. Check plugin versions and form configurations.
Prioritize: Patch internet-facing sites first, especially those with hidden File Upload fields on public forms.
Upgrade: Update Gravity Forms to a version newer than 3.1.0.4. If a fixed version is not yet available, apply the workarounds above.
Verify: After patching, confirm the plugin version and re-audit forms to ensure no hidden upload fields remain on public forms.
Monitor: Continue monitoring for indicators of compromise for at least 30 days post-patch, as attackers may have established persistence.
Incident Response: If compromise is suspected, isolate the affected host, preserve evidence, and conduct a thorough investigation. Rotate credentials and rebuild if necessary.

Strategic takeaways

CVE-2026-84434 exemplifies the risk of logic flaws in widely used plugins. The mismatch between validation and persistence pipelines is a common pattern that can bypass security controls. Defenders should adopt a defense-in-depth approach: keep plugins updated, minimize attack surface by restricting public forms, enforce server-side execution controls, and monitor for anomalous file uploads. The presence of a public PoC and KEV listing underscores the need for rapid response. Organizations should integrate this vulnerability into their continuous threat exposure management (CTEM) programs, ensuring that asset inventories include WordPress plugins and that patching SLAs reflect active exploitation.

FAQ

Q: Is CVE-2026-84434 on CISA KEV? A: Yes, CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-19.

Q: What versions of Gravity Forms are affected? A: All versions up to and including 3.1.0.4.

Q: Can an unauthenticated attacker exploit this? A: Yes, if a publicly accessible form contains a File Upload field with Visibility set to "Hidden."

Q: Is there a public PoC? A: Yes, a public proof-of-concept repository exists on GitHub (murrez/CVE-2026-84434).

Q: What is the CVSS score? A: 9.8 (Critical) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Q: How can I mitigate if I cannot patch immediately? A: Disable hidden File Upload fields on public forms, block script execution in upload directories, and deploy WAF rules to reject dangerous file extensions.

Q: What are the signs of exploitation? A: Look for POST requests with executable file extensions to Gravity Forms endpoints, new PHP files in upload directories, and unusual child processes spawned by the web server.

Q: Does this affect all WordPress sites? A: No, only those running vulnerable Gravity Forms versions with a publicly accessible form containing a hidden File Upload field.

Q: What should I do if I suspect compromise? A: Isolate the host, preserve evidence, rotate credentials, and conduct a full incident response investigation. Consider rebuilding the site from a known-good backup.

Q: Where can I find more information? A: Refer to the Wordfence advisory, GitHub advisory, and CISA KEV catalog. Links are provided in the Additional Resources section.