CVE-2026-6692 · Slider Revolution for WordPress authenticated arbitrary file upload…

01 · The Real Story

This is a loaded loading dock, but only for people who already have a badge

CVE-2026-6692 is an arbitrary file upload bug in the Slider Revolution WordPress plugin caused by weak file-type validation in _get_media_url and _check_file_path. Affected versions are 7.0.0 through 7.0.10; 7.0.10 was only a partial fix, and 7.0.11 is the first fully patched release. If an attacker can authenticate to WordPress at *subscriber* level or higher, the plugin can be tricked into downloading attacker-controlled PHP into a web-accessible uploads path and then executing it.

The vendor's 8.8/HIGH score is technically defensible in a lab because successful exploitation becomes full site compromise. In real enterprise fleets, though, this is not an unauthenticated internet bug: it needs a WordPress login, the vulnerable code lives only in the newer 7.0.0-7.0.10 branch, and Wordfence estimated only about 45,000 vulnerable sites despite 5,000,000+ total installs. That friction is enough to downgrade it to MEDIUM for patch-priority purposes.

"High technical impact, but the chain starts with a low-priv WordPress login and only a narrow 7.x slice is affected."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Get a low-priv WordPress account

The attacker first needs a valid authenticated WordPress session, typically by abusing open registration, compromising a reused password, or taking over a low-value customer/member account. Tooling here is usually just a browser or Burp Suite; there is no exploit value until the attacker is already logged in.

Conditions required:

Internet-facing WordPress site
Slider Revolution installed
Attacker has at least subscriber access

Where this breaks in practice:

Many enterprise sites disable self-registration entirely
MFA, SSO, bot protection, and credential hygiene often stop this before the CVE matters
This prerequisite already implies partial compromise or an intentionally open membership flow

Detection/coverage: IAM logs, WordPress auth logs, IdP telemetry, and WAF bot signals usually see this stage; generic unauthenticated vuln scanners do not.

STEP 02

Reach the whitelisted AJAX action

Per Wordfence's analysis, the plugin exposes library.load.image in the user_allowed list, so an authenticated low-priv user can reach the AJAX path without admin privileges. Attackers use a browser or Burp Suite to replay the authenticated request and associated nonce-bearing workflow.

Conditions required:

Valid logged-in session
Reachability to the normal WordPress application endpoints
Usable nonce from the authenticated workflow

Where this breaks in practice:

Nonce handling adds some request-shaping friction
Application firewalls with WordPress-aware rules can block or log suspicious client_action use
Sites fronted by strong bot/session controls make repeat exploitation noisier

Detection/coverage: Look for authenticated requests tied to RevSlider AJAX operations, especially client_action=library.load.image and unusual data[0][id] values.

STEP 03

Make RevSlider fetch attacker-hosted PHP

The exploit path abuses _check_file_path() and the plugin's download routine so the application fetches a remote file from an attacker-controlled URL and stores it under the plugin's destination path. The weaponized infrastructure is the attacker's own web server serving a PHP webshell or dropper; the vulnerable site becomes the downloader.

Conditions required:

Attacker-controlled URL serving payload content
Server can make outbound HTTP(S) requests
Destination directory writable by the web server/PHP process

Where this breaks in practice:

Outbound filtering or DNS egress controls can break the remote fetch
Some hosting stacks block PHP execution in uploads or disallow dangerous extensions
Wordfence shipped a firewall rule before broad public exposure

Detection/coverage: Web logs, reverse-proxy logs, and EDR/FIM can catch outbound fetches plus new files in wp-content/uploads; version-only scanners still cannot prove exploitability safely.

STEP 04

Call the uploaded file for code execution

Once the file lands in a web-accessible path, the attacker simply browses to it and executes arbitrary PHP, typically using a webshell for persistence and follow-on actions. Tooling is basic curl, browser requests, or a standard PHP webshell operator console.

Conditions required:

Uploaded payload is reachable over HTTP(S)
Web server executes the file type
No compensating control blocks execution from uploads

Where this breaks in practice:

PHP execution disabled in uploads kills the usual win condition
Immutable hosting, read-only containers, or strong FIM/EDR can contain or expose the drop quickly
Some WordPress deployments isolate the web tier enough to limit lateral movement

Detection/coverage: High-signal artifacts include fresh .php, .phtml, or .phar files under uploads, anomalous requests to them, and child-process or shell activity from php-fpm, Apache, or Nginx worker contexts.

