The Exclusive Addons for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via…

CVE-2024-1234 is a stored XSS flaw in the WordPress plugin Exclusive Addons for Elementor affecting versions <= 2.6.9. A user with Contributor or higher privileges can place script-bearing payloads into a vulnerable data attribute; that payload is then stored and rendered later when someone loads the poisoned content.

The vendor's MEDIUM 6.4 label is fair in a vacuum, but it oversells real-world urgency for most enterprise patch queues. The decisive friction is the attacker must already have a valid low-privilege WordPress foothold or a site that allows untrusted contributor registrations; that makes this a post-initial-access web-content abuse issue, not a broad unauthenticated internet-exploitation event.

Why this verdict

• Start at vendor 6.4, then cut for attacker position: this is not unauthenticated remote exploitation. Requiring Contributor+ access means the attacker already has a foothold, abused registration, or an insider role; that is major downward pressure.
• Cut again for practical user-interaction reality: despite the vendor's UI:N, the path to meaningful privilege abuse usually requires an admin/editor to load the poisoned content. NVD's later UI:R assessment better fits real operations.
• Cut again for reachable population: only sites running this specific plugin version range and allowing low-privilege content authors into the relevant workflow are exposed. That's far narrower than the raw 'network exploitable' label suggests.
• Do not drop to IGNORE: the payload is stored, durable, and can ride privileged browser context to create admins or alter site state. On multi-author or externally contributed WordPress sites, this is still exploitable enough to fix.

Why not higher?

There is no unauthenticated path, no direct server-side code execution, and no evidence here of active internet-scale exploitation pressure. For most enterprise WordPress estates, a flaw that starts at Contributor+ is downstream of identity compromise or permissive publishing workflows, which sharply limits real attacker reach.

Why not lower?

Stored XSS is not harmless when it lives in a CMS used by admins. If a malicious or compromised contributor can get content in front of an administrator, the browser context can be abused for user creation, settings changes, and persistent site compromise; that keeps it above IGNORE.

1. Lock down Contributor creation — Disable public self-registration where not explicitly needed, review who actually has Contributor/Author roles, and remove stale accounts. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and complete it in the normal WordPress hardening cycle.
2. Require stronger auth for publishing roles — Put MFA and SSO in front of WordPress accounts that can author or edit content so the attacker never reaches the vulnerable state. For a LOW verdict there is no mitigation SLA; handle it as routine identity hardening rather than emergency work.
3. Add editorial approval for low-trust authors — Force review before Contributor-authored content is rendered publicly or viewed by admins. That directly breaks the stored-XSS chain by stopping poisoned content from reaching higher-value sessions; for LOW, do this in the standard workflow-improvement queue.
4. Deploy CSP where feasible — A restrictive Content Security Policy can blunt some XSS payloads, especially script-source and inline execution paths, though WordPress compatibility testing is required. For this LOW issue, schedule carefully as a platform-hardening task, not a fire drill.

Run this on the WordPress host or from a mounted copy of the site filesystem. Invoke it as bash check_cve_2024_1234.sh /var/www/html and it needs only read access to the WordPress files; sudo is only required if the webroot is not readable by your account.

#!/usr/bin/env bash
# check_cve_2024_1234.sh
# Detects whether a WordPress site is vulnerable to CVE-2024-1234
# Affected plugin: Exclusive Addons for Elementor <= 2.6.9
# Patched version: 2.6.9.1+
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_ROOT="${1:-}"
PLUGIN_REL="wp-content/plugins/exclusive-addons-for-elementor/exclusive-addons-for-elementor.php"
PATCHED_VERSION="2.6.9.1"
VULN_CUTOFF="2.6.9"

if [[ -z "$TARGET_ROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/wordpress/root"
  exit 2
fi

PLUGIN_FILE="$TARGET_ROOT/$PLUGIN_REL"

if [[ ! -f "$PLUGIN_FILE" ]]; then
  echo "UNKNOWN - plugin file not found: $PLUGIN_FILE"
  exit 2
fi

version_line=$(grep -iE '^\s*Version:\s*' "$PLUGIN_FILE" | head -n1 || true)
if [[ -z "$version_line" ]]; then
  echo "UNKNOWN - could not parse plugin version from $PLUGIN_FILE"
  exit 2
fi

version=$(echo "$version_line" | sed -E 's/^\s*Version:\s*//I' | tr -d '\r' | xargs)
if [[ -z "$version" ]]; then
  echo "UNKNOWN - empty version field in $PLUGIN_FILE"
  exit 2
fi

verlte() {
  # returns success if $1 <= $2 using sort -V
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" == "$1" ]]
}

verlt() {
  # returns success if $1 < $2
  [[ "$1" != "$2" ]] && verlte "$1" "$2"
}

if verlte "$version" "$VULN_CUTOFF"; then
  echo "VULNERABLE - Exclusive Addons for Elementor version $version (affected: <= $VULN_CUTOFF)"
  exit 1
fi

if verlt "$version" "$PATCHED_VERSION"; then
  echo "UNKNOWN - version $version is above vulnerable cutoff but below expected patched floor $PATCHED_VERSION; verify package provenance/backporting manually"
  exit 2
fi

echo "PATCHED - Exclusive Addons for Elementor version $version (patched: >= $PATCHED_VERSION)"
exit 0

Sources

1. NVD CVE-2024-1234
2. MITRE CVE record
3. Wordfence vulnerability entry
4. WordPress.org plugin page
5. Patchstack advisory
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS User Guide