CVE-2026-87796: Unauthenticated Arbitrary File Upload in Multi Uploader for Gravity Forms
TL;DR - CVE-2026-87796 is a critical unauthenticated arbitrary file-upload flaw in Multi Uploader for Gravity Forms through version 1.1.9. - Disable or remove
gf-multi-uploader; no fixed version is identified. - No verified public PoC or confirmed in-the-wild exploitation is known, but possible remote code execution makes prompt action necessary.
Vulnerability at a Glance
CVE-2026-87796 affects the WordPress plugin Multi Uploader for Gravity Forms, identified by the plugin slug gf-multi-uploader. NVD describes the vulnerability as an unauthenticated arbitrary file-upload issue in the plugin’s move_file function and chunked-upload handling.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-87796 |
| CVSS base score | 9.8 Critical |
| CVSS vector | Not returned in the NVD record reviewed |
| Attack vector | Network-based HTTP request, according to the unauthenticated plugin vulnerability description |
| Authentication required | No |
| Affected versions | All versions through and including 1.1.9 |
| Fixed version | None identified |
| Patch available | No confirmed fixed release |
| Potential impact | Arbitrary file upload and possible remote code execution |
| CISA KEV status | Not listed |
The absence of a fixed release is especially important operationally. The WordPress.org listing states that the plugin was closed on September 11, 2026, pending a full review. Administrators should not interpret the currently listed version, 1.1.9, as safe or assume that an upgrade path exists.
What Is This Vulnerability?
The vulnerability is caused by insufficient file-type validation during chunked upload processing. NVD identifies the vulnerable operation as the plugin’s move_file function, which handles moving an uploaded file into its destination after upload processing. In a secure implementation, the server must validate the final file type and name rather than trusting upload metadata or an intermediate chunk filename.
Chunked uploads divide a file into multiple pieces before reassembling it on the server. If validation is applied only to individual chunks, to client-controlled metadata, or before the final file is reconstructed, an attacker may be able to submit content that bypasses the intended restrictions. The resulting file could be written to a server-accessible location. Whether that file becomes executable depends on the web-server configuration, PHP handler behavior, filesystem permissions, and the final destination.
The NVD description states that exploitation is possible without authentication and may enable remote code execution. The available research identifies related source locations in GFMUAddon.class.php, GFMUHandlePluploader.class.php, and GFMU_FileUploader.php. The exact vulnerable code and any remediation diff could not be independently verified because some referenced source requests returned HTTP 403 during review.
Who Is Affected?
Affected systems are WordPress installations running Multi Uploader for Gravity Forms, plugin slug gf-multi-uploader, in all versions up to and including 1.1.9. The WordPress.org listing identifies the developer as sh1zen and lists version 1.1.9 as the available product version at the time of the review.
The exposure is not limited to sites where an administrator recently configured a form. Any reachable installation retaining the vulnerable plugin may be at risk if an attacker can reach the affected upload-handling code. Internet-facing WordPress sites should therefore be treated as exposed unless the plugin has been disabled or removed and access to its upload paths has been blocked.
| Environment | Assessment |
|---|---|
gf-multi-uploader 1.1.9 |
Affected |
gf-multi-uploader versions earlier than 1.1.9 |
Affected |
| Sites with the plugin installed but inactive | Lower exposure, but remove it if unnecessary and verify no residual files or routes remain |
| Sites without the plugin | Not affected by this specific component |
| A version newer than 1.1.9 | No such fixed version was identified in the reviewed sources; do not assume it is available or safe |
CVSS Score Breakdown
NVD reports a CVSS base score of 9.8, classified as Critical. However, the NVD API response reviewed for this article did not include a CVSS vector string. Consequently, the individual official metric selections cannot be confirmed from the available record.
The score is consistent with a vulnerability that is remotely reachable, requires no authentication, and can have severe confidentiality, integrity, and availability consequences. The technical description supports the following practical interpretation, but these should not be treated as the authoritative NVD vector:
| Practical factor | Assessment |
|---|---|
| Network reachability | The issue is described as exploitable through the plugin’s web upload functionality |
| Attack complexity | The reported severity is consistent with relatively low exploitation complexity, although the exact CVSS metric is unavailable |
| Privileges required | None, according to the NVD description |
| User interaction | No victim interaction is indicated in the available description |
| Confidentiality impact | Potentially high if uploaded code permits access to WordPress data or server secrets |
| Integrity impact | Potentially high if an attacker writes executable files or modifies site content |
| Availability impact | Potentially high if the server or WordPress installation is altered or disrupted |
Defenders should use 9.8 for prioritization while preserving the uncertainty around the missing vector. The score does not establish that every installation permits code execution. Execution depends on where the file is stored and how the server handles that location. It does establish that unauthenticated arbitrary file writing in an internet-facing WordPress plugin warrants urgent containment.
Exploitation Status
No verified public proof-of-concept repository, exploit module, or GitHub PoC was identified in the sources reviewed. The github_mentions value in this article is zero based on the available research, not a guarantee that no private or newly published exploit exists.
CVE-2026-87796 is not listed in the CISA Known Exploited Vulnerabilities catalog. No confirmed in-the-wild exploitation was identified, and there is no CISA date-added deadline, required action, or ransomware-campaign designation for this CVE. This is a statement about available confirmation, not proof of safety. The CVE was published on September 17, 2026, and exploitation reporting may lag disclosure.
Security teams should act as though exploitation is plausible despite the absence of a confirmed campaign. Unauthenticated upload vulnerabilities are attractive because attackers can scan for plugin presence and test upload behavior without first obtaining WordPress credentials. Prioritize exposed sites, especially those with PHP execution enabled in upload-related directories.
How to Detect It
Detection should combine plugin inventory, web-server telemetry, WordPress logs, and filesystem monitoring. First identify installations with the vulnerable plugin and verify the installed version from WordPress administration, WP-CLI, or the plugin directory. A version at or below 1.1.9 should be considered exposed until the plugin is removed or a trustworthy fixed release is published.
Investigate requests associated with upload handling, chunk assembly, file moves, and newly created files in WordPress upload directories. Because the precise endpoint and request parameter names were not confirmed in the reviewed sources, avoid relying on a single hard-coded URL. Look for anomalous POST requests followed by access to newly created files, especially PHP, CGI, or other server-executable extensions.
Apply a zero-trust approach to network and application access during the investigation: do not assume that an internal source, authenticated session, or previously trusted host is safe without corroborating logs and endpoint evidence.
Technical Notes
Example inventory and log searches:
# List the plugin and installed version with WP-CLI
wp plugin get gf-multi-uploader --fields=name,status,version
# Search common web logs for the plugin slug and upload-related requests
grep -Ei 'gf-multi-uploader|GFMU|upload|chunk|move_file' \
/var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null
# Find recently created PHP files under the WordPress uploads directory
find /var/www/html/wp-content/uploads \
-type f -iname '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\\n'
A useful investigation pattern is a sequence such as:
POST /<plugin-or-upload-endpoint> ... 2xx
POST /<plugin-or-upload-endpoint> ... chunk ...
GET /wp-content/uploads/<unexpected-name>.php ... 200
The literal endpoint is intentionally unspecified because it was not confirmed from the available source review. A single upload request is not proof of compromise. Correlate timestamps, source IPs, response codes, user agents, uploaded filenames, and process activity. Also search for PHP files created in wp-content/uploads, temporary directories, and other plugin-managed locations. If executable files are found, preserve them for analysis before deleting or altering them.
Mitigation and Patching
No fixed version was identified in the NVD record or the reviewed vendor-facing sources. The WordPress.org listing reports that the plugin was closed on September 11, 2026, pending a full review. Therefore, the recommended action is to disable and remove gf-multi-uploader rather than wait for an assumed update.
For sites that cannot immediately remove the plugin, restrict access to the affected upload functionality at the web-application firewall or reverse proxy, require authentication where operationally possible, and prevent script execution in upload directories. These controls are compensating measures, not a substitute for removal. Review whether Gravity Forms workflows can operate without the add-on and test the replacement before re-enabling any upload functionality.
Technical Notes
Use WP-CLI during a controlled maintenance window:
# Confirm the installed plugin and version
wp plugin get gf-multi-uploader --fields=name,status,version
# Disable the vulnerable plugin
wp plugin deactivate gf-multi-uploader
# Remove it after preserving any required configuration or evidence
wp plugin delete gf-multi-uploader
If WP-CLI is unavailable, deactivate the plugin through the WordPress administrator interface or rename its directory under wp-content/plugins/ during incident containment. Before deletion, collect relevant logs and preserve suspicious files if compromise is suspected.
As an additional control, configure the web server so PHP cannot execute under the uploads directory. A representative Apache configuration is:
<Directory "/var/www/html/wp-content/uploads">
<FilesMatch "\\.(php|phtml|php[0-9]*)$">
Require all denied
</FilesMatch>
</Directory>
Validate the configuration for the local Apache version and deployment model before applying it. Nginx deployments should likewise ensure that requests for PHP files beneath wp-content/uploads are denied or are not passed to PHP-FPM.
If compromise is suspected, rotate WordPress administrator, hosting, database, SSH, and API credentials. Use unique credentials stored in a reputable password manager such as Try 1Password →. Also review authentication logs and signs of lateral movement, including activity associated with pass-the-hash attacks.
References
The primary vulnerability record is the NVD entry for CVE-2026-87796. It identifies the affected plugin, version range through 1.1.9, unauthenticated arbitrary file upload behavior, the move_file operation, and insufficient validation during chunked uploads.
The following source references were associated with the NVD record:
- WordPress.org: Multi Uploader for Gravity Forms
- Plugin source:
GFMUAddon.class.php, version 1.1.9 - Plugin source:
GFMUHandlePluploader.class.php, version 1.1.9 - Plugin source:
GFMU_FileUploader.php, version 1.1.9 - Plugin source:
GFMU_FileUploader.php, version 1.1.9 - Plugin source:
GFMU_FileUploader.php, version 1.1.9 - CISA Known Exploited Vulnerabilities Catalog
Some source references returned HTTP 403 during review, so the exact vulnerable statements and any patch diff were not independently confirmed. The CISA catalog lookup did not list CVE-2026-87796 as of the assessment date.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.