CVE-2026-103039: Gravity Forms <= 3.1.2 - Unauthenticated PHP Object Injection via Post Custom Field
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::createpost() passing the submitted value to WordPress' unrestricted global maybeunserialize() rather than the plugin's own hardened GFCommon::maybeunserialize(), which was added in 3.1.1 and passes allowedclasses => 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 wppagetemplate meta key, WordPress itself supplies the chain: validatefile() accepts non-scalars, WPTheme::toString() then resolves an attacker-controlled path, and on hosts with a readable PEAR install and registerargcargv enabled this yields remote code execution.
Event History
Frequently Asked Questions
Which sites are exposed to unauthenticated exploitation?
Sites using Gravity Forms versions through 3.1.2 are affected if they have a Post Custom Field with input type set to List and a content template enabled. An attacker does not need an account or user interaction to submit the malicious value.
Is remote code execution possible in every affected installation?
No. Gravity Forms does not contain a PHP object-injection gadget chain itself. Remote code execution may be possible if another installed plugin or theme supplies a suitable chain, or when the field is mapped to _wp_page_template under the described WordPress, PEAR, and register_argc_argv conditions.
What configuration creates the described WordPress-provided remote-code-execution path?
The Post Custom Field must be mapped to the protected _wp_page_template meta key. The described path additionally requires a host with a readable PEAR installation and register_argc_argv enabled.
What should be reviewed while a fix is not available or cannot be applied immediately?
Review Post Custom Fields configured as List fields, especially those with content templates enabled. Prioritize removing or changing mappings to _wp_page_template and assess installed plugins and themes for PHP object-injection gadget chains.