HIGH 7.2

CVE-2026-13040: Stored XSS in NEX-Forms WordPress Plugin v9.2.2 – CVSS 7.2 HIGH

NEX-Forms, a WordPress form-builder plugin, contains a stored cross-site scripting (XSS) vulnerability that allows unauthenticated attackers to inject malicious scripts into web pages. Because the vulnerable form submission endpoint lacks both input validation and CSRF protection, anyone can craft a malicious form submission that persists in the database. When legitimate users later view pages containing the injected content, the attacker's scripts execute in their browsers, potentially compromising user sessions, stealing credentials, or redirecting visitors to malicious sites.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.2 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Weaknesses (CWE)
CWE-79
Affected products
0 configuration(s)
Published / Modified
2026-07-03 / 2026-07-07

NVD description (verbatim)

The NEX-Forms – Ultimate Forms Plugin for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'real_val__' parameter in all versions up to, and including, 9.2.2 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. The submission endpoint is registered via wp_ajax_nopriv_submit_nex_form with no nonce verification, making it fully accessible to unauthenticated attackers without any CSRF token.

14 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-13040 is a stored XSS vulnerability in NEX-Forms versions up to 9.2.2, stemming from insufficient sanitization of the 'real_val__' parameter and inadequate output escaping. The vulnerability exists in the form submission handler registered via wp_ajax_nopriv_submit_nex_form, an AJAX endpoint explicitly designed to accept unauthenticated requests. The absence of nonce verification compounds the risk, allowing attackers to bypass WordPress's standard CSRF protections. User-supplied input flows directly into stored data without proper escaping, enabling persistent payload injection. When content containing injected scripts is rendered to other users, the malicious JavaScript executes with the privileges of the viewing user.

Business impact

A successful exploit could compromise the reputation and integrity of any website using vulnerable versions of NEX-Forms. Customer data submitted through forms may be intercepted or exfiltrated. Visitor sessions can be hijacked, enabling account takeover or fraudulent transactions. Malware distribution campaigns could be launched via compromised form pages. Regulatory exposure increases for organizations handling sensitive user information; stored XSS on forms can breach PCI-DSS, GDPR, and HIPAA compliance requirements. Website defacement and SEO poisoning further amplify reputational and business risk.

Affected systems

All versions of the NEX-Forms – Ultimate Forms Plugin for WordPress up to and including version 9.2.2 are vulnerable. Any WordPress installation using this plugin in an affected version is at risk, regardless of site size or configuration. Multisite WordPress networks are particularly exposed because a single compromised plugin instance can affect multiple properties. The vulnerability affects sites whether forms are used for lead generation, customer contact, commerce transactions, or event registration.

Exploitability

Exploitability is high and straightforward. The vulnerability requires no authentication, no special privileges, and no user interaction beyond normal form submission. An attacker simply crafts a POST request to the wp-admin/admin-ajax.php endpoint with action=submit_nex_form and injects malicious JavaScript into the 'real_val__' parameter. The lack of nonce verification means standard CSRF protections do not apply. Once stored, the payload executes automatically whenever any user accesses the affected page, creating a persistent attack surface. No special technical skills are required; basic HTTP tools or JavaScript are sufficient.

Remediation

Immediately update NEX-Forms to a patched version released after 9.2.2—verify the exact version number in the plugin's official repository or vendor advisory. If an immediate patch is unavailable, disable the plugin until a fix is released. Review form submissions stored in the database for suspicious or encoded content that may indicate prior exploitation. Implement Web Application Firewall (WAF) rules to detect and block requests containing script tags or event handlers in form parameters. Apply WordPress security hardening practices, including limiting AJAX endpoint access where feasible and enforcing strong authentication controls.

Patch guidance

Check the NEX-Forms plugin repository on WordPress.org or the vendor's official website for the latest released version. Update the plugin through the WordPress dashboard (Plugins > Installed Plugins > NEX-Forms > Update). After updating, clear browser caches and verify form functionality across your site. If automatic updates are enabled, ensure they are configured for this plugin. Test form submissions on a staging environment before deploying to production. Document the update date and version number for compliance auditing purposes.

