The wpForo Forum plugin for WordPress is vulnerable to SQL Injection via the 'slug' attribute of the…

CVE-2024-3200 is an SQL injection flaw in the wpForo shortcode's slug attribute in wpForo Forum for WordPress <= 2.3.3. The vulnerable path lets an attacker who already has WordPress contributor-level access or higher feed crafted input into a query that is not safely prepared, enabling database reads and potentially broader follow-on abuse depending on what secrets are stored in that WordPress database. The upstream fix landed in 2.3.4.

The vendor's 9.9 CRITICAL score overstates the operational risk for most enterprises. The decisive friction is not the SQL syntax; it's the attacker position requirement: this is not unauthenticated internet spray, it is post-auth web app abuse against a plugin with about 20,000+ active installs, and many real deployments do not hand out contributor rights to strangers. NVD's later 6.5 MEDIUM is closer to reality because the most reliable outcome is data extraction, not turnkey site destruction.

Why this verdict

• Downward pressure: requires authenticated contributor+ access — this is not unauthenticated remote exploitation; it assumes prior compromise, weak role assignment, or an intentionally open content workflow.
• Downward pressure: exposed population is narrower than the CVSS suggests — wpForo shows about 20,000+ installs, and only a subset of those also grant contributors the ability to hit this shortcode path.
• Downward pressure: likely impact is confidentiality-first — NVD's 6.5 MEDIUM vector better matches the most dependable outcome: database read/exfiltration rather than direct integrity/availability takeover.
• Upward pressure: internet-facing app and low exploit complexity once prerequisites are met — if an attacker already has the right WordPress role, exploitation is straightforward and can expose high-value secrets.
• Upward pressure: WordPress secrets often chain well — password hashes, salts, plugin tokens, and email data can enable follow-on account takeover or content abuse.

Why not higher?

Because the prerequisite stack compounds hard: internet-facing WordPress is not enough; the attacker also needs valid credentials, the right role, and a renderable shortcode path. There is also no KEV listing and no strong public evidence of large-scale exploitation pressure, so treating this as CRITICAL would blur the line between pre-auth edge risk and post-auth application abuse.

Why not lower?

Because this is still SQL injection in a public web application, not a cosmetic bug. Once the attacker has the required role, the path to database exposure is short, and WordPress databases often contain enough secrets to turn a 'read-only' web bug into materially useful compromise.

1. Restrict contributor issuance — Audit WordPress role assignments and remove unnecessary contributor or higher privileges on sites running wpForo. This directly attacks the main exploit prerequisite and should be completed within the MEDIUM-severity decision window by prioritizing immediately where roles are internet-reachable, even though there is no formal mitigation SLA for MEDIUM.
2. Force MFA on WordPress logins — Require MFA for all editorial and administrative WordPress accounts, especially any account able to create content or manage forum pages. This reduces the most realistic attacker path—credential theft—and should be deployed as a durable control while you work through remediation.
3. Disable unneeded self-registration and content preview paths — If a site does not need public account creation or user-authored shortcode content, turn those off. This shrinks the reachable population materially and is the cleanest temporary control where patching must be staged.
4. Monitor shortcode-bearing content changes — Alert on new or modified posts/pages containing [wpforo and correlate with non-admin users. This will not block exploitation, but it gives defenders a cheap tripwire for the exact abuse path.
5. Tune WAF and DB logging for authenticated SQLi — Focus signatures and anomaly rules on authenticated requests hitting forum/post rendering endpoints with suspicious quote, UNION, comment, or timing patterns. It is not perfect, but it raises attacker cost and may catch iterative testing before large exfiltration.

Run this on the WordPress host or on a mounted backup of the web root. Invoke it as bash check-wpforo-cve-2024-3200.sh /var/www/html (replace with your WordPress root). It needs read access to the plugin directory; root is not required unless your web files are permission-restricted.

#!/usr/bin/env bash
# check-wpforo-cve-2024-3200.sh
# Detects whether a local WordPress installation has a vulnerable wpForo version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

if [ "$#" -ne 1 ]; then
  echo "Usage: $0 /path/to/wordpress_root"
  exit 3
fi

WP_ROOT="$1"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/wpforo"
README_FILE="$PLUGIN_DIR/readme.txt"
MAIN_FILE="$PLUGIN_DIR/wpforo.php"
VERSION=""

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

# Try to read Stable tag from readme.txt first
if [ -f "$README_FILE" ]; then
  VERSION=$(grep -iE '^Stable tag:' "$README_FILE" 2>/dev/null | head -n1 | sed -E 's/^Stable tag:[[:space:]]*//I' | tr -d '\r')
fi

# Fallback to Version header in main plugin file
if [ -z "$VERSION" ] && [ -f "$MAIN_FILE" ]; then
  VERSION=$(grep -iE '^[[:space:]]*Version:' "$MAIN_FILE" 2>/dev/null | head -n1 | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not determine wpForo version from $README_FILE or $MAIN_FILE"
  exit 2
fi

# Normalize common suffixes, keeping only the leading numeric version for comparison.
NORM_VERSION=$(printf '%s' "$VERSION" | sed -E 's/^([0-9]+(\.[0-9]+){0,3}).*/\1/')

if [ -z "$NORM_VERSION" ]; then
  echo "UNKNOWN - parsed version is empty (raw version: $VERSION)"
  exit 2
fi

verlte() {
  [ "$1" = "$2" ] && return 0
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

if verlte "$NORM_VERSION" "2.3.3"; then
  echo "VULNERABLE - wpForo version $NORM_VERSION detected (affected: <= 2.3.3, fixed: 2.3.4)"
  exit 1
fi

if [ "$NORM_VERSION" = "2.3.4" ] || ! verlte "$NORM_VERSION" "2.3.3"; then
  echo "PATCHED - wpForo version $NORM_VERSION detected"
  exit 0
fi

echo "UNKNOWN - unable to classify version $NORM_VERSION"
exit 2

Sources

1. NVD CVE-2024-3200
2. Wordfence advisory
3. Patchstack advisory
4. WordPress.org wpForo plugin page
5. CISA Known Exploited Vulnerabilities catalog
6. OpenCVE record
7. CVE Details record