The Slider Revolution plugin for WordPress is vulnerable to Arbitrary File Upload in versions 7

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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.

#!/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

Sources

1. NVD CVE-2026-6692
2. Wordfence vulnerability record
3. Wordfence research blog
4. Slider Revolution changelog
5. WPScan entry
6. OpenCVE / CISA ADP view
7. CISA KEV catalog