Detection guidance

Monitor admin-ajax.php requests for the action parameter value 'submit_nex_form' paired with suspicious payloads in POST data, particularly those containing <script>, onclick, onerror, or other event handler attributes. Review form submission logs and database records for encoded or obfuscated JavaScript patterns. Implement content security policy (CSP) headers to restrict script execution sources. Query your WordPress database for stored form values containing script tags or HTML entities that decode to malicious content. Use WordPress security plugins with XSS detection capabilities to scan stored post metadata and form submission records. Check page revisions and edit logs for unexpected modifications to published content.

Why prioritize this

This vulnerability scores HIGH (CVSS 7.2) due to its network-accessible, unauthenticated attack vector, combined with stored persistence that affects all site visitors. The lack of CSRF protection and straightforward exploitation significantly elevate risk. While the vulnerability does not directly impact system availability or enable unauthorized access to other systems, its scope is changed (XSS can affect other users and systems), and it provides a foothold for follow-on attacks such as credential theft, malware distribution, or advanced phishing. For any organization using NEX-Forms to collect user data or drive revenue through forms, this is a critical remediation priority.

Risk score, explained

CVSS 3.1 score of 7.2 reflects: Network-Accessible (AV:N) with Low Attack Complexity (AC:L), requiring no privileges or user interaction (PR:N, UI:N). The vulnerability changes scope (S:C), meaning it affects resources beyond the vulnerable component—in this case, other users' browsers. Confidentiality and Integrity are both impacted (C:L, I:L) through session hijacking and malicious script injection. Availability is not affected (A:N). The 'HIGH' severity designation appropriately signals that patching should be prioritized, particularly for public-facing websites and applications handling sensitive data.

Frequently asked questions

Can this vulnerability be exploited if the NEX-Forms plugin is installed but inactive?

If the plugin is installed but deactivated, the vulnerable AJAX endpoint will not be registered, preventing exploitation. However, best practice is to either remove unused plugins entirely or ensure they are updated to patched versions before reactivation. Simply leaving a vulnerable version disabled creates risk if it is accidentally or intentionally reactivated.

Will a Web Application Firewall (WAF) fully protect us if we cannot patch immediately?

A well-configured WAF can significantly reduce risk by blocking malicious form submissions containing script tags and event handlers. However, WAF rules may be bypassed through encoding, obfuscation, or novel payloads, and WAF does not prevent exploitation of submissions already stored in the database. WAF should be treated as a temporary mitigation, not a substitute for patching.

If an attacker injects a payload, how long does it persist before being displayed to users?

Payloads are stored immediately in the database upon submission. They persist and execute every time any user accesses the affected page, until the form data is manually deleted or the site is restored from a clean backup. This means a single injection can compromise thousands of users over days, weeks, or longer if the plugin remains unpatched and the malicious entry is not discovered.

Does WordPress's built-in sanitization functions protect against this vulnerability?

The vulnerability exists precisely because the plugin does not properly apply WordPress's sanitization and escaping functions (such as sanitize_text_field, wp_kses_post, or esc_html) to the 'real_val__' parameter. If the developer had used these functions correctly, the vulnerability would not exist. Update to the patched version, which implements proper sanitization.

This analysis is provided for informational purposes to assist security professionals in vulnerability assessment and remediation prioritization. It is not a substitute for vendor advisories, security research, or professional penetration testing. Readers should verify all patch versions, affected product ranges, and mitigation strategies against official vendor documentation and their own environmental configurations. No exploit code or weaponized proof-of-concept is included; this document is intended for defensive use only. SEC.co makes no warranty regarding the completeness or accuracy of this analysis, and organizations should conduct independent risk assessment aligned with their compliance and business requirements. Source: NVD (public-domain), retrieved 2026-08-11. Analysis generated by SEC.co (claude-haiku-4-5).