CVE-2026-103039: Gravity Forms, 9.8 PHP Object Injection
Unauthenticated PHP object injection in Gravity Forms through 3.1.2, rated 9.8. Hotel microsites are exposed. Fix 3.1.3, plus a forms and metadata audit.
Who is affected
- Gravity Forms for WordPress, all versions through 3.1.2
- Forms that create posts via a List-type custom field (quote requests, event and group bookings)
- Hotel microsites running contact, wedding, group or spa inquiry forms on Gravity Forms
How to fix
Update Gravity Forms to version 3.1.3 or later, released in early October; it is the only fix available. Then review every form that creates posts through a List-type custom field with a content template enabled, the configuration that makes the vulnerable path reachable. Search post metadata and page content for injection traces predating the patch, and check for unexpected administrator accounts or files, the sign that a gadget chain supplied by another plugin or theme was put to use.
What happened
Wordfence, acting as the CVE Numbering Authority for this flaw, disclosed on October 29, 2026 a PHP object injection in Gravity Forms rated 9.8 on CVSS 3.1. The root cause is precisely documented: GFFormsModel::create_post() hands the submitted value of a List-type custom field to WordPress' global maybe_unserialize() with no class restrictions, instead of the plugin's own hardened GFCommon::maybe_unserialize() added in 3.1.1. An unauthenticated visitor can therefore lodge a PHP object into a post's metadata. Every version through 3.1.2 is affected; the 3.1.3 fix shipped in early October without the vendor's release post naming the CVE.
Why it matters for a hotel
Gravity Forms powers a large share of hotel microsites: quote requests, wedding and group inquiries, spa or restaurant reservations. The plugin contains no gadget chain of its own, so an injected object does nothing on its own; but when another plugin or the site's theme supplies one, or on hosts that leave certain options open (readable PEAR install, register_argc_argv enabled), the injection becomes remote code execution. It is the same weakness family as the recent php2shell wave: deserializing visitor data without a guard, on public sites that nobody patches.
Who is affected
Gravity Forms all versions through 3.1.2, with full exposure on sites that contain a form creating posts via a List-type custom field with a content template enabled. Neither setting is visible from outside: the administrator has to check them inside the plugin. As of this writing, CISA reports no confirmed exploitation; one independent tracker lists attempted exploitation from October 30, a signal to treat as acceleration rather than proof.
How to fix
- Update Gravity Forms to 3.1.3 or later, then confirm the exact version number in the plugin interface.
- Inventory every form that creates posts through a List-type custom field, and disable the content template where the business need is questionable.
- Audit post metadata and pages created since late September: unexpected serialized content, small unexplained edits.
- Look for wider exploitation signs: new administrator accounts, files dropped in wp-content, unknown scheduled tasks. If in doubt, treat the site as compromised and restore from a known-clean backup.
- Use the visit to inventory the microsite's other plugins and themes, and record each one's update policy.
Context
The flaw lands in a bad week for WordPress forms and themes: a batch of unauthenticated object-injection CVEs, most rated 9.8, was published October 29 and 30, days after the wave of attempts against the core's upgrade path. For hospitality the finding repeats itself: the never-patched microsite is the property's most fragile entry point, and it touches guest data before it ever reaches the property management system.