Gravity Forms vulnerability: Why 3.1.2 Is Still at Risk

The Gravity Forms vulnerability CVE-2026-103039 is a reason to check the exact plugin version, not just whether someone remembers updating it. The newly disclosed PHP object injection flaw affects releases through 3.1.2. 3.1.3 contains the fix, according to Wordfence's advisory, published on 29 October 2026.

The practical priority is to update, then identify forms that create WordPress posts using the affected custom-field configuration. Patchstack marks this vulnerability as known to be exploited. That warrants action, while leaving an important question open: what evidence exists for your particular site?

Check the installed release and the forms that write post data.

The short version

All current-state checks in this article are dated 31 October 2026, US Eastern time. Release dates and disclosure dates describe different events.

How the Gravity Forms vulnerability works

Gravity Forms' Post Custom Field lets a submission populate a WordPress post's custom data. It belongs to the Post Fields group and works with other post-creation fields. That is more specific than an ordinary contact form containing a text box or list.

In the vulnerable path, submitted data can be interpreted as a PHP object instead of remaining ordinary field content. The CVE description identifies a Post Custom Field with List as its input type and describes the role of an enabled content template. The conceptual failure is unsafe interpretation at the boundary between untrusted submissions and post metadata.

The trust boundary described by Wordfence. This diagram shows relationships, without an exploit sequence.

Call the flaw PHP object injection. Remote code execution is a possible consequence when additional code and environmental conditions align. The advisory does not establish that installing Gravity Forms alone makes every site directly exploitable for code execution.

Credit goes to Tin Pham (TF1T), Hao Ngo and Trong Pham, the researchers named in the CVE record.

What conditions matter on a real site?

The Wordfence description connects the flaw to a specific post-creation path. Review whether an affected release runs a reachable form containing a Post Custom Field whose Field Type is List. Its content-template configuration also matters. The attacker does not need an account; the published vector does not require a victim click.

There is a documentation mismatch worth keeping visible. The vendor's Create Content Template guide describes that option for Post Custom Fields using Single line text or Paragraph Text. The security advisory describes a List configuration with a content template enabled. We cannot resolve that difference from those pages. A missing checkbox in the current editor is therefore insufficient evidence to clear an older stored configuration. Ask the maintainer to inspect it, and apply the update regardless.

Also avoid confusing this field with the Advanced Post Creation Add-On. The Post Custom Field documentation says that field cannot be used with the add-on, which uses standard fields instead. Record which workflow the site actually uses.

Threat status on 31 October 2026

Exploitation: Patchstack's entry, dated 29 October 2026, labels the flaw known to be exploited. The reviewed entry does not provide victim totals or an attack timeline. We are reporting its assessment, not claiming independent confirmation of compromised sites.

Conflicting enrichment: CISA-ADP's SSVC assessment in the CVE record, timestamped 30 October 2026, records exploitation as none. That differs from Patchstack's label. The public records do not expose enough underlying evidence to reconcile them.

CISA KEV: The identifier was absent from CISA's official JSON mirror, catalog 2026.10.30, checked today. Patchstack's own KEV label is not a CISA listing. Catalog absence is not evidence that attacks cannot have occurred.

Public PoC: A public repository, created on 31 October 2026 according to GitHub's metadata, claims a proof of concept. Its README says an optional payload generator is omitted and no live target was used for validation. We reviewed that documentation, did not execute the script, and do not treat the repository as independently validated end-to-end exploitation. A PoC claim and observed attacks are different evidence.

Dated events from the vendor changelog, CVE record and GitHub repository metadata. The chart measures dates, not attacks or infections.

The patch predates this week's disclosure. The changelog dates the fixed release to 1 October 2026; the release announcement is dated 2 October. We retain that distinction instead of describing an old patch as newly released today.

Is my site affected?

In WordPress administration, open Forms > System Status and read the Gravity Forms Version. The vendor's environment guide documents this screen. Record the plugin version, rather than the separate database version shown in the report.

For a routine inventory on a site without indications of compromise, run this read-only WP-CLI check from the WordPress directory:

wp plugin get gravityforms --field=version --skip-plugins --skip-themes

A missing-plugin error means the component was not found in the installation queried. Confirm the directory before treating that as a useful result. WP-CLI documents that --skip-plugins still loads must-use plugins. For suspected compromise, ask the host to inspect preserved files in a trusted environment instead of bootstrapping the site's PHP.

