Description

Ninja Forms 3.15.3 stores an anonymous non-RTE textarea value and renders it without safe HTML encoding in the legacy submission editor. An attacker can break out of the textarea with stored script. When an Administrator opens the attacker-known direct submission URL, the script runs in the WordPress admin origin.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-09-22T07:16:31.340Z",
  "pubdate": "2026-09-22T07:16:31.340Z",
  "executiveSummary": "Ninja Forms version 3.15.3 is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability located within its legacy submission editor. The flaw originates from the improper sanitization and encoding of user-supplied data submitted through non-Rich Text Editor (RTE) textarea fields.\nAn unauthenticated attacker can inject arbitrary malicious JavaScript into submission fields, which is then stored in the database. The payload is subsequently executed within the context of the WordPress administrator's session when the administrator views the specific submission through the legacy editor interface.\nThis vulnerability poses a significant security risk, as successful exploitation allows an attacker to execute scripts within the high-privilege WordPress admin origin. This can lead to unauthorized actions, administrative account takeover, data exfiltration, or the deployment of further malicious payloads. Exploitation requires no authentication from the attacker, but necessitates that an administrator interacts with the compromised submission data.\nThe primary risk implication is the potential for full site compromise if an administrator with sufficient privileges views the malicious submission.",
  "technicalDetails": "The vulnerability resides in how the legacy submission editor processes and renders data submitted via non-RTE textarea fields in Ninja Forms 3.15.3. The root cause is the lack of context-aware output encoding when the plugin retrieves stored submission data from the database for display in the admin dashboard.\nWhen a user submits data through a textarea field configured without the RTE, the application fails to adequately sanitize the input or encode it upon output. An attacker can craft a payload containing HTML tags and JavaScript (e.g., <script>alert(document.domain)</script> or equivalent obfuscated variants) within the textarea content. Because the application does not implement strict input validation or output escaping, this malicious payload is stored persistently in the database as part of the form submission record.\nThe attack flow follows these steps: 1) The attacker identifies a target Ninja Forms instance and determines that a textarea field lacks RTE functionality. 2) The attacker submits a crafted malicious payload via this field, which is recorded in the submission database. 3) The attacker identifies or predicts the direct submission URL associated with the record. 4) The attacker lures or waits for a WordPress administrator to access the specific submission record via the legacy submission editor in the admin panel. 5) Upon opening the submission, the plugin renders the malicious payload directly into the DOM without escaping characters. 6) The browser interprets the injected JavaScript and executes it within the context of the administrator’s session, granting the attacker the permissions associated with the administrator's account.\nThis vulnerability is classified as Stored XSS because the payload is permanently stored in the application's backend. The execution of the script is triggered automatically upon rendering the content in the legacy submission view. Since the script executes within the WordPress admin origin, it bypasses Same-Origin Policy (SOP) restrictions, allowing for the manipulation of the administrative interface, exfiltration of session tokens (e.g., via document.cookie), or the execution of administrative functions via unauthorized AJAX requests."
}