Subscriber Cross Site Scripting

CVE-2026-57329 is a stored/reflected Cross-Site Scripting flaw (CWE-79) in the WooCommerce Designer Pro plugin, affecting all versions ≤ 1.9.34. An attacker who already holds a Subscriber-level account on the target WordPress site can inject script payloads via plugin-controlled input that doesn't sanitize before rendering. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L) tells the whole story: network reachable, but requires *low privilege* auth, *user interaction*, and only yields *low* impact across the triad — with a scope change because the script runs in another user's browser session.

Vendor severity of MEDIUM (6.5) is generous. This is a Subscriber-authenticated XSS in a paid third-party WooCommerce add-on with a small installed base — *not* the core WooCommerce platform, not unauthenticated, not in a Critical path. The realistic worst case is hijacking a shop admin who happens to view the attacker's payload. For most operators of 10,000 hosts this is a hygiene patch, not a fire drill.

Why this verdict

• Authentication required (PR:L): the attacker must hold a subscriber account. Self-registration is common on shops, but this still gates the population of viable targets and provides forensic attribution.
• User interaction required (UI:R): a higher-privileged victim must navigate to the affected page. Stored XSS in admin contexts is real, but the time-to-impact is bounded by admin workflow cadence.
• Narrow installed base: Designer Pro is a niche commercial WooCommerce add-on. Per-site impact is bounded; there is no aggregate fleet exposure comparable to core WooCommerce or Elementor.
• Role multiplier — workstation/LOB shop role: chain succeeds; outcome is *single-shop admin hijack* → site defacement / customer-data scrape. Local-to-tenant blast radius only.
• Role multiplier — high-value role: N/A. Designer Pro does not run on domain controllers, hypervisors, IdPs, PAM, backup admin servers, or CI/CD. There is no canonical high-value-role deployment, so the CRITICAL/HIGH role floor does not apply.
• No KEV, no public PoC, no active exploitation: zero upgrade pressure from threat-intel signals.

Why not higher?

MEDIUM would be defensible if Designer Pro were widely deployed core software or if the bug were unauthenticated. Neither is true — PR:L plus a small installed base plus no exploitation evidence plus no role-multiplier path keeps this below the MEDIUM threshold for an enterprise patch backlog.

Why not lower?

IGNORE would be wrong: it *is* a real XSS with stored impact on the admin session, and S:C confirms scope crosses the privilege boundary. Some shops do allow open subscriber registration, making opportunistic exploitation feasible. LOW correctly reflects that this is real but non-urgent.

1. Deactivate WooCommerce Designer Pro on any site not actively using it — Most stores install it during a campaign and forget — deactivating eliminates the attack surface entirely. No mitigation SLA at LOW; treat as opportunistic hardening alongside the next maintenance window.
2. Enforce a WAF rule blocking known XSS payload signatures on plugin endpoints — Cloudflare / Wordfence / Sucuri all ship generic stored-XSS rule packs. Push the ruleset to block <script>, onerror=, onload=, and javascript: in Designer Pro submission paths.
3. Require 2FA for all administrator and shop-manager accounts — Even if the XSS fires in an admin browser, 2FA on high-impact actions (plugin install, user creation) limits the pivot path. Use WP 2FA or Wordfence Login Security.
4. Set a restrictive Content-Security-Policy header on /wp-admin/ — Block inline-script execution and restrict script-src to first-party. Designer Pro's payload becomes inert even if injected. Roll out behind report-only mode first to catch breakage.
5. Audit existing subscriber-submitted content for stored payloads — Use wp db search or a SQL query against postmeta/options tables for <script, onerror=, onload=, <svg/onload. If the plugin shipped vulnerable for months, payloads may already be staged.

Run this on each WordPress host as root or the www-data user with read access to the WordPress install. Invoke with the document root as the argument: ./check_cve_2026_57329.sh /var/www/html. Exits 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN (plugin not installed or version unreadable).

#!/usr/bin/env bash
# CVE-2026-57329 — WooCommerce Designer Pro XSS (<= 1.9.34)
# Usage: ./check_cve_2026_57329.sh /path/to/wordpress
set -u

WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="${WP_ROOT}/wp-content/plugins/woocommerce-designer-pro"
FIXED_VERSION="1.9.35"

if [[ ! -d "${WP_ROOT}" ]]; then
  echo "UNKNOWN: WordPress root ${WP_ROOT} not found"
  exit 2
fi

if [[ ! -d "${PLUGIN_DIR}" ]]; then
  echo "PATCHED: WooCommerce Designer Pro not installed at ${PLUGIN_DIR}"
  exit 0
fi

# Locate the plugin's main PHP header file (any *.php at top level with 'Version:' header)
MAIN_FILE=$(grep -lE '^[[:space:]]*\*?[[:space:]]*Version:' "${PLUGIN_DIR}"/*.php 2>/dev/null | head -n1)
if [[ -z "${MAIN_FILE}" ]]; then
  echo "UNKNOWN: cannot locate plugin header file in ${PLUGIN_DIR}"
  exit 2
fi

INSTALLED_VERSION=$(grep -iE '^[[:space:]]*\*?[[:space:]]*Version:' "${MAIN_FILE}" | head -n1 | sed -E 's/.*Version:[[:space:]]*([0-9][0-9A-Za-z.\-]*)\b.*/\1/I')
if [[ -z "${INSTALLED_VERSION}" ]]; then
  echo "UNKNOWN: could not parse version from ${MAIN_FILE}"
  exit 2
fi

# Semantic version compare — installed < fixed ?
ver_lt() {
  [[ "$1" == "$2" ]] && return 1
  local IFS=.
  local a=($1) b=($2)
  local len=$(( ${#a[@]} > ${#b[@]} ? ${#a[@]} : ${#b[@]} ))
  for ((i=0; i<len; i++)); do
    local x=${a[i]:-0} y=${b[i]:-0}
    # strip non-numeric trailers
    x=${x%%[!0-9]*}
    y=${y%%[!0-9]*}
    x=${x:-0}; y=${y:-0}
    if (( 10#$x < 10#$y )); then return 0; fi
    if (( 10#$x > 10#$y )); then return 1; fi
  done
  return 1
}

if ver_lt "${INSTALLED_VERSION}" "${FIXED_VERSION}"; then
  echo "VULNERABLE: WooCommerce Designer Pro ${INSTALLED_VERSION} <= 1.9.34 (CVE-2026-57329). Upgrade to >= ${FIXED_VERSION}."
  exit 1
fi

echo "PATCHED: WooCommerce Designer Pro ${INSTALLED_VERSION} >= ${FIXED_VERSION}"
exit 0

Sources

1. Patchstack vulnerability database
2. WPScan WordPress plugin vulnerability index
3. WooCommerce official security advisories
4. WooCommerce GitHub Security Advisories
5. MITRE CWE-79: Improper Neutralization of Input During Web Page Generation
6. FIRST EPSS scoring
7. CISA Known Exploited Vulnerabilities Catalog
8. CVE Details — WooCommerce vendor page