Next, review post-creating forms in the form editor. Inspect Post Custom Field, Field Type, Custom Field Name, and any stored template configuration using the vendor's field reference. Record the form's owner and where it is exposed. A list of affected-version sites tells an agency where to patch; this form inventory tells it where to focus investigation.

What to do

Update first. Use the current compatible release from the vendor's update channel. The minimum fix is 3.1.3, while the latest release documented today is 3.2.1. Fix reference, current changelog.

Keep a usable backup and test compatibility through your maintenance process. Gravity Forms recommends staging for updates, particularly where add-ons, payments or custom code are involved. Verify the installed version after deployment.

Our recommended acceptance check follows the site's real purpose: submit harmless test content in staging, confirm the expected post and custom-field values, and check notifications. Avoid testing with serialized objects or public exploit tools. If something breaks, involve the maintainer rather than restoring an affected release as a lasting solution.

For an agency, keep a short handoff record: site, installed release, relevant form, configuration owner, deployment result and investigation status. Our WordPress patch-gap article explains why checking deployment matters. Here, add the post-creation workflow to that check.

Were you targeted?

The reviewed Patchstack entry does not publish campaign-specific IP addresses, domains or file hashes. Do not borrow indicators from another Gravity Forms incident.

The CVE description identifies _wp_page_template as a sensitive metadata key in a conditional impact scenario. It is also a legitimate WordPress key, not a compromise signature. Ask a responder to compare unexpected values with the site's approved templates and form configuration.

This read-only SQL inspects stored text through a trusted database console. Run it against a preserved database copy. Replace wp_ with the relevant site's actual table prefix; Multisite requires the correct site's post-metadata table. The columns come from the WordPress schema.

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_page_template'
ORDER BY post_id;

The query does not execute or deserialize the returned values. Keep the output private and review it as text. A legitimate template assignment will match too; absence of a suspicious value does not clear other object-injection paths.

For a deliberately broad error-log lead, search an exported, uncompressed PHP log:

grep -nEi 'unserialize|GFFormsModel|GFCommon' example.com-php-error.log

These strings come from the advisory's component names; the grep filter is our proposed triage aid, not a vendor detection rule. It can match ordinary errors and miss successful attacks. Both checks were tested with harmless matching and nonmatching fixtures.

Correlate findings with retained form entries, post changes and host telemetry. Standard Apache access-log formats do not preserve complete submitted form bodies. Missing logs and unreadable files must remain evidence gaps. For unexplained changes, follow WordPress's incident guidance: document symptoms, preserve a snapshot and involve the host before cleanup.

Where PowerSEC fits

As checked today, PowerSEC's pricing page includes local vulnerability scanning in Free, with CISA KEV issues flagged first, and bulk plugin updates in Pro Protection. These support inventory and remediation tracking. The free external scan checks public signals; it cannot inspect private form configuration or post metadata. A scan neither fixes this flaw nor establishes that a site was not compromised. The vendor update is the fix.

Bottom line

Check the exact release, apply the vendor fix and identify forms that write post custom data. Close the maintenance task with a verified update and a working form. Close any investigation only with documented findings and their limits. A reassuring dashboard badge does not answer what was submitted before patching.

Sources

All sources were fetched on 31 October 2026, US Eastern time. The fresh hook is the disclosure and public PoC listing, not the earlier patch date.

• CVE Program record: published and updated 30 October 2026; disclosure event 29 October. Type, score assigner, affected range, credits and CISA-ADP assessment.

• Wordfence advisory: published 29 October, updated 30 October 2026. Conditions and remediation. WPScan listing: dated 29 October 2026; independently displayed affected/fixed boundary.

• Patchstack advisory: published 29 October 2026; exploited-status label checked today.

• Vendor changelog and release announcement: patch and current-release dates. Post Custom Field, content templates, System Status and staging: operational documentation.

• Public PoC repository and GitHub metadata: created 31 October 2026; author's validation limitations.

• CISA's official KEV mirror: catalog 2026.10.30, released 30 October 2026.

• Command and response references: WP-CLI, WordPress schema, grep, Apache logs and WordPress incident response. Product claims were checked against the PowerSEC pages linked above.

KEV checked on 31 October 2026 against CISA's official mirror, catalog 2026.10.30: CVE-2026-103039 was not listed. Patchstack separately labels it known to be exploited.