Gravity Forms Stored XSS (CVE-2026-3492): What WordPress Site Owners Must Do Now

Author: Hong Kong Security Expert
Date: 2026-03-12

A stored cross-site scripting (XSS) vulnerability was disclosed in Gravity Forms versions up to and including 2.9.28 (patched in 2.9.29). The issue allows an authenticated low-privilege account (Subscriber or similar) to inject JavaScript into a form title that may be stored and executed later when viewed by other users, potentially including users who have higher privileges. The vulnerability has been assigned CVE-2026-3492 and given a CVSS base score of 6.5 (medium). While not the highest-severity issue, it is practical and exploitable in many real-world WordPress deployments — which is why site owners and administrators need to act immediately.

This post explains:

• What this vulnerability is and how it is dangerous
• The likely exploitation scenarios and impact
• Immediate mitigations and detection techniques
• A step-by-step incident response and recovery checklist if you think you were compromised
• Long-term hardening and best practices

Quick summary (for site owners short on time)

• Vulnerability: Stored XSS in Gravity Forms (form title handling).
• Affected versions: Gravity Forms <= 2.9.28 (patched in 2.9.29).
• Privilege required: Authenticated subscriber (lowest common authenticated role).
• Impact: Stored XSS — script stored in database and executed when another user views the form (could lead to session theft, phishing, malicious admin actions, or pivoting).
• Urgency: High for sites that allow subscriber-level users to create or edit forms, or if untrusted users can create content that is later rendered in the admin or public UI.
• Immediate actions: Update Gravity Forms to 2.9.29+; if you cannot patch immediately, apply virtual patching via a managed WAF or similar edge controls, restrict form creation/edit rights, audit forms and user accounts, and enable two-factor authentication.

Technical summary (non-exploitative)

Stored XSS vulnerabilities occur when attacker-supplied data is stored by the application without proper sanitization or encoding, and then later embedded into a page in a context that allows JavaScript execution (for example, an HTML title attribute or content area). In this case the vulnerable vector is a form’s title property handled by the Gravity Forms plugin.

Key technical facts:

• The attacker needs an authenticated account (Subscriber or similar).
• The malicious payload is stored in the WordPress database as part of the form metadata/title.
• The payload is executed when the affected content is rendered for a user with sufficient privileges to view that form (or for visitors if the form is displayed publicly).
• The vulnerability is rated Medium (CVSS 6.5). Successful exploitation can lead to account compromise of viewing users, site defacement, or administrative actions when combined with other poor security controls.

I will not provide proof-of-concept payloads or reproduction steps — providing exploit code is dangerous and irresponsible. Instead, the guidance below focuses on actionable defenses and recovery steps.

Real-world exploitation scenarios

Understanding likely attack scenarios helps prioritise mitigation:

1. Subscriber creates or edits a form title and injects malicious HTML/JavaScript.

   When that form is accessed by an editor/administrator or rendered on a public page, the script executes in the victim’s browser.

   Potential impact: Stealing admin session cookies, executing admin actions, creating new admin users via privileged AJAX endpoints, or planting additional backdoors.

2. Malicious payload triggers when an admin views the Gravity Forms listing or edit screen.

   Potential impact: Admin panel actions performed in the admin context (CSRF-like outcomes via XSS), or redirecting admins to credential-phishing pages.

3. Public-facing forms render titles without escaping.

   Visitors (customers) could be targeted — damaging brand reputation and potentially enabling data theft.

These scenarios are realistic and impactful for many WordPress sites, particularly those that allow public registration, guest posting, or delegate content management to external users.

Immediate steps — patching and mitigation

1. Update Gravity Forms to 2.9.29 or later (recommended)

   This is the definitive fix. Schedule and apply the update immediately. Test updates on a staging environment first where possible, then deploy to production.