03 · Compensating Control

Disable unnecessary self-registration — If a site does not need public sign-ups, turn off WordPress user registration and remove stale low-priv accounts. This cuts off the most realistic entry condition for this CVE; there is no mitigation SLA for a MEDIUM verdict, so apply where practical and still complete patching within the 365-day remediation window.

Enforce MFA and SSO on WordPress logins — Protect every account that can authenticate to the site, including low-priv roles if your business flow allows it. This does not fix the bug, but it attacks the highest-friction precondition; there is no mitigation SLA here, so do it as platform hardening while working toward patch completion inside the 365-day remediation window.

Block PHP execution from uploads — Prevent direct execution of .php, .phtml, .phar, and similar files under wp-content/uploads using web-server policy or hosting controls. This is one of the few controls that meaningfully breaks the RCE end-state even if upload succeeds; deploy opportunistically now, with patching still due inside the 365-day remediation window.

Watch for RevSlider AJAX abuse and new executable files — Create detections for authenticated requests using RevSlider image-loading actions and for freshly created executable files under uploads. This won't prevent exploitation by itself, but it improves time-to-detect on the narrow subset of sites that remain exposed while you remediate within the 365-day window.

What doesn't work

Blocking xmlrpc.php doesn't solve this; the exploit rides normal authenticated WordPress/RevSlider application paths, not XML-RPC specifically.
Unauthenticated perimeter scanning won't tell you much; the bug is auth-gated and version-sensitive, so generic external scanners routinely miss or mis-rank it.
Relying on port exposure data is weak here; Shodan/Censys can see WordPress, but they usually cannot prove revslider presence and exact 7.0.0-7.0.10 versioning reliably.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No authoritative evidence of active exploitation found in the sources reviewed. CISA ADP SSVC in OpenCVE marks `Exploitation: none` and `Automatable: no`.
Proof-of-concept availability	`Wordfence` says it validated a proof-of-concept on `2026-04-20`, but I found no primary-source public GitHub PoC in the reviewed sources. Expect private tradecraft before mass public weaponization.
EPSS	EPSS is about `0.00093` (~`0.09%`, roughly the `26th percentile`), which is very low and consistent with an auth-required niche exploit path.
KEV status	Not listed in CISA KEV in the sources reviewed. That matters because there is no government-backed signal of broad exploitation pressure yet.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` means total impact if reached, but the decisive friction is `PR:L`: the attacker needs a WordPress login first.
Affected versions	Affected range is `7.0.0` through `7.0.10` only. This bug was introduced in the `SR7` line rather than legacy `SR6`, which sharply narrows the exposed population.
Fixed versions	`7.0.10` was only a partial patch; `7.0.11` is the first full fix. Vendor changelog for `7.0.10` explicitly mentions the arbitrary file upload issue, and Wordfence states `7.0.11` fully resolves it.
Exposure data	`Wordfence` lists `5,000,000` active installs for Slider Revolution overall, but its blog estimates only ~45,000 sites were on vulnerable `7.x` builds at disclosure. Shodan/Censys-style internet counts are not reliable here because plugin presence and exact version are not cleanly fingerprintable remotely.
Disclosure timeline	Wordfence received the report on `2026-04-18`, validated the PoC on `2026-04-20`, vendor shipped a partial fix on `2026-04-22`, full fix on `2026-05-04`, and the CVE/NVD publication date is `2026-05-07`.
Researcher / reporting org	Researcher credited by Wordfence/WPScan is h0xilo. The CNA/source on NVD is Wordfence.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.6/10)

Why this verdict

Downshift for attacker position: PR:L is real friction, not paperwork. Requiring a WordPress login means this is usually *post-initial-access* or dependent on self-registration-heavy sites, not a generic internet worm bug.
Downshift for exposure slice: only the SR7 range 7.0.0-7.0.10 is affected. Wordfence's estimate of ~45,000 vulnerable sites versus 5,000,000 active installs materially narrows fleet risk.
Hold above LOW because impact is total: once the chain lands, this is effectively arbitrary PHP upload to webshell/RCE. For the subset of exposed sites with open registration or lots of low-priv users, the blast radius is still full site compromise.

Why not higher?

There is no credible active-exploitation signal in KEV or the reviewed primary sources, EPSS is very low, and the exploit path is gated by authentication. On top of that, the vulnerable population is a narrow branch rather than the full installed base, so this does not justify top-of-queue treatment across a large fleet.

Why not lower?

This is still an arbitrary file upload that can end in remote code execution and complete site takeover. Subscriber-level access is low privilege, not admin, so any externally reachable WordPress property with self-registration, membership, or customer accounts keeps this meaningfully dangerous.

06 · Verification

Crowdsourced verification payload.

Run this on the WordPress host or on a mounted filesystem copy of the site. Invoke it as sudo bash check_revslider_cve_2026_6692.sh /var/www/html (or pass the plugin directory directly, e.g. /var/www/html/wp-content/plugins/revslider); it only needs read access to the plugin files.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_revslider_cve_2026_6692.sh
# Detects whether Slider Revolution is vulnerable to CVE-2026-6692.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

TARGET="${1:-.}"

find_plugin_dir() {
  local t="$1"
  if [ -d "$t" ] && [ -f "$t/revslider.php" ]; then
    echo "$t"
    return 0
  fi
  if [ -d "$t/wp-content/plugins/revslider" ] && [ -f "$t/wp-content/plugins/revslider/revslider.php" ]; then
    echo "$t/wp-content/plugins/revslider"
    return 0
  fi
  return 1
}

normalize_version() {
  # Prints three numeric fields: major minor patch
  local v="$1"
  v="${v%%[^0-9.]*}"
  IFS='.' read -r a b c _ <<< "$v"
  a="${a:-0}"
  b="${b:-0}"
  c="${c:-0}"
  printf "%d %d %d\n" "$a" "$b" "$c"
}

version_ge() {
  local a1 a2 a3 b1 b2 b3
  read -r a1 a2 a3 <<< "$(normalize_version "$1")"
  read -r b1 b2 b3 <<< "$(normalize_version "$2")"

  if [ "$a1" -gt "$b1" ]; then return 0; fi
  if [ "$a1" -lt "$b1" ]; then return 1; fi
  if [ "$a2" -gt "$b2" ]; then return 0; fi
  if [ "$a2" -lt "$b2" ]; then return 1; fi
  if [ "$a3" -ge "$b3" ]; then return 0; fi
  return 1
}

version_le() {
  local a1 a2 a3 b1 b2 b3
  read -r a1 a2 a3 <<< "$(normalize_version "$1")"
  read -r b1 b2 b3 <<< "$(normalize_version "$2")"

  if [ "$a1" -lt "$b1" ]; then return 0; fi
  if [ "$a1" -gt "$b1" ]; then return 1; fi
  if [ "$a2" -lt "$b2" ]; then return 0; fi
  if [ "$a2" -gt "$b2" ]; then return 1; fi
  if [ "$a3" -le "$b3" ]; then return 0; fi
  return 1
}

PLUGIN_DIR="$(find_plugin_dir "$TARGET" 2>/dev/null || true)"
if [ -z "$PLUGIN_DIR" ]; then
  echo "UNKNOWN - could not find revslider plugin directory from target: $TARGET"
  exit 2
fi

VERSION=""
MAIN_FILE="$PLUGIN_DIR/revslider.php"
if [ -f "$MAIN_FILE" ]; then
  VERSION="$(grep -Eim1 '^[[:space:]]*Version:[[:space:]]*' "$MAIN_FILE" | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')"
fi

if [ -z "$VERSION" ] && [ -f "$PLUGIN_DIR/package.json" ]; then
  VERSION="$(grep -Eim1 '"version"[[:space:]]*:' "$PLUGIN_DIR/package.json" | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/' | tr -d '\r')"
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not parse Slider Revolution version in $PLUGIN_DIR"
  exit 2
fi

if version_ge "$VERSION" "7.0.0" && version_le "$VERSION" "7.0.10"; then
  echo "VULNERABLE - Slider Revolution version $VERSION is in affected range 7.0.0-7.0.10 for CVE-2026-6692"
  exit 1
fi

if version_ge "$VERSION" "7.0.11"; then
  echo "PATCHED - Slider Revolution version $VERSION is >= 7.0.11"
  exit 0
fi

# Versions below 7.0.0 are not affected by this specific CVE.
echo "PATCHED - Slider Revolution version $VERSION is outside the affected 7.0.0-7.0.10 range for CVE-2026-6692"
exit 0