CVE-2026-7284 · Easy Elements for Elementor unauthenticated administrator…

01 · The Real Story

This is a master key hidden in a signup form, but only on the few doors that actually installed that keypad

CVE-2026-7284 is a WordPress plugin privilege-escalation bug in Easy Elements for Elementor – Addons & Website Templates. In versions through 1.4.4, the plugin's registration handler trusts attacker-supplied role data, so an unauthenticated visitor can register a new account as administrator and immediately own the site.

The vendor/CNA 9.8 CRITICAL score is technically defensible in a lab because the path is remote, unauthenticated, and ends in full admin. In real enterprise patch queues, though, that score overstates urgency: Wordfence showed only about 1,000 active installs, the plugin was closed on WordPress.org on 2026-05-19, there is no KEV listing or confirmed in-the-wild exploitation, and the reachable attack surface appears tied to the plugin's registration widget rather than every WordPress page.

"Unauthenticated admin creation is nasty, but the exposed population looks small and feature-gated."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a reachable Easy Elements registration surface

An attacker fingerprints a public WordPress site for the easy-elements plugin and looks for a page exposing the plugin's Login/Register functionality. In practice this is done with commodity tooling like curl, httpx, or WPScan against internet-facing sites, then scraping page content and plugin asset paths for clues.

Conditions required:

Target WordPress site is internet-accessible
The easy-elements plugin is installed in a vulnerable version
A public page or AJAX path exposes the plugin registration flow

Where this breaks in practice:

Wordfence listed only about 1,000 active installs, so the victim pool is small
There is no strong internet-wide fingerprint like a unique Shodan banner for this plugin
Many enterprise WordPress sites do not enable self-service registration widgets at all

Detection/coverage: WPScan can identify vulnerable plugin versions when the site exposes enough metadata. General external scanners will have weak coverage unless the plugin assets or widget are public.

STEP 02

Submit crafted registration as administrator

The attacker sends a forged registration request to the vulnerable handler and supplies a privileged role such as administrator. The bug is low-complexity because the server-side code fails to enforce a safe allowlist for the created user's role.

Conditions required:

Registration endpoint is reachable without authentication
The plugin accepts attacker-controlled role data
WordPress/user-registration workflow is enabled enough for account creation

Where this breaks in practice:

A later related bug in the same function path, CVE-2026-9018, explicitly required registration enabled plus a public widget nonce; that strongly suggests the reachable population for this code path is narrower than the raw CVSS implies
WAFs or Wordfence rules may block obviously malformed registration posts
Some deployments add custom approval or registration controls that can break reliable exploitation

Detection/coverage: Watch admin-ajax.php or equivalent registration requests, especially payloads containing elevated role fields. WordPress audit plugins and web logs are your best evidence source.

STEP 03

Log in with the newly created admin account

Once the account is created, the attacker authenticates to wp-admin using the password they chose during registration. From there, they inherit full site administration inside the WordPress trust boundary.

Conditions required:

Admin-capable account was successfully created
The site permits standard wp-admin authentication for that account

Where this breaks in practice:

Mandatory MFA for administrators can stop the takeover from becoming operational
SSO-only admin flows or IP restrictions on wp-admin can contain impact
Alerting on new admin creation can cut dwell time if someone is watching

Detection/coverage: Correlate a fresh user creation event with a near-immediate wp-admin login from the same IP or ASN. EDR usually sees nothing here because this is application-layer abuse until post-login actions occur.

STEP 04

Turn application admin into persistent site control

With administrator rights, the attacker can change content, add backdoor accounts, steal database-held secrets, or often achieve code execution by installing plugins/themes or editing site components. Tools here are boring and effective: the native WordPress admin UI, wp-cli if exposed internally, or direct plugin uploads.

Conditions required:

Administrator session is active
Hardening has not disabled plugin/theme installation or file editing

Where this breaks in practice:

Some hardened WordPress estates disable in-app file editing and plugin installation
Read-only containers, immutable images, or restricted filesystem permissions reduce post-compromise persistence options
Blast radius is usually one WordPress site, not the whole enterprise, unless the host shares credentials or adjacent secrets

Detection/coverage: Look for plugin/theme uploads, unexpected option changes, new scheduled tasks, added admin users, and writes under wp-content. This phase is where EDR, FIM, and webshell scanners finally become useful.

03 · Compensating Control

Disable self-service registration where you can — If the business does not need public account creation, turn off WordPress registration and remove or hide the Easy Elements Login/Register widget. This directly cuts the exploit path and should be done within 30 days for this HIGH verdict.

Enforce MFA on all administrator accounts — This does not fix the bug, but it can stop a freshly created rogue admin from turning into an interactive takeover if your MFA policy triggers on new privileged accounts too. Apply it within 30 days anywhere WordPress admin access is exposed.

Block the vulnerable registration action at the edge — Add a temporary WAF or reverse-proxy rule to challenge or block suspicious registration posts to the plugin's AJAX registration path, especially requests carrying elevated role fields. Use this as a stopgap within 30 days while patching catches up.

Audit for rogue admins and registration spikes — Review WordPress users, audit logs, and web logs for new privileged accounts, bursts of registration attempts, or suspicious admin-ajax.php traffic. Start immediately and keep it in place until all affected sites are remediated.

What doesn't work

