Introduction
An unauthenticated PHP object injection vulnerability in the Everest Forms WordPress plugin lets any internet user plant a serialized PHP payload through a public form, where it sits in the database waiting to detonate when an administrator views form entries. With a CVSS score of 9.8 and no authentication required, CVE-2026-3296 is a serious risk for the many WordPress sites that rely on this plugin for contact forms, surveys, and payment forms.
Everest Forms is a popular WordPress form builder plugin developed by WPEverest (a subsidiary of ThemeGrill), based in Kathmandu, Nepal. The plugin has over 100,000 active installations and provides drag-and-drop form building, payment integration, and surveys. It holds a significant share of the WordPress form plugin ecosystem, alongside alternatives like WPForms and Gravity Forms.
Technical Information
The root cause of CVE-2026-3296 is a classic CWE-502 (Deserialization of Untrusted Data) issue. The flaw is in the form entry metadata pipeline, in how the plugin stores and later retrieves user-submitted form data.
Data Flow: Submission to Storage
When a user submits a form built with Everest Forms, the plugin processes the field values and stores them in the wp_evf_entrymeta database table. It applies WordPress's sanitize_text_field() to the input, but that function does not strip PHP serialization control characters. A crafted serialized string such as O:8:"SomeClass":1:{s:4:"prop";s:5:"value";} passes through sanitize_text_field() intact and is written to the database.
Data Flow: Storage to Deserialization
The payload stays inert in the database until an administrator opens the Everest Forms entries page in the WordPress dashboard. At that point, html-admin-page-entries-view.php retrieves the stored metadata and checks whether it is serialized. If it is, the plugin calls PHP's native unserialize() directly:
if ( is_serialized( $meta_value ) ) { $raw_meta_val = unserialize( $meta_value ); // phpcs:ignore WordPress.PHP.DiscouragedPHPFunctions.serialize_unserialize
The unserialize() call omits the allowed_classes parameter, so PHP will instantiate any class available in the runtime environment. That omission is the core of the vulnerability.
Exploitation Walkthrough
The attack runs in five stages:
-
The attacker identifies a WordPress site running Everest Forms version 3.4.3 or earlier with at least one publicly accessible form. Detecting the plugin version is often trivial, through readme.txt or by inspecting the source.
-
The attacker builds a serialized PHP object targeting a known POP (Property Oriented Programming) gadget chain. With so many plugins in circulation, the WordPress ecosystem frequently contains classes with exploitable magic methods (
__destruct,__wakeup,__toString) that can be chained into file writes, command execution, or other dangerous operations. -
The attacker submits the serialized payload as the value of any field on the public-facing Everest Forms form. This is a standard form submission, and it needs no authentication, no special headers, and no CSRF token bypass.
-
The plugin runs
sanitize_text_field()on the submitted value. Because this function targets HTML entities, tags, and whitespace rather than serialization syntax, the payload survives intact and is stored in thewp_evf_entrymetatable. -
When any administrator views the form entries list or opens an individual entry in the WordPress admin panel, the plugin retrieves the stored metadata and passes it to the unrestricted
unserialize()call. PHP instantiates the objects described in the serialized data and executes the gadget chain in the context of the administrator's authenticated session.
Why sanitize_text_field() Is Insufficient
WordPress's sanitize_text_field() is designed to clean strings for safe display. It strips HTML tags, removes extra whitespace, and encodes certain special characters. PHP serialization format, however, uses characters like O:, s:, {, and } as structural delimiters, and the function targets none of them. The payload persists because the sanitization scope does not match the threat model.
The Fix in Version 3.4.4
The vendor replaced the direct unserialize() call with a custom wrapper function named evf_maybe_unserialize(). The table below summarizes how the behavior changed:
| Component | Version 3.4.3 Behavior | Version 3.4.4 Behavior | Security Impact |
|---|---|---|---|
| Entry View Processing | Uses native unserialize() directly on $meta_value | Uses evf_maybe_unserialize() on $meta_value | Prevents arbitrary object instantiation during admin viewing |
| Deserialization Wrapper | Not used for this data path | Implements allowed_classes => false for PHP 7.1 and above | Blocks class loading during deserialization |
| Legacy PHP Support | Executes deserialization normally | Blocks unserialize() attempts entirely on PHP versions older than 7.1 | Prevents exploitation on outdated server environments |
WordPress core itself has an open Trac ticket (#37757) recommending that maybe_unserialize pass allowed_classes to prevent exactly this class of vulnerability.
Affected Systems and Versions
All versions of the Everest Forms WordPress plugin up to and including version 3.4.3 are affected. The vulnerability is present in any WordPress installation where:
- Everest Forms version 3.4.3 or earlier is installed and active
- At least one form is publicly accessible (the default use case for a form builder plugin)
- An administrator periodically views form entries through the WordPress admin panel
The fix is available in version 3.4.4.
Vendor Security History
This is not the first PHP object injection vulnerability in Everest Forms. In August 2025, Patchstack reported a critical PHP object injection vulnerability affecting Everest Forms version 3.2.2 and below, which impacted over 100,000 sites. That earlier vulnerability also involved the evf_maybe_unserialize wrapper in certain environments. The same vulnerability class, PHP object injection via unsafe deserialization, has recurred within roughly eight months, which suggests a systemic problem in how the plugin handles serialized data across its codebase. The fix for CVE-2026-3296 extends the same evf_maybe_unserialize() wrapper to a code path that was apparently missed in the earlier remediation.
References
- NVD Entry for CVE-2026-3296
- Wordfence Threat Intelligence Advisory
- Wordfence Detailed Vulnerability Page
- Vulnerable Code: html-admin-page-entries-view.php (v3.4.3)
- Vulnerable Code: evf-core-functions.php (v3.4.3)
- Patched Code: html-admin-page-entries-view.php (v3.4.4)
- Changeset: v3.4.3 to v3.4.4
- Changeset: readme.txt diff
- Trunk Code: html-admin-page-entries-view.php
- WordPress Core Trac #37757: Add allowed_classes to maybe_unserialize
- Patchstack: Critical Vulnerability in Everest Forms (August 2025)
- Everest Forms on WordPress.org
