Advisory · CVE-2026-103039
Unauthenticated PHP object injection in Gravity Forms can lead to remote code execution
Gravity Forms for WordPress, in versions up to and including 3.1.2, lets an unauthenticated attacker inject a PHP object through a Post Custom Field, which can lead to remote code execution where a gadget chain is available. Rated critical at CVSS 3.1 9.8.
- Vendor
- RocketGenius
- Product
- Gravity Forms
- Identifier / CWE
- CVE-2026-103039
CWE-502 - Action timing
- Immediate
Explain it like I’m five
A form on a site lets a visitor hand the plugin a sealed package that the plugin opens without checking what is inside. If another plugin or theme on the site knows how to use that package, the visitor can get the server to run their code.
- 01Public form submitted
An unauthenticated attacker submits a form that includes a Post Custom Field whose input type is List, with a content template enabled.
- 02Value passed to unserialize
GFFormsModel::create_post() passes the submitted value to the unrestricted global maybe_unserialize() instead of the hardened helper that blocks object creation.
- 03Object injected into post meta
The attacker-controlled serialized value is injected as a PHP object into post meta.
- 04Gadget chain fires
Where a gadget chain is present in another plugin or theme, or where the field is mapped to the protected _wp_page_template key, the injected object can be turned into code execution.
- 05Site compromise
The attacker gains the ability to run code on the server and take over the site.
What happened
Wordfence disclosed CVE-2026-103039, published in NVD on October 30, 2026 and rated critical at CVSS 3.1 9.8: the Gravity Forms plugin for WordPress is vulnerable to PHP object injection (CWE-502) in all versions up to, and including, 3.1.2, via a Post Custom Field whose input type is List. GFFormsModel::create_post() passes the submitted value to the unrestricted global maybe_unserialize(), rather than the plugin hardened GFCommon::maybe_unserialize() added in 3.1.1, which passes allowed_classes as false to prevent object instantiation. Where the field has a content template enabled, the submitted row reaches that call verbatim, so an unauthenticated attacker can inject a PHP object into post meta.
No PHP object injection gadget chain is present in Gravity Forms itself, so code execution depends on a chain in an additional plugin or theme. The record describes one chain WordPress itself supplies: where the custom field is mapped to the protected _wp_page_template meta key, validate_file() accepts non-scalars, WP_Theme::__toString() resolves an attacker-controlled path, and on hosts with a readable PEAR install and register_argc_argv enabled this yields remote code execution. The affected range in the record ends at 3.1.2, so sites should update to Gravity Forms 3.1.3 or later. Gravity Forms is widely deployed, with over one million active installations reported.
What to do
- Inventory WordPress sites running Gravity Forms and note the version of each, including staging and client sites.
- Update Gravity Forms to version 3.1.3 or later on every site running 3.1.2 or earlier, and verify the deployed version afterwards.
- Check forms that use Post Custom Fields with List input and content templates, and review post meta for unexpected serialized values.
- Review administrator accounts, installed plugins and themes, and recent file changes for signs of a gadget chain having been used.
- If any unexpected object injection or takeover indicator is found, reset administrator passwords, rotate WordPress salts and any credentials reachable from the site, and scan the site for added files or content.
Management note
This is a 9.8 that needs no login and targets one of the most widely used form builders on WordPress. The code execution step needs a gadget chain elsewhere on the site, but on a typical site with many plugins and themes that is a condition to assume, not a comfort. Treat the update as urgent on any public-facing form.