Unauthenticated Cross Site Scripting

ARForms is a commercial WordPress form-builder plugin (Repute Infosystems). All versions ≤ 7.1.2 ship an unauthenticated stored XSS in the arf_save_incomplete_form_data AJAX endpoint. An anonymous visitor submits a partially completed form whose value parameter contains a script payload; the plugin writes it to the database without escaping. When a WordPress administrator later opens *Partial Filled Form Entries* in the ARForms dashboard, the payload renders in the admin's browser context.

Vendor / Wordfence-style HIGH (7.1) with S:C is technically defensible — a successful pop lands in an authenticated admin session and can install plugins, create users, or pivot to the host. In practice this is a textbook *user-interaction stored XSS in an admin-only view*, and the per-site blast radius is one WordPress instance. For a defender running ARForms at scale on tenant sites it deserves attention; for an enterprise that does not run ARForms or runs it on a marketing micro-site it is noise. We hold MEDIUM.

Why this verdict

• User interaction gate is real: the payload only fires when an admin manually opens *Partial Filled Form Entries* — a view many ARForms operators never touch. That single condition removes the worm-grade exposure that drives true HIGHs.
• Narrow installed base: ARForms is a commercial Envato/CodeCanyon plugin with an installed base orders of magnitude smaller than Contact Form 7 or Elementor Forms. Most enterprise WP estates do not run it at all.
• Role multiplier: ARForms is deployed almost exclusively in the *typical role* (marketing/contact form on a content site). It is not a domain controller, IdP, hypervisor, CA, PAM, backup, or kernel-mode agent — none of the high-value-role catalog applies. The high-value-role floor of HIGH/CRITICAL is therefore not triggered.
• Per-site blast radius is one WP install. Even a successful pop yields admin on a single tenant site, not the fleet. Enterprises with hardened WP (DISALLOW_FILE_EDIT, MFA, audit logging) further reduce post-XSS pivot value.
• No KEV, no observed exploitation, EPSS will be low. Nothing in the threat-intel signal forces an upgrade.

Why not higher?

HIGH would require either active exploitation, a wormable unauthenticated → RCE chain, or a high-value-role component. None of the three conditions hold: the chain stops at admin-context JS in one WP install, and ARForms is not a fleet-impact component. Vendor's S:C rating is correct on paper but doesn't move the enterprise-scale dial.

Why not lower?

LOW would imply no realistic path to admin compromise. Stored XSS that lands in the WP admin session is materially worse than a reflected XSS or self-XSS — once it fires, full site takeover follows in under a minute. That justifies MEDIUM, not LOW or IGNORE.

1. Block the vulnerable AJAX action at the WAF until patched — Add a WAF rule on admin-ajax.php POSTs with action=arf_save_incomplete_form_data to reject bodies containing <, script, onerror=, onload=, javascript:. Deploy within the standard hygiene window — there is no mitigation SLA at MEDIUM, but for sites that actively use ARForms apply this within ~2 weeks.
2. Disable the *Save Incomplete Form Data* feature in ARForms settings — If the partial-save feature is not a business requirement, turn it off. This neutralizes the sink entirely without waiting for the vendor patch.
3. Set define('DISALLOW_FILE_EDIT', true); and DISALLOW_FILE_MODS in wp-config.php — Even if XSS fires, this prevents the admin session from being used to drop a webshell via theme/plugin editor — collapsing step 4 of the chain. Apply across the WP estate this week as standing hygiene.
4. Audit & purge existing partial-entry rows — Query wp_arforms_* tables for entries containing <script, onerror, javascript: before any admin opens the view. Quarantine suspicious rows in case the bug was exploited before disclosure.
5. Patch to ARForms ≥ 7.1.3 (verify vendor changelog) — Pull from CodeCanyon, stage on a non-prod WP, regression-test forms, deploy. Target the noisgate remediation SLA of ≤ 365 days, but most teams will roll it in the next monthly WP maintenance window.

Run from an auditor workstation against the target WordPress site. No credentials required. Usage: ./check-arforms.sh https://target.example.com — exits 0 PATCHED / 1 VULNERABLE / 2 UNKNOWN.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-57338 ARForms ≤ 7.1.2 stored XSS
set -u
TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 https://site.example.com" >&2
  exit 2
fi

# 1. Confirm ARForms is present
README_URL="${TARGET%/}/wp-content/plugins/arforms/readme.txt"
RESP=$(curl -sSL -o /tmp/arf_readme -w '%{http_code}' "$README_URL" 2>/dev/null)
if [[ "$RESP" != "200" ]]; then
  echo "UNKNOWN: arforms readme not reachable (HTTP $RESP). Plugin may be hidden or absent."
  exit 2
fi

# 2. Parse Stable tag / Version
VER=$(grep -Eim1 '^(Stable tag|Version):' /tmp/arf_readme | awk -F: '{print $2}' | tr -d ' \r')
if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not parse ARForms version from readme."
  exit 2
fi
echo "Detected ARForms version: $VER"

# 3. Version compare — vulnerable if <= 7.1.2
vuln_le() {
  # returns 0 if $1 <= 7.1.2
  printf '%s\n7.1.2\n' "$1" | sort -V | head -n1 | grep -qx "$1" && \
  [[ "$1" != "7.1.3" && "$1" != "7.1.4" ]]
}
if vuln_le "$VER"; then
  # 4. Sanity-poke the endpoint (benign payload, no script execution)
  AJAX="${TARGET%/}/wp-admin/admin-ajax.php"
  PROBE=$(curl -sS -o /dev/null -w '%{http_code}' \
    -X POST "$AJAX" \
    --data 'action=arf_save_incomplete_form_data&form_id=1&field_id=1&value=noisgate-probe')
  echo "AJAX endpoint responded: HTTP $PROBE"
  echo "VULNERABLE: ARForms $VER is in the affected range (<= 7.1.2)."
  exit 1
fi
echo "PATCHED: ARForms $VER is outside the affected range."
exit 0

Sources

1. CISA Vulnerability Summary — Week of June 22, 2026 (SB26-180)
2. CISA Known Exploited Vulnerabilities Catalog
3. Wordfence Threat Intelligence — WordPress vulnerability feed
4. Patchstack WordPress vulnerability database
5. ARForms plugin (CodeCanyon vendor page)
6. WordPress hardening — DISALLOW_FILE_EDIT
7. OWASP Cross-Site Scripting (XSS) reference
8. FIRST EPSS scoring documentation