Ninja Forms EUVD-2026-84281

Requires the legacy submission editor code path where an anonymous, non-RTE textarea field value is rendered without safe HTML encoding in the WordPress admin (admin-metabox-sub-fields.html.php). Exploitation is limited by required victim interaction: a logged-in Administrator must open the specific attacker-known direct submission URL for the stored payload to execute - it does not fire automatically. The public-facing form must accept a textarea field (the injection vector), and the affected version is Ninja Forms 3.15.3 (and earlier) before the 3.15.4 fix. The initial submission itself is unauthenticated.

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2) rates this a High, but it overstates real-world triggerability: the description explicitly requires that 'an Administrator opens the attacker-known direct submission URL' before the stored script runs, which is user interaction - so UI:N conflicts with the described exploitation and should be UI:R. PR:N is correct because the malicious textarea value is submitted anonymously through a public form (no attacker account needed). This is a stored/persistent XSS confined to the WordPress wp-admin origin (S:C is justified) with only low confidentiality/integrity impact (C:L/I:L) and no availability impact - not code execution or data-store compromise. No EPSS score, no CISA KEV listing, and no public POC were provided, so this is not a demonstrated priority for mass exploitation; realistic risk is moderate and contingent on an admin viewing a specific attacker-supplied submission. The high plugin footprint raises aggregate exposure, but the required admin interaction and low technical impact keep this well below the urgency of an unauthenticated RCE. Net: a legitimate but not emergency-tier fix - patch on normal cadence.

An unauthenticated attacker submits a Ninja Forms contact form whose non-RTE textarea field contains markup that breaks out of the textarea and injects a stored <script>. Later, a WordPress administrator opens that submission in the legacy submission editor (via a direct submission URL the attacker can predict/share), and the script executes in the wp-admin origin, enabling admin-context actions such as creating users or planting a backdoor. No public exploit code was identified at time of analysis, though the vulnerable code paths are documented in the WordPress plugin SVN.