Changing the default WordPress new-user role alone does not solve a plugin bug that trusts an attacker-supplied role value.
Hiding or renaming wp-login.php does not matter if exploitation rides the plugin's front-end registration/AJAX path instead of the core login page.
Relying on a public nonce is weak protection if the nonce is rendered into publicly accessible pages; the related CVE-2026-9018 shows exactly that pattern in the same code path.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No confirmed active exploitation found in the sources reviewed. CISA ADP enrichment for the CVE record shows SSVC `Exploitation: none`, and CISA KEV does not list it.
KEV status	Not listed in the CISA KEV catalog as of the lookup.
PoC availability	WPScan says the PoC is withheld until 2026-06-24 to give users time to update. I did not find a verified public GitHub exploit in the reviewed sources.
EPSS	User-supplied EPSS is 0.00099 (~0.099% 30-day exploitation probability). I did not verify a reliable percentile from a primary source at lookup time.
CVSS vector reality check	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` correctly captures the technical path, but it ignores the population filter: tiny install base, widget/registration exposure, and per-site blast radius.
Affected versions	All versions through 1.4.4 are affected according to Wordfence, NVD, and WPScan.
Fixed versions	This CVE is fixed in 1.4.5. However, a follow-on privilege-escalation CVE-2026-9018 hit version 1.4.5, so defenders should prefer 1.4.6 or newer, not stop at 1.4.5.
Exposure population	Wordfence's product page showed roughly 1,000 active installs and the WordPress.org page says the plugin was closed on 2026-05-19 pending review. There is no dependable Shodan/Censys/FOFA fingerprint for this plugin, so internet-wide counts are weak.
Disclosure and researcher	Wordfence attributes the finding to Ankit Patel. Public vulnerability pages show Wordfence published on 2026-05-19, while NVD published on 2026-05-20.
Exploit prerequisites	For this CVE, the CNA text says unauthenticated admin registration via `easyel_handle_register`. Inference from the later CVE-2026-9018 in the same code path: exploitation likely depends on registration being enabled and a public Login/Register widget exposing the necessary workflow surface.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.1/10)

Why this verdict

Baseline starts severe: unauthenticated remote creation of an administrator account is direct application takeover, not a mere information leak or nuisance bug.
Population collapses fast: Wordfence showed only about 1,000 active installs, so this is nowhere near the exposure class of a broadly deployed CMS core or edge appliance bug.
Feature gating matters: the vulnerable path sits in the plugin's registration flow; based on the later related CVE-2026-9018 in the same function area, reachable exploitation likely assumes registration is enabled and a public Login/Register widget is exposed.
Threat intel is cold: no KEV, no verified active exploitation in reviewed sources, and the supplied EPSS 0.00099 is very low for a supposedly urgent internet fire.

Why not higher?

I am not keeping this at CRITICAL because the raw CVSS story assumes every installed site is equally reachable from the internet, and that is not how WordPress plugin bugs work in practice. Small install base, probable widget/registration prerequisites, and no exploitation evidence all cut the operational urgency down a full notch.

Why not lower?

I am not dropping this to MEDIUM because the exploit does not require prior compromise, valid credentials, or user interaction. If your site exposes the vulnerable workflow, the attacker goes straight to administrator, and the jump from there to content abuse, secret theft, or code execution is short.

06 · Verification

Crowdsourced verification payload.

Run this on the target WordPress host or inside the container that holds the site files. Invoke it as bash check-cve-2026-7284.sh /var/www/html and pass the WordPress root path; it needs only read access to the plugin files, though sudo may be required if the webroot is not readable to your shell user.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-cve-2026-7284.sh
# Detects whether a WordPress site is vulnerable to CVE-2026-7284
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

WP_ROOT="${1:-}"
PLUGIN_DIR=""
VERSION=""

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

if [[ ! -d "$WP_ROOT" ]]; then
  echo "UNKNOWN - path does not exist: $WP_ROOT"
  exit 2
fi

if [[ ! -f "$WP_ROOT/wp-config.php" && ! -f "$WP_ROOT/wp-load.php" ]]; then
  echo "UNKNOWN - does not look like a WordPress root: $WP_ROOT"
  exit 2
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/easy-elements"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "PATCHED - easy-elements plugin not present at $PLUGIN_DIR"
  exit 0
fi

# Try readme.txt Stable tag first
if [[ -f "$PLUGIN_DIR/readme.txt" ]]; then
  VERSION=$(grep -iE '^Stable tag:' "$PLUGIN_DIR/readme.txt" | head -n1 | sed -E 's/^[Ss]table [Tt]ag:[[:space:]]*//')
fi

# Fall back to plugin header in the main PHP file
if [[ -z "$VERSION" && -f "$PLUGIN_DIR/easy-elements.php" ]]; then
  VERSION=$(grep -iE '^\s*Version:' "$PLUGIN_DIR/easy-elements.php" | head -n1 | sed -E 's/^\s*[Vv]ersion:[[:space:]]*//')
fi

# Final fallback: scan top-level PHP files for a Version header
if [[ -z "$VERSION" ]]; then
  while IFS= read -r -d '' f; do
    v=$(grep -iE '^\s*Version:' "$f" | head -n1 | sed -E 's/^\s*[Vv]ersion:[[:space:]]*//')
    if [[ -n "$v" ]]; then
      VERSION="$v"
      break
    fi
  done < <(find "$PLUGIN_DIR" -maxdepth 1 -type f -name '*.php' -print0 2>/dev/null)
fi

VERSION=$(echo "$VERSION" | tr -d '\r' | xargs)

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine easy-elements version"
  exit 2
fi

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

if verlte "$VERSION" "1.4.4"; then
  echo "VULNERABLE - easy-elements version $VERSION <= 1.4.4"
  exit 1
fi

if [[ "$VERSION" == "1.4.5" ]]; then
  echo "PATCHED - easy-elements version 1.4.5 fixes CVE-2026-7284 (review CVE-2026-9018 separately)"
  exit 0
fi

echo "PATCHED - easy-elements version $VERSION is newer than 1.4.4"
exit 0