Everest Forms CVE-2026-5096

Exploitation requires a publicly accessible WordPress form built with Everest Forms version 3.4.4 or earlier that contains at least one upload field type and at least one required non-upload field. The required field must be left empty on submission to trigger form re-rendering - this specific code path is what invokes load_previous_field_value() in class-evf-form-task.php and subsequently calls wp_remote_head() with the unsanitized POST URL. Per the CVSS vector (PR:N), no authentication is required; any anonymous visitor who can access and submit the form can trigger the SSRF. Key limiting factors that reduce practical impact: the attack issues only HTTP HEAD requests, so no response body is returned to the attacker, restricting impact to host reachability inference via status codes rather than content exfiltration. WordPress deployments where no published form includes an upload field, where all upload-enabled forms require user login, or where network egress from the web server is filtered, are not practically exploitable via this vector even without patching.

The CVSS 3.1 base score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N accurately captures an unauthenticated, low-complexity network attack path with limited confidentiality impact. The C:L rating is justified because, while HEAD requests return no response body, successful status codes reveal host reachability - enabling internal network mapping, SSRF-based port scanning of internal services, and probing of cloud instance metadata endpoints (e.g., 169.254.169.254 on AWS/GCP/Azure), which can expose cloud credentials in environments lacking egress filtering. No EPSS data was provided, leaving exploitation probability unquantified; this is a material gap in the risk picture. CISA KEV listing is absent and no public POC code is explicitly identified, indicating no confirmed active mass exploitation at time of analysis. Scope is correctly rated Unchanged given that the attacker receives only HTTP status code information from the server-side HEAD request rather than achieving code execution or accessing a second security authority. The practical risk is highest for WordPress deployments hosted in cloud environments with accessible instance metadata services; a security team managing a fleet of WordPress sites - including smaller municipal or SMB operators - should verify whether network-level egress filtering already neutralizes this pathway before treating the Medium CVSS score as a safe deprioritization signal.

An unauthenticated attacker locates a public WordPress site running Everest Forms 3.4.4 or earlier with a form containing both an upload field and at least one required non-upload field. The attacker submits the form with a crafted internal URL - such as http://169.254.169.254/latest/meta-data/ for AWS instance metadata or an RFC 1918 address targeting an internal service - in the upload field while deliberately leaving the required field blank. The form re-renders, triggering the vulnerable code path; the WordPress server issues an HTTP HEAD request to the attacker-specified URL, and based on the HTTP response code, the attacker infers whether the internal host is reachable from the server's network position, building a map of internal services for follow-on attack planning.