CVE-2026-84434 in Gravity Forms Plugin
Summary
by MITRE • 09/19/2026
The Gravity Forms plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 3.1.0.4 via the upload_file function. This is due to a mismatch between the field validation pipeline and the file persistence pipeline, where hidden file upload fields bypass extension validation and a rejected file's intact upload state is later passed to upload_file() without re-validation. This makes it possible for unauthenticated attackers to upload files that may be executable, which makes remote code execution possible. Exploitation requires the targeted form to contain a File Upload field with its Visibility set to 'Hidden'; the vulnerability is reachable by unauthenticated attackers on any publicly accessible form meeting this condition.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
The Gravity Forms plugin for WordPress contains a critical security flaw identified as an Arbitrary File Upload vulnerability, affecting all versions up through 3.1.0.4. This vulnerability stems from a fundamental architectural inconsistency within the plugin's file handling logic, specifically located in the upload_file function. The core issue arises from a mismatch between two distinct operational pipelines: the field validation pipeline and the file persistence pipeline. In a secure implementation, these processes should be tightly coupled to ensure that any data accepted for storage has undergone rigorous security checks. However, in this vulnerable version, the system fails to enforce consistent validation rules across both stages of processing user input.
The technical mechanism of exploitation relies on hidden form fields rather than visible ones. When a WordPress site utilizes Gravity Forms with a File Upload field configured as Hidden, it is typically intended for internal use or automated processes where end-users do not directly interact with the upload control. Despite this intent, the validation logic that checks file extensions and types is bypassed during the initial submission phase for these hidden fields. Consequently, when a malicious actor submits data containing an executable file extension, such as PHP or ASPX, the system accepts the payload without performing the necessary integrity checks on the file type.
Following the acceptance of the unvalidated upload request, the file remains in an intact uploaded state within the server's temporary storage. The vulnerability is triggered when this pending upload object is subsequently passed to the upload_file function for final persistence and organization into the designated directory structure. Because the initial validation was skipped or bypassed due to the hidden field configuration, the upload_file function proceeds to save the file without re-validating its extension or content type. This lack of secondary verification allows malicious scripts to be written directly to the web-accessible directories associated with the WordPress installation.
The operational impact of this vulnerability is severe, as it enables unauthenticated remote code execution on the targeted server. An attacker does not need valid credentials or any form of authentication to exploit this flaw; they only require access to a publicly accessible page containing a Gravity Form that includes a hidden file upload field. By uploading a web shell or other executable script via this vector, an adversary gains the ability to execute arbitrary commands on the underlying operating system with the privileges of the web server process. This can lead to complete compromise of the WordPress environment, including theft of sensitive data, defacement of the website, and use as a pivot point for further attacks against internal networks.
This vulnerability aligns with CWE-434, which describes Unrestricted Upload of File with Dangerous Type, highlighting the failure to restrict file types that can be uploaded by users. Furthermore, from an offensive security perspective, this exploitation technique maps directly to MITRE ATT&CK Tactic TA0001 and Technique T1505.002, known as Server Side Request Forgery leading to Web Shell Upload or more specifically Data Staged via Unrestricted File Upload followed by Execution. The lack of input validation on file extensions is a classic example of trusting client-side constraints or incomplete server-side checks rather than enforcing strict allow-lists for acceptable file types.
Mitigation strategies must address both the immediate risk and the underlying architectural weakness. Administrators should immediately update Gravity Forms to version 3.1.0.5 or later, where this validation mismatch has been resolved by ensuring that all upload fields, regardless of visibility settings, undergo consistent extension and type verification before persistence. In environments where updating is not immediately feasible, a temporary workaround involves removing any File Upload fields set to Hidden from public-facing forms until the patch can be applied. Additionally, implementing strict file upload restrictions at the web server level, such as configuring Apache or Nginx to deny execution of scripts in WordPress uploads directories, provides an essential layer of defense-in-depth that limits the impact even if a malicious file is successfully uploaded.