CVE-2026-90437 in Gravity Forms Plugin
Summary
by MITRE • 10/30/2026
The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Post Excerpt / Post Custom Field / Rich-Text Paragraph Field Values in all versions up to, and including, 3.1.1 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 is possible because Post Excerpt, Post Custom Field, and Rich-Text-Editor-enabled Paragraph Text fields allow raw HTML submissions via allow_html(), and an entity-encoded payload stored in a data-dialog-confirm attribute evades wp_kses_post() at save time but is decoded into executable markup by the browser when the plugin's admin JavaScript passes the attribute value to insertAdjacentHTML().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The Gravity Forms plugin for WordPress, widely utilized for creating complex forms and surveys on websites running the popular content management system, contains a critical security flaw in versions up through 3.1.1 that allows for stored cross-site scripting attacks. This vulnerability stems from insufficient input sanitization and output escaping mechanisms within specific form field types, namely Post Excerpt fields, Post Custom Field inputs, and Rich-Text Paragraph Text fields. These components are designed to allow users to submit raw HTML content through the allow_html function, which is intended to support rich text formatting but inadvertently creates a vector for malicious script injection when proper validation boundaries are not enforced against untrusted input sources.
The technical mechanism of this exploitation relies on a specific interaction between server-side filtering and client-side rendering logic. An attacker can inject an entity-encoded payload into the data-dialog-confirm attribute of these form fields during submission. At the time of saving, the WordPress core function wp_kses_post(), which is responsible for sanitizing post content by stripping out dangerous tags and attributes, fails to detect or remove this specific encoded sequence because it does not decode HTML entities before performing its checks. Consequently, the malicious payload persists in the database without triggering server-side security filters that would typically block such attempts.
The execution of the attack occurs when an administrator or authorized user accesses a page containing the affected form data through the Gravity Forms admin interface. The plugin's JavaScript code retrieves the value from the data-dialog-confirm attribute and passes it directly to the insertAdjacentHTML method for rendering within the DOM. Unlike server-side sanitization, client-side browser engines automatically decode HTML entities before processing them as markup. This decoding process transforms the previously inert entity-encoded payload back into executable script tags or event handlers, which are then immediately executed by the browser environment in the context of the victim's session.
This vulnerability is classified under CWE-79, known as Improper Neutralization of Input During Web Page Generation commonly referred to as Cross-site Scripting XSS. The specific nature of this flaw aligns with CWE-836, which involves using a password field for data storage rather than authentication, although the primary classification remains stored XSS due to the persistence of the payload in the database and its subsequent execution upon page load. From an offensive security perspective, particularly within the MITRE ATT&CK framework, this vulnerability facilitates T1059 Command and Scripting Interpretation via browser-based scripting languages such as JavaScript or ECMAScript. It also supports TA0005 Defense Evasion by leveraging legitimate system functions like insertAdjacentHTML to bypass traditional input validation controls that operate at the application layer rather than the presentation layer.
The operational impact of this vulnerability is severe because it allows unauthenticated attackers to inject arbitrary web scripts into pages viewed by authenticated administrators or users with elevated privileges. Once executed, these scripts can perform a variety of malicious actions including session hijacking through cookie theft, credential harvesting via keyloggers embedded in injected forms, defacement of the administrative interface, or redirection of victims to phishing sites designed to steal sensitive information. Because the payload is stored server-side, every subsequent page load by any authorized user triggers the execution of the malicious code without requiring further interaction from the attacker, creating a persistent and scalable attack vector across all users who view the compromised content.
Mitigation strategies must address both immediate remediation and long-term defensive posture improvements. The primary and most effective mitigation is to upgrade the Gravity Forms plugin to version 3.1.2 or later where this specific input validation flaw has been patched by enforcing stricter sanitization on HTML entities within dialog attributes before they are stored in the database. For organizations unable to immediately patch, implementing a Web Application Firewall WAF rule that detects and blocks entity-encoded script payloads in form submissions can provide temporary protection. Additionally administrators should review user roles and ensure that only trusted individuals have access to create or edit forms containing rich text fields, thereby reducing the attack surface available to unauthenticated actors.
Long-term security enhancements involve adopting a defense-in-depth approach where input validation is performed at multiple layers including client-side JavaScript for immediate feedback and server-side PHP functions for final enforcement. Developers should ensure that any data passed to DOM manipulation methods like insertAdjacentHTML undergoes rigorous decoding and sanitization checks before rendering. Utilizing Content Security Policy headers can also mitigate the impact of successful XSS attacks by restricting the sources from which scripts can be loaded, thereby preventing the execution of injected inline scripts even if they bypass other controls. Regular security audits and penetration testing focused on form handling logic are recommended to identify similar vulnerabilities in custom or third-party plugins before they can be exploited in production environments.