The Secure Copy Content Protection and Content Locking WordPress plugin before 2

CVE-2021-24931 is an unauthenticated SQL injection in the *Secure Copy Content Protection and Content Locking* WordPress plugin. Affected versions are all releases before 2.8.2; the bug sits in the ays_sccp_results_export_file AJAX action, where the sccp_id parameter is fed into a SQL query without proper sanitization. Because the action is reachable through /wp-admin/admin-ajax.php for unauthenticated users, an external attacker can hit it directly over HTTP and pull or tamper with WordPress database content.

The raw 9.8 score is directionally understandable on a lab bench: no auth, no user click, database compromise potential. In real fleets, though, this is not a universal WordPress bug; it only matters on sites running this specific plugin, and even then the practical target set is public-facing WordPress estates rather than your whole enterprise. That trims it down from *internet-on-fire critical* to a very solid HIGH—still patch-worthy fast because public PoC, scanner support, high EPSS, and current attack telemetry all keep the risk elevated.

Why this verdict

• Unauthenticated remote path: no login, no click, no prior foothold; the attacker can hit admin-ajax.php directly from the internet, which preserves a high baseline.
• Public weaponization exists: WPScan published a concrete PoC, NVD links exploit references, and ProjectDiscovery maintains a ready-made nuclei check. This is easy to operationalize with curl, sqlmap, or scanner automation.
• Observed attack pressure is real: despite no KEV listing, CrowdSec reports active exploitation telemetry and hundreds of exploiting IPs, so this is not theoretical shelfware.
• Downward pressure from exposure population: this is a plugin-specific bug. The attacker needs a site that actually runs *Secure Copy Content Protection and Content Locking* below 2.8.2, which sharply narrows the target fraction versus a core WordPress or mass-market plugin issue.
• Blast radius is usually tenant-level: compromise is often severe for the affected WordPress site, but it does not inherently imply domain-wide enterprise compromise unless that site is already a privileged hub.

Why not higher?

I am not calling this CRITICAL because the main friction is population reachability, not exploit syntax. A 9.8 score assumes every network-reachable instance matters equally; in production, only a subset of public WordPress sites with this exact plugin installed are exposed, and the likely blast radius is usually one web tenant at a time rather than immediate estate-wide compromise.

Why not lower?

I am not dropping this to MEDIUM because the attack does not require credentials, internal access, user interaction, or chaining with another bug. Add the public PoC, scanner support, and active opportunistic exploitation telemetry, and this is well above backlog hygiene.

1. Block the vulnerable AJAX action — At the reverse proxy or WAF, block requests to /wp-admin/admin-ajax.php where action=ays_sccp_results_export_file, or restrict that action to trusted admin source ranges if the workflow is genuinely needed. Because there is active exploitation evidence, deploy this within hours, not on a normal 30-day HIGH cycle.
2. Pull external exposure on low-value sites — If the affected site does not need to be public, put it behind VPN, identity-aware proxy, or temporary maintenance controls. This sharply cuts attacker reach and should be done within hours for any internet-facing instance that cannot be patched immediately.
3. Hunt for exploitation telemetry — Search WAF, reverse-proxy, and web logs for /wp-admin/admin-ajax.php requests with action=ays_sccp_results_export_file, array-style sccp_id[], UNION, SLEEP(, or abnormally repeated export attempts. Start the hunt immediately and keep it active until patch coverage is complete.
4. Constrain database privileges where feasible — If your WordPress DB accounts are over-permissioned, reduce them to the minimum schema rights needed by the application. This will not prevent exploitation, but it can limit post-injection write impact; treat it as a supporting control and complete it within the normal HIGH remediation window if urgent containment is already in place.
5. Patch the plugin everywhere it exists — Upgrade all instances to 2.8.2 or later and verify no stragglers remain in staging, DR, or forgotten marketing sites. Because current exploitation exists, treat patching as accelerated and begin within hours, not at the edge of the usual HIGH timeline.

Run this on the target WordPress host or in a build/CI artifact where the plugin files are present. Invoke it as bash check-cve-2021-24931.sh /var/www/html and use a path to the WordPress root; read access only to the plugin directory is sufficient.

#!/usr/bin/env bash
# check-cve-2021-24931.sh
# Detects whether the Secure Copy Content Protection and Content Locking plugin
# is vulnerable to CVE-2021-24931 based on installed version.
#
# Usage: bash check-cve-2021-24931.sh /path/to/wordpress
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN (not installed / unreadable / cannot determine)

set -u

TARGET_VERSION="2.8.2"
WP_ROOT="${1:-}"
PLUGIN_DIR_REL="wp-content/plugins/secure-copy-content-protection"

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

PLUGIN_DIR="$WP_ROOT/$PLUGIN_DIR_REL"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
  exit 2
fi

# Find the plugin header file by looking for the plugin name or a Version header.
PLUGIN_FILE=""
while IFS= read -r -d '' file; do
  if grep -qi "Plugin Name:.*Secure Copy Content Protection" "$file" 2>/dev/null; then
    PLUGIN_FILE="$file"
    break
  fi
done < <(find "$PLUGIN_DIR" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)

if [[ -z "$PLUGIN_FILE" ]]; then
  # Fallback: grab the first PHP file with a Version header.
  while IFS= read -r -d '' file; do
    if grep -qi '^\s*Version:' "$file" 2>/dev/null; then
      PLUGIN_FILE="$file"
      break
    fi
  done < <(find "$PLUGIN_DIR" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)
fi

if [[ -z "$PLUGIN_FILE" || ! -r "$PLUGIN_FILE" ]]; then
  echo "UNKNOWN - could not locate readable plugin header file"
  exit 2
fi

INSTALLED_VERSION=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^\s*Version:/ {print $2; exit}' "$PLUGIN_FILE" | tr -d '\r')

if [[ -z "$INSTALLED_VERSION" ]]; then
  echo "UNKNOWN - could not parse version from $PLUGIN_FILE"
  exit 2
fi

version_lt() {
  # returns 0 if $1 < $2
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" && "$1" != "$2" ]]
}

if version_lt "$INSTALLED_VERSION" "$TARGET_VERSION"; then
  echo "VULNERABLE - installed version $INSTALLED_VERSION is older than fixed version $TARGET_VERSION"
  exit 1
fi

if [[ "$INSTALLED_VERSION" == "$TARGET_VERSION" || "$(printf '%s\n%s\n' "$INSTALLED_VERSION" "$TARGET_VERSION" | sort -V | tail -n1)" == "$INSTALLED_VERSION" ]]; then
  echo "PATCHED - installed version $INSTALLED_VERSION is at or above fixed version $TARGET_VERSION"
  exit 0
fi

echo "UNKNOWN - installed version $INSTALLED_VERSION could not be compared reliably"
exit 2

Sources

1. NVD CVE-2021-24931
2. WPScan advisory
3. WordPress.org plugin page and changelog
4. OpenCVE record with credit and metadata
5. CISA Known Exploited Vulnerabilities catalog
6. CrowdSec CVE explorer telemetry
7. ProjectDiscovery nuclei template
8. Tenable CVE page