2. If you cannot patch immediately, apply virtual patching via a managed WAF or edge security control

   Virtual patching is an effective stop-gap while you plan and test plugin updates. Use reputable managed WAF services or your hosting provider’s security controls to block obvious injection attempts targeting form titles and Gravity Forms endpoints.

3. Restrict form creation/edit capabilities

   Review who can create or edit forms. If Subscriber accounts should not be able to create forms, remove that capability. Consider disabling public registration or applying moderation until the site is patched.

4. Harden admin access

   Enforce two-factor authentication (2FA) for all admin and editor accounts. Limit admin access to specific IP ranges where possible, and use strong, unique passwords with a password manager.

5. Monitor logs and scan for indicators of compromise

   Look for POST requests to admin-ajax.php, Gravity Forms endpoints, or wp-admin form pages with suspicious payloads in the form_title or related fields. Run a full malware scan of your site and database to identify injected JavaScript or other persistent artifacts.

6. Implement Content Security Policy (CSP)

   A strict CSP helps mitigate impact by preventing inline scripts from executing on pages where you don’t allow them. CSP deployment requires careful testing to avoid breaking legitimate functionality.

7. Block common patterns at the server or WAF level

   Examples include blocking form submissions that include <script> tags in form title fields or disallowing HTML in metadata fields that should not contain HTML.

What virtual patching looks like (conceptual)

Edge rules typically look for suspicious payloads in parameters used by the plugin and block or challenge those requests. Rule concepts include:

• Block POST requests to Gravity Forms endpoints (admin-ajax.php, relevant admin pages) where the form_title parameter contains <script> tags or suspicious event handlers (onload, onclick).
• Rate-limit or challenge users creating multiple forms or repeatedly updating metadata.
• Log and alert on blocked attempts for forensic analysis.

These rules should be tuned to avoid false positives. Test rules on staging or under monitoring before enforcing in production where possible.

Example mod_security-style rule (illustrative only)

# Block potential stored XSS in Gravity Forms form_title submissions
SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,log,msg:'Block potential stored XSS in Gravity Forms form_title'"
  SecRule REQUEST_URI "@rx (admin-ajax\.php|wp-admin/admin\.php).*gf_entries|gravityforms" "chain"
  SecRule ARGS_NAMES|ARGS:form_title "@rx (<\s*script|on\w+\s*=|javascript:)" "t:none,t:utf8toUnicode,t:lower"

Notes: The above is intentionally simple. Production rules should include normalization, encoding detection, contextual checks, and whitelists for legitimate HTML where needed. Do not paste third-party rules into production without testing.

Detection and hunting: what to look for in logs and database

If you suspect an attack or want to proactively hunt, check the following:

1. Web server / application logs

   Search for POST requests to:

   • /wp-admin/admin-ajax.php
   • /wp-admin/admin.php (Gravity Forms admin pages)
   • Any REST endpoints used by Gravity Forms

   Look for parameters: form_title, title, post_title containing HTML tags like <script, onerror=, onload=, or javascript: URIs.

   Example grep (adapt for your environment):

   grep -i "form_title" /var/log/apache2/access.log | grep -E "

2. Database search

   Search wp_posts and plugin-specific tables for suspicious strings:

   SELECT ID, post_title FROM wp_posts WHERE post_title LIKE '%<script%';
   SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%';
   SELECT * FROM gf_form WHERE form_title LIKE '%<script%';
   SELECT * FROM gf_form_meta WHERE meta_value LIKE '%<script%';

   Gravity Forms stores form information in custom tables (for example, gf_form, gf_form_meta or serialized arrays). Search those tables as well.

3. File system and theme/plugin files

   Check for recently modified files and unknown PHP files under wp-content/uploads or theme/plugin directories.

4. WAF / security logs

   If you have a WAF or other security service enabled, review blocked requests for patterns targeting Gravity Forms endpoints or parameter names.

add_filter('gform_pre_form_title_save', function($title) {
    // Remove all tags (or apply a more targeted allowlist)
    return wp_strip_all_tags($title);
});