Unauthenticated PHP object injection disclosed in Everest Forms

TL;DR — A critical unsafe unserialize() path in the everest-forms WordPress plugin lets unauthenticated attackers inject serialized objects via public forms, triggering object injection when an admin views entries.

What happened

Everest Forms is a WordPress form builder plugin used to collect and manage website form submissions (contact forms, payment forms, quizzes, and surveys).

Wordfence disclosed CVE-2026-3296 as a critical PHP Object Injection vulnerability caused by unsafe deserialization of stored form-entry metadata. The report states that html-admin-page-entries-view.php calls PHP’s native unserialize() on stored entry meta values without passing the allowed_classes parameter. Attackers can inject a serialized PHP object payload through any public Everest Forms form field; the payload survives sanitize_text_field() and is stored in the wp_evf_entrymeta database table. When an administrator views entries (or an individual entry), the unsafe unserialize() processes the stored data without class restrictions.

This is a high-risk class because it sits on a common operational workflow (reviewing form submissions) and places attacker-controlled data on a deserialization boundary.

Who is impacted

• WordPress sites running Everest Forms with versions <= 3.4.3.
• Sites exposing any public-facing Everest Forms form field to untrusted users (the injection happens via form submission).
• Environments where administrators review form entries in the WordPress admin UI (the vulnerable unserialize() is triggered when viewing entries).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Remediation Update to version 3.4.4, or a newer patched version"

• Inventory where everest-forms is deployed (sites, container images, golden AMIs, and WordPress build artifacts) and prioritize internet-facing instances.
• Treat this as a potentially security-boundary issue and triage exposure:
  • review access and audit logs around form submissions and admin entry-view activity
  • restrict admin dashboard access (network allowlists/VPN) and limit who can access form-entry pages until patched
  • if you use WAF rules for WordPress, consider temporarily tightening controls on high-risk payload patterns in form submissions while patch rollout is in progress