WordPress security changelog
CRITICAL CVE-2026-103039 Received

Gravity Forms: PHP object injection

The Gravity Forms plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1.2 via a Post Custom Field whose input type is List. This is due to GFFormsModel::create_post() passing the submitted value to WordPress' unrestricted global maybe_unserialize() rather than the plugin's own hardened GFCommon::maybe_unserialize(), which was added in 3.1.1 and passes allowed_classes => false precisely to prevent object instantiation. Where the field has a content template enabled, the submitted row reaches that call verbatim. This makes it possible for unauthenticated attackers to inject a PHP object into post meta. No PHP Object Injection gadget chain is present in the plugin itself; however, if a gadget chain is present via an additional plugin or theme, it could allow the attacker to perform actions such as remote code execution. Where the custom field is mapped to the protected _wp_page_template meta key, WordPress itself supplies the chain: validate_file() accepts non-scalars, WP_Theme::__toString() then resolves an attacker-controlled path, and on hosts with a readable PEAR install and register_argc_argv enabled this yields remote code execution. The structured affected range is <= 3.1.2.

CVE / CNA score 9.8 CVSS 3.1 · security@wordfence.com
NVD score Pending NVD has not published its own CVSS assessment.
Component
Gravity Forms
Plugin slug
gravity-forms
Affected
<= 3.1.2
Safe version
See mitigation notes
Published
Oct 30, 2026
Weakness
CWE-502 — Deserialization of Untrusted Data

This CVE was published Oct 30, 2026 and is one of 19 known issues for this plugin.

Update, patch or deactivate.

Official author notes reviewed on 2026-10-30 through version 3.2.1 did not establish an exact fixed release for this CVE. Generic Gravity Forms notes do not identify List/Post Custom Field deserialization. This archive’s uncertainty does not establish that the current release remains vulnerable. Do not deserialize attacker-controlled input into PHP objects; enforce the intended authorization before processing it. Official author notes: https://docs.gravityforms.com/gravityforms-change-log/.

No confirmed safe version is listed. Consider a vendor-supported patch or temporarily restricting the affected functionality while you assess the risk.

Deactivate only when warranted by your risk profile, or when advised by your hosting provider in the limited circumstances where the vulnerability cannot otherwise be mitigated. If you’re unsure which action is appropriate, contact Fused or your hosting provider for guidance.

Technical description

The Gravity Forms plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1.2 via a Post Custom Field whose input type is List. This is due to GFFormsModel::create_post() passing the submitted value to WordPress' unrestricted global maybe_unserialize() rather than the plugin's own hardened GFCommon::maybe_unserialize(), which was added in 3.1.1 and passes allowed_classes => false precisely to prevent object instantiation. Where the field has a content template enabled, the submitted row reaches that call verbatim. This makes it possible for unauthenticated attackers to inject a PHP object into post meta. No PHP Object Injection gadget chain is present in the plugin itself; however, if a gadget chain is present via an additional plugin or theme, it could allow the attacker to perform actions such as remote code execution. Where the custom field is mapped to the protected _wp_page_template meta key, WordPress itself supplies the chain: validate_file() accepts non-scalars, WP_Theme::__toString() then resolves an attacker-controlled path, and on hosts with a readable PEAR install and register_argc_argv enabled this yields remote code execution.

CVE / CNA vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Primary and upstream sources