The BookingPress Pro plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type…

CVE-2026-6960 is an arbitrary file upload bug in BookingPress Pro for WordPress. Per NVD and Wordfence, all versions up to and including 5.6 are affected, and 5.7 is the stated fixed version. The vulnerable path is the booking form submission handler bookingpress_validate_submitted_booking_form_func, where uploads tied to the Signature custom field are not properly type-validated; on an exposed site, that can let an unauthenticated attacker land a server-side file and turn it into remote code execution.

The vendor's 9.8/CRITICAL score is technically understandable because the impact is full site compromise and the attacker needs no credentials. But in real environments this is not a blanket internet-wide WordPress fire: exploitation only works when a site is running the Pro plugin, is still on <= 5.6, has a public booking form, and has the optional Signature field configured on that form. That hidden prerequisite materially shrinks the reachable population, so this lands as HIGH, not CRITICAL.

Why this verdict

• Downgrade for hidden prerequisite: vendor/NVD both state exploitation only works if a Signature custom field is added to the booking form; that is a meaningful exposure filter, not a footnote.
• Still pre-auth and internet-reachable: no credentials, no prior foothold, and no user interaction are required once the vulnerable form exists, so this stays well above MEDIUM.
• Threat telemetry is weak so far: prompt-supplied EPSS 0.00197 is low, there is no KEV listing, and I found no authoritative active-exploitation reporting in the reviewed sources.
• Blast radius is full site takeover: arbitrary file upload on a PHP-backed WordPress host can become code execution, credential theft, content tampering, webshell persistence, and downstream abuse of shared hosting or adjacent secrets.
• Some modern controls can break the chain: WAF rules on the BookingPress AJAX action and 'no PHP execution in uploads' hardening materially raise friction in ways the raw CVSS base score ignores.

Why not higher?

This is not a universal pre-auth WordPress RCE across every BookingPress install. The exploit path depends on an optional premium feature being present on a reachable public form, and some hardened stacks will store uploads in places that do not execute PHP. Those two friction points are enough to keep it out of CRITICAL.

Why not lower?

Once the prerequisite is met, the rest of the chain is ugly: no auth, low complexity, and likely one-request compromise. A successful hit gives the attacker a direct path to server-side code execution on an internet-facing CMS, which is far too consequential for MEDIUM or LOW.

1. Remove or disable Signature fields — If you cannot patch immediately, remove the Signature custom field from public booking forms or disable the affected booking workflow entirely. This directly breaks the documented prerequisite for exploitation and should be deployed within 30 days for a HIGH verdict.
2. Block the BookingPress upload action at the edge — Add a reverse-proxy or WAF rule to scrutinize or block multipart uploads hitting wp-admin/admin-ajax.php when the action is bookingpress_validate_submitted_booking_form, especially for suspicious filenames, MIME mismatches, or PHP extensions. Treat this as the main temporary shield and deploy it within 30 days.
3. Disable script execution in upload paths — Enforce web-server policy so wp-content/uploads and any BookingPress-specific upload subdirectories cannot execute PHP or other server-side scripts. This does not fix the upload bug, but it can turn full RCE into a failed post-upload step; implement within 30 days.
4. Hunt for webshell artifacts — Review wp-content/uploads for newly created .php, double-extension files, anomalous image/polyglot payloads, and suspicious timestamps near the disclosure window. Pair file review with HTTP logs for direct requests into upload directories; start immediately and complete the first sweep within 30 days.
5. Constrain egress from the web tier — If an attacker does land a shell, outbound restrictions from the PHP/Apache worker reduce follow-on staging, callback traffic, and data theft. This is blast-radius reduction, not prevention, and should be in place within 30 days.

Run this on the target WordPress host or an admin jump box with filesystem access to the site directory. Invoke it as sudo bash verify-bookingpress-cve-2026-6960.sh /var/www/html; read access to WordPress files is required, and WP-CLI is optional but helps with a best-effort check for the Signature-field prerequisite.

#!/usr/bin/env bash
# verify-bookingpress-cve-2026-6960.sh
# Purpose: Best-effort verification for CVE-2026-6960 on a WordPress host.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

WP_ROOT="${1:-}"
if [ -z "$WP_ROOT" ]; then
  echo "UNKNOWN - usage: $0 /path/to/wordpress"
  exit 3
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/bookingpress-appointment-booking-pro"
if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN - BookingPress Pro plugin directory not found: $PLUGIN_DIR"
  exit 2
fi

find_version() {
  local v=""
  local candidates=(
    "$PLUGIN_DIR/bookingpress-appointment-booking-pro.php"
    "$PLUGIN_DIR/bookingpress-pro.php"
    "$PLUGIN_DIR/bookingpress.php"
  )

  for f in "${candidates[@]}"; do
    if [ -f "$f" ]; then
      v=$(grep -Ei '^[[:space:]]*Version:[[:space:]]*' "$f" | head -n1 | sed -E 's/^[^:]+:[[:space:]]*//; s/[[:space:]]+$//')
      [ -n "$v" ] && { echo "$v"; return 0; }
    fi
  done

  if [ -f "$PLUGIN_DIR/readme.txt" ]; then
    v=$(grep -Ei '^(Stable tag|Version):[[:space:]]*' "$PLUGIN_DIR/readme.txt" | head -n1 | sed -E 's/^[^:]+:[[:space:]]*//; s/[[:space:]]+$//')
    [ -n "$v" ] && { echo "$v"; return 0; }
  fi

  return 1
}

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

verlt() {
  [ "$1" = "$2" ] && return 1
  verlte "$1" "$2"
}

VERSION="$(find_version || true)"
if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not determine installed BookingPress Pro version"
  exit 2
fi

# Fast path: fixed version or newer.
if ! verlt "$VERSION" "5.7"; then
  echo "PATCHED - BookingPress Pro version $VERSION"
  exit 0
fi

# At this point version is <= 5.6, but exploitability depends on Signature field usage.
# Best-effort check using WP-CLI if available.
SIG_FOUND=0
WPCLI_FOUND=0
if command -v wp >/dev/null 2>&1; then
  WPCLI_FOUND=1
  # Search BookingPress-related options for the string 'signature'.
  # This is heuristic because vendor option names may vary by version.
  QUERY_RESULT=$(wp --path="$WP_ROOT" db query \
    "SELECT option_name FROM $(wp --path='$WP_ROOT' db prefix 2>/dev/null)options WHERE option_name LIKE '%bookingpress%' AND option_value LIKE '%signature%';" \
    --skip-column-names 2>/dev/null || true)
  if [ -n "$QUERY_RESULT" ]; then
    SIG_FOUND=1
  fi
fi

if [ "$SIG_FOUND" -eq 1 ]; then
  echo "VULNERABLE - BookingPress Pro version $VERSION and Signature-related BookingPress config found"
  exit 1
fi

if [ "$WPCLI_FOUND" -eq 1 ]; then
  echo "UNKNOWN - BookingPress Pro version $VERSION is in the vulnerable range, but Signature-field usage was not confirmed by heuristic WP-CLI inspection"
  exit 2
else
  echo "UNKNOWN - BookingPress Pro version $VERSION is in the vulnerable range; install WP-CLI or manually review BookingPress custom fields for Signature usage"
  exit 2
fi

Sources

1. NVD CVE-2026-6960
2. Wordfence advisory for BookingPress Pro <= 5.6
3. BookingPress official changelog
4. BookingPress official custom fields documentation
5. BookingPress official product page
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS project
8. Atomic Edge public PoC analysis