Skip to content

CVE-2026-5063 - NEX-Forms POST key stored XSS

NEX-Forms - Ultimate Forms Plugin for WordPress versions <=9.1.11 contain a high-severity unauthenticated stored cross-site scripting flaw. The vulnerable path accepts attacker-controlled POST parameter key names in submit_nex_form() without enough sanitization and later renders stored entry data without enough escaping.

The practical risk is administrator-browser execution after an unauthenticated form submission. A malicious submitted key can become stored entry content and execute when a privileged WordPress user views affected pages or entries.

Affected versions

  • Vulnerable: NEX-Forms - Ultimate Forms Plugin for WordPress <=9.1.11
  • Fixed: 9.1.12
  • Preferred: Update to the latest available plugin release, not only the minimum fixed version.

Indicator-of-exposure

  • The repository owns a WordPress site, plugin bundle, Bedrock/Composer project, WP-CLI install script, deployment manifest, container image, or runbook that installs nex-forms-express-wp-form-builder.
  • A deployable WordPress target resolves NEX-Forms 9.1.11 or older.
  • Public NEX-Forms submissions are enabled.
  • Administrators or editors review form entries inside wp-admin.

Quick checks:

wp plugin list --fields=name,version,status | grep -E '^nex-forms-express-wp-form-builder[[:space:]]'
wp plugin status nex-forms-express-wp-form-builder
rg -n "nex-forms-express-wp-form-builder|NEX-Forms|submit_nex_form|wp-content/plugins/nex-forms" .
find . -path "*/wp-content/plugins/nex-forms-express-wp-form-builder/*" -maxdepth 8 -type f | head

Remediation strategy

  • Upgrade NEX-Forms to 9.1.12+, preferably the latest release available through WordPress.org, Composer/WPackagist, WP-CLI, or the repository’s plugin artifact channel.
  • If the plugin is not business-critical, remove or deactivate it and document the replacement form workflow.
  • Review stored NEX-Forms entries submitted while the site was vulnerable and remove payload-bearing entry keys or values before administrators continue reviewing entries.
  • Add temporary containment when immediate upgrade is blocked: disable affected forms, restrict admin entry viewing, add WAF rules for suspicious POST parameter names, and strengthen Content Security Policy where the repository owns response headers.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-5063 (NEX-Forms unauthenticated stored XSS via
POST parameter key names). Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or removes the vulnerable
  plugin and documents required operator cleanup, or
- TRIAGE.md if this repository does not own the WordPress plugin deployment or
  cannot make a safe patch.

## Rules

- Scope only CVE-2026-5063.
- Treat form submissions, customer contact data, uploaded files, cookies,
  nonces, WordPress sessions, and administrator URLs as sensitive. Do not print
  real values in logs, tests, screenshots, or PR text.
- Do not create a proof-of-concept payload that exfiltrates cookies, reads
  wp-admin data, phones home, or performs actions as an administrator.
- Do not hand-edit vendored plugin code unless no package/channel upgrade is
  available and the patch is explicitly marked as temporary containment.
- Do not delete production form entries automatically.
- Do not auto-merge.

## Steps

1. Inventory WordPress ownership in this repository:
   - `wp-content/plugins/nex-forms-express-wp-form-builder`;
   - Composer or Bedrock references such as
     `wpackagist-plugin/nex-forms-express-wp-form-builder`;
   - WP-CLI install scripts, Dockerfiles, plugin zips, checksums, Helm charts,
     Terraform, Ansible, or deployment runbooks;
   - response-header, CSP, WAF, and reverse-proxy configuration for the
     affected WordPress site.
2. If the repository does not deploy or package a WordPress site with
   NEX-Forms, stop with `TRIAGE.md` explaining what was checked and who owns the
   runtime remediation.
3. Determine the resolved NEX-Forms version for every deployable target. A
   target is vulnerable if it resolves to `<=9.1.11`.
4. For every vulnerable target, upgrade NEX-Forms to `>=9.1.12`, preferably the
   latest WordPress.org release available through the repo's normal dependency
   channel. Regenerate Composer locks, plugin manifests, image metadata, SBOMs,
   checksums, or deployment render output as appropriate.
5. If the plugin is optional or no longer used, prefer removal or deactivation
   over carrying an exposed form plugin.
6. Add temporary containment if the fixed plugin cannot be deployed
   immediately:
   - disable public NEX-Forms submissions for affected forms;
   - restrict wp-admin entry review to trusted administrators only;
   - block suspicious form POST parameter names at the edge where safe;
   - add or tighten CSP headers where this repo owns response headers;
   - add an emergency runbook for reviewing and cleansing stored entries.
7. Add a PR body section named `CVE-2026-5063 operator actions` that requires:
   - confirmation that production now runs NEX-Forms `>=9.1.12` or that the
     plugin is disabled/removed;
   - review of NEX-Forms entries submitted before the patch for suspicious
     parameter names, HTML, script-like values, SVG payloads, event handlers, or
     encoded JavaScript;
   - safe cleanup of malicious entries before routine admin review resumes;
   - review of web and WordPress logs for suspicious unauthenticated form POSTs;
   - admin session invalidation if malicious payload execution is suspected.
8. Add or update verification that a submitted POST parameter key containing
   HTML/script-like content is sanitized or escaped before admin rendering. Use
   a non-exfiltrating inert marker such as `xss-test-key` and do not include a
   working cookie-stealing payload.
9. Run the relevant validation: Composer/WP-CLI dependency checks, WordPress
   plugin inventory, PHP tests, image build, deployment rendering, CSP tests,
   and security scan available in this repository.
10. Use PR title:
    `fix(sec): remediate CVE-2026-5063 in NEX-Forms`.

## Stop conditions

- No WordPress site or NEX-Forms plugin deployment is controlled by this
  repository.
- The plugin version is managed exclusively in production outside the repo.
- A fixed plugin release cannot be consumed without a broader WordPress
  platform migration.
- The only apparent fix would delete production form entries, expose submitted
  customer data, or ship an exploit-like payload.
- Validation fails for unrelated pre-existing reasons; document the failure
  instead of broadening scope.

Verification - what the reviewer looks for

  • No deployable target still resolves NEX-Forms <=9.1.11.
  • The PR updates the real plugin delivery path, such as Composer lockfiles, WP-CLI scripts, plugin artifacts, images, checksums, or deployment manifests.
  • Stored entry cleanup and admin session guidance are explicit operator actions.
  • Verification covers POST parameter key handling and admin entry rendering without adding a live exploit payload.
  • Build, dependency, image, deployment, and security checks pass or unrelated failures are documented.

Watch for

  • WordPress repositories that vendor plugins under wp-content/plugins while also installing plugins through Composer or WP-CLI.
  • Form-entry data stored in the database that remains dangerous even after the plugin is upgraded.
  • Fixes that sanitize values but forget attacker-controlled POST key names.
  • CSP changes used as a substitute for upgrading the plugin. CSP is containment, not remediation.

References