The rtMedia for WordPress

CVE-2024-3293 is a blind SQL injection in the rtmedia_gallery shortcode of the rtMedia WordPress plugin. Affected versions are all releases through 4.6.18; the fix landed in 4.6.19. Exploitation requires an attacker to already have a Contributor-level account or higher on a WordPress site running this specific plugin.

The vendor's 8.8/HIGH score is technically defensible in CVSS terms because SQLi against the application database can be ugly. But real-world risk is lower: this is a niche plugin with about 8,000+ active installs, it is post-auth, and the path starts with either stolen credentials or an intentionally granted low-privilege publishing role. That combination materially shrinks the exposed population and makes this a MEDIUM operational priority for most enterprises.

Why this verdict

• Requires authenticated Contributor access: this is not unauthenticated internet spray-and-pray. PR:L here implies prior compromise, open registration, or a deliberately granted publishing role, which is a major real-world downgrade from the vendor baseline.
• Narrow deployment population: rtMedia is a relatively niche BuddyPress/bbPress plugin with about 8,000+ active installs, not a ubiquitous enterprise platform. Reachable population is far smaller than the generic WordPress ecosystem.
• Still meaningful impact after auth: if an attacker already has the role they need, blind SQLi can expose database contents and create credible follow-on admin takeover paths. That keeps it above LOW despite the friction.

Why not higher?

There is no unauthenticated path, no KEV listing, and no strong public evidence of broad exploitation campaigns. It is also blind SQLi in a plugin-specific shortcode path, not a straightforward pre-auth RCE on a commonly exposed enterprise service.

Why not lower?

This is still SQL injection in production application code, and once the attacker satisfies the role requirement the blast radius can include credential material, sensitive community data, and WordPress configuration secrets. Contributor accounts are not hypothetical on editorial or community sites, so dismissing it as mere backlog noise would be sloppy.

1. Shut down untrusted Contributor creation — If the site allows self-registration or loosely governed Contributor issuance, close that gap first. For a MEDIUM verdict there is no mitigation SLA; use this as an interim control where patching will lag, and keep it in place until the plugin is updated within the 365-day remediation window.
2. Restrict shortcode-capable authoring to trusted users — Move community authors to lower-trust workflows, limit who can save or render content using rtMedia features, and review custom role plugins that accidentally broaden publishing rights. Again, no mitigation SLA for MEDIUM—apply during normal change control if needed, then remove once patched.
3. Put WordPress auth behind SSO and MFA — This does not fix the bug, but it attacks the most important prerequisite: authenticated access. Roll it in as part of identity hardening for any externally reachable WordPress authoring surface, especially if those sites host contractors, moderators, or community contributors.
4. Review Contributor accounts and recent role changes — Audit who has Contributor+ on sites running buddypress-media, look for stale accounts, and remove anyone who no longer needs authoring access. That trims the reachable attack population immediately while you schedule the actual plugin update.

Run this on the target WordPress host or a mounted copy of the site's filesystem. Invoke it as sudo bash verify_cve_2024_3293.sh /var/www/html or point it directly at the plugin directory, for example sudo bash verify_cve_2024_3293.sh /var/www/html/wp-content/plugins/buddypress-media; it needs read access to the plugin files.

#!/usr/bin/env bash
# verify_cve_2024_3293.sh
# Check whether the rtMedia WordPress plugin is vulnerable to CVE-2024-3293.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET="${1:-/var/www/html}"
PLUGIN_DIR=""
VERSION=""

if [[ -d "$TARGET/wp-content/plugins/buddypress-media" ]]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/buddypress-media"
elif [[ -d "$TARGET" && "$(basename "$TARGET")" == "buddypress-media" ]]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - could not find buddypress-media plugin directory from: $TARGET"
  exit 2
fi

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

extract_from_readme() {
  local f="$1/readme.txt"
  if [[ -f "$f" ]]; then
    awk -F': ' 'BEGIN{IGNORECASE=1} /^Stable tag:/ {print $2; exit}' "$f" | tr -d '\r'
  fi
}

extract_from_php_headers() {
  local dir="$1"
  local php
  while IFS= read -r -d '' php; do
    local v
    v=$(awk -F': ' 'BEGIN{IGNORECASE=1} /^Version:/ {print $2; exit}' "$php" | tr -d '\r')
    if [[ -n "$v" ]]; then
      echo "$v"
      return 0
    fi
  done < <(find "$dir" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)
  return 1
}

VERSION=$(extract_from_readme "$PLUGIN_DIR")
if [[ -z "$VERSION" ]]; then
  VERSION=$(extract_from_php_headers "$PLUGIN_DIR" || true)
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine installed rtMedia version in $PLUGIN_DIR"
  exit 2
fi

if version_lte "$VERSION" "4.6.18"; then
  echo "VULNERABLE - rtMedia version $VERSION is <= 4.6.18 (fixed in 4.6.19)"
  exit 1
fi

if version_lte "4.6.19" "$VERSION"; then
  echo "PATCHED - rtMedia version $VERSION is >= 4.6.19"
  exit 0
fi

echo "UNKNOWN - parsed version '$VERSION' but could not classify"
exit 2

Sources

1. NVD CVE-2024-3293
2. Wordfence advisory
3. WordPress.org plugin page and changelog
4. WPScan vulnerability entry
5. Patchstack advisory
6. CISA Known Exploited Vulnerabilities Catalog
7. CVE Details EPSS and timeline mirror
8. CVEFeed PoC tracking