Gravity Forms CVE-2026-19513

Remote code execution requires all three conditions simultaneously: (1) a publicly accessible Gravity Forms form with a File Upload field and Multiple Files mode enabled - authenticated-only or non-upload forms are not exploitable by unauthenticated attackers; (2) a web server that does not honor .htaccess directives, specifically NGINX, Caddy, or any FastCGI-based stack where PHP execution in upload directories is not restricted by server configuration; and (3) the Gravity Forms temporary upload directory must be reachable via HTTP. The bundled .htaccess file placed by Gravity Forms during installation and activation blocks PHP execution on Apache and LiteSpeed, making those deployments immune to the RCE path even if the malicious file is written. The secondary XSS path is available on .htaccess-protected deployments but additionally requires a victim user to navigate to the attacker-generated .html URL (PR:N per CVSS but UI:R for this sub-path). Authentication is not required for the upload itself per CVSS PR:N.

The CVSS 8.1 High score (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) correctly captures the zero-authentication requirement and reflects high attack complexity, which is warranted given the dual preconditions: a publicly accessible form with Multiple Files upload enabled AND a non-Apache web server. EPSS data is absent from the provided input and cannot be assessed. The vulnerability is not listed in the CISA KEV catalog, and no POC has been disclosed at time of analysis - these are distinct signals that should not be conflated. Despite the high base score, real-world RCE risk is meaningfully reduced for the majority of WordPress deployments, as Apache and LiteSpeed hosts with the plugin's intact .htaccess are fully protected against PHP execution. NGINX-hosted WordPress installations - a growing but still minority segment - represent the highest-risk population. The XSS path is secondary and gated on victim navigation to the crafted URL. Overall, this is a high-priority patch for NGINX deployments and a moderate-urgency patch for Apache deployments where .htaccess integrity cannot be guaranteed.

An attacker enumerates a target WordPress site running NGINX, identifies a public Gravity Forms form with a File Upload field using Multiple Files mode, and captures a valid form state URL hash by submitting a benign file. They craft a PNG polyglot containing a PHP web shell, replay the captured hash as the chunk continuation token, and specify a .php destination filename in the upload request. Once the file lands in the unguarded temporary directory, the attacker issues a GET request to it, triggering PHP execution and obtaining interactive shell access to the web server process. No confirmed public exploit code exists at time of analysis, though the individual techniques (polyglot construction, chunk hash replay) are independently documented in offensive security literature.