NEX-Forms patches unauthenticated stored XSS via POST key names
TL;DR - NEX-Forms <= 9.1.11: submit_nex_form() stores attacker-controlled POST parameter key names without sanitising or escaping them. No authentication required. Script payloads persist and execute when an admin views the submissions.
What happened
NEX-Forms - Ultimate Forms Plugin for WordPress is a form builder plugin with roughly 7,000 active installations. Its submit_nex_form() handler accepts form submissions and stores them - including, critically, the names of POST parameters.
CVE-2026-5063 describes the problem: those parameter key names are neither sanitised nor escaped before storage or rendering. Anyone can submit a crafted request with a malicious key name and have the payload stored. When an admin later views the submissions, the payload executes in their browser session.
| Item | Detail |
|---|---|
| Affected component | NEX-Forms - Ultimate Forms Plugin for WordPress |
| Vulnerable path | submit_nex_form() |
| Attack vector | Stored XSS via POST parameter key names |
| Affected versions | <= 9.1.11 |
| Severity | CVSS 3.1 7.2 (High) |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N |
This is a well-worn WordPress risk pattern. Public form submission endpoint plus stored XSS equals a reliable path into admin sessions. Once a payload fires in an authenticated admin context, the blast radius extends to the broader plugin ecosystem and anything reachable from that session.
Who is impacted
- WordPress sites running
NEX-Forms - Ultimate Forms Plugin for WordPressat versions<= 9.1.11. - Any site with an internet-facing form backed by the plugin's submission handler.
- WordPress.org lists the plugin at 7,000+ active installations, with
9.1.12as the current listed version.
What to do now
- Update
NEX-Formsnow. Confirm you are not running<= 9.1.11- check wp-admin, lockfiles, backups, and any deployed artifacts. - Treat this as a stored-payload problem, not just a patching problem:
- Review recent form submissions and every admin-facing page that renders submission content. Look for unexpected HTML or JavaScript.
- Check web server logs for requests targeting the plugin's submission path with unusual POST parameter names.
- If you suspect you were exposed, rotate any credentials reachable from a compromised WordPress admin session - WordPress admin accounts, API keys, and any secrets managed through the site.
Related
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.
