CVE-2026-5096 in Everest Forms Plugin
Summary
by MITRE • 08/28/2026
The Everest Forms plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.4.4. This is due to the `load_previous_field_value()` method in `class-evf-form-task.php` accepting arbitrary URL values from `$_POST` data for upload fields without domain restriction, which are then passed to `wp_remote_head()` in the `get_local_file_size()` method of `class-evf-form-fields-upload.php`. This makes it possible for unauthenticated attackers to force the WordPress server to make outbound HTTP HEAD requests to arbitrary URLs by submitting a form with an upload field containing a malicious URL while leaving a required field empty to trigger form re-rendering.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Everest Forms plugin, a widely utilized tool for creating and managing forms within the WordPress ecosystem, has been identified as susceptible to Server-Side Request Forgery vulnerabilities across all versions up through 3.4.4. This security flaw stems from inadequate input validation mechanisms embedded in the core logic of the form processing pipeline. Specifically, the vulnerability resides in how the plugin handles file upload fields during form submission and subsequent re-rendering processes. The lack of strict domain restrictions on URLs provided by users allows malicious actors to manipulate server-side behavior, leading to potential data exfiltration or internal network reconnaissance depending on the hosting environment's configuration.
The technical root cause is located within the `load_previous_field_value()` method found in the `class-evf-form-task.php` file. When a user submits a form containing an upload field with a URL value and leaves another required field empty, the system triggers a re-rendering of the form to display validation errors. During this process, the plugin attempts to load previous values for persistence purposes. The code accepts arbitrary URL strings from the `$_POST` superglobal without verifying that these URLs point to trusted or expected domains. This unchecked acceptance is critical because it allows an attacker to inject external URIs into a context where they are processed by internal WordPress functions rather than being sanitized or rejected outright.
Once the malicious URL is accepted, it is passed as an argument to the `get_local_file_size()` method in `class-evf-form-fields-upload.php`. This function utilizes the native WordPress HTTP API function `wp_remote_head()` to determine the size of the file associated with the provided URL. The `wp_remote_head` function performs an actual outbound HTTP HEAD request to the specified destination. Because there are no restrictions on the target domain, this mechanism effectively turns the vulnerable WordPress instance into a proxy for making requests to arbitrary external or internal endpoints. An unauthenticated attacker can exploit this by crafting a specific form submission payload that includes a malicious URL in the upload field and an empty required field to force the execution path through these vulnerable methods.
The operational impact of this vulnerability is significant, particularly regarding information disclosure and potential pivoting within protected networks. By forcing the server to make outbound requests, attackers can probe internal services such as database management interfaces, administrative panels, or cloud metadata endpoints that are not exposed to the public internet but are accessible from the web server's network interface. This capability aligns with the ATT&CK technique of Server-Side Request Forgery (T1557), which describes how adversaries use a compromised system to make requests on its behalf to access internal resources. Furthermore, this flaw maps directly to CWE-918, which addresses Server-Side Request Forgery flaws where web applications accept user-supplied URLs and process them without proper validation, leading to unauthorized access or data leakage.
Mitigation strategies must focus on immediate patching and enhanced input validation. Administrators should upgrade the Everest Forms plugin to version 3.4.5 or later, where these vulnerabilities have been addressed by implementing strict domain allowlists for URL inputs in upload fields. In cases where upgrading is not immediately feasible, temporary mitigations include restricting outbound HTTP requests from the web server using firewall rules or security groups that limit access to only necessary external services. Additionally, configuring WordPress to disable remote lookups via `WP_HTTP_BLOCK_EXTERNAL` can provide a layer of defense against SSRF attacks by preventing functions like `wp_remote_head()` from making any external connections unless explicitly whitelisted. Regular auditing of form handling logic and enforcing strict type checking on all user-supplied inputs are essential practices for maintaining the integrity of WordPress-based applications.