Everest Forms CVE-2026-3296: Brief Summary of Unauthenticated PHP Object Injection via Form Entry Metadata

Introduction

An unauthenticated PHP object injection vulnerability in the Everest Forms WordPress plugin allows any internet user to 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 represents a serious risk for the large number of WordPress sites relying 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 survey capabilities. It occupies 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 vulnerability exists in the form entry metadata processing pipeline, specifically 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 field values are processed and stored in the wp_evf_entrymeta database table. The plugin applies WordPress's sanitize_text_field() to the input. Critically, this sanitization 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 remains inert in the database until an administrator navigates to 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 does not include the allowed_classes parameter, which means PHP will instantiate any class available in the runtime environment. This is the core of the vulnerability.

Exploitation Walkthrough

The attack proceeds through the following stages:

1. Reconnaissance: The attacker identifies a WordPress site running Everest Forms version 3.4.3 or earlier with at least one publicly accessible form. Plugin version detection is often trivial through readme.txt or source inspection.

2. Payload Crafting: The attacker constructs a serialized PHP object targeting a known POP (Property Oriented Programming) gadget chain. The WordPress ecosystem, with its extensive plugin landscape, frequently contains classes with exploitable magic methods (__destruct, __wakeup, __toString) that can be chained to achieve file writes, command execution, or other dangerous operations.

3. Payload Delivery: The attacker submits the serialized payload as a value in any form field on the public facing Everest Forms form. No authentication, no special headers, no CSRF token bypass is needed; it is a standard form submission.

4. Sanitization 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 the wp_evf_entrymeta table.

5. Trigger: 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, executing 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. However, PHP serialization format uses characters like O:, s:, {, and } as structural delimiters, none of which are targeted by this sanitization function. The mismatch between the sanitization scope and the threat model is what allows the payload to persist.

The Fix in Version 3.4.4

The vendor addressed the vulnerability by replacing the direct unserialize() call with a custom wrapper function named evf_maybe_unserialize(). The behavioral differences are summarized below:

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 utilized for this specific 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 (which is 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 recurrence of the same vulnerability class, PHP object injection via unsafe deserialization, within roughly eight months suggests a systemic challenge in how the plugin handles serialized data across its codebase. It is worth noting that 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 effort.

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