Gravity Bookings <= 2

CVE-2026-1719 is an unauthenticated SQL injection in the commercial WordPress plugin Gravity Bookings Premium (gf-bookings-premium) affecting versions up to and including 2.5.9. Wordfence and Patchstack both say the bug sits in handling of the category_id parameter and allows remote attackers to append SQL to an existing query, with the practical outcome being database data disclosure rather than clean code execution. Wordfence lists 2.6 as the patched release, and NVD shows the record as published on 2026-05-06.

The vendor/CNA HIGH 7.5 rating is technically defensible in a vacuum because it is network-reachable and pre-auth. In the real world, though, this is a niche premium WordPress booking add-on, there is no KEV listing, the supplied EPSS is only 0.00084, and the only public exploit material I found is a metadata-based PoC/WAF rule writeup rather than broad in-the-wild tradecraft. That combination pushes this down to MEDIUM for enterprise patch scheduling.

Why this verdict

• Downgrade for narrow population: this is a premium niche WordPress booking add-on, not WordPress core or a mass-market plugin, so the exposed population is much smaller than the CVSS baseline assumes.
• Downgrade for low threat pressure: EPSS 0.00084, no KEV, and no solid reports of active campaigns materially reduce Monday-morning urgency.
• Partial impact only: the published vector claims confidentiality impact without integrity or availability impact, which matters when converting bug severity into patch priority.
• Some modern controls help: WAFs and WordPress security layers are unusually well-suited to stopping noisy SQLi against admin-ajax.php, especially once signatures exist.
• Still not LOW: the attack is still unauthenticated and internet-reachable on vulnerable sites, so any organization actually running this plugin on a public booking flow should treat it as a legitimate external-app risk.

Why not higher?

A higher bucket would require a bigger real-world blast radius or stronger threat evidence. We do not have that here: no KEV, no observed exploitation, a very low EPSS signal, and a likely small install base for this product family. The vendor's 7.5 reflects the technical shape of the bug, but not the scarcity of likely targets.

Why not lower?

This is still pre-auth SQLi against a public web application component, which means a vulnerable exposed site can leak database content without prior compromise. Even if the affected population is small, the organizations that do run it on internet-facing booking pages are carrying genuine external attack surface.

1. Block SQLi patterns on admin-ajax.php — Deploy or tune WAF rules to inspect category_id and related booking parameters for SQL metacharacters, UNION/select, boolean/time-based payloads, and abnormal POST bodies. For a MEDIUM verdict there is no noisgate mitigation SLA; do this as normal web hardening if patching is not immediate.
2. Reduce public reachability of booking actions — If the booking workflow is not required on the public internet, move it behind access control, IP allowlists, or a reverse-proxy rule that only exposes the minimum endpoints. There is no mitigation SLA — go straight to the 365-day remediation window, but exposed internet forms are where this CVE matters.
3. Turn on WordPress security telemetry — Log and alert on repeated hits to wp-admin/admin-ajax.php, especially requests carrying category_id, SQL keywords, long encoded strings, or timing anomalies. This helps catch opportunistic scanning while you validate whether the plugin is present.
4. Constrain database and secret fallout — Verify the WordPress database account is not over-privileged and rotate any plugin/API secrets stored in options tables if you suspect prior exposure. This does not remove the vulnerability, but it cuts the value of successful data extraction.

Run this on the target WordPress host with read access to the WordPress install directory. Invoke it as sudo bash check_gf_bookings.sh /var/www/html; root is not strictly required, but you need permission to read plugin files under wp-content/plugins.

#!/usr/bin/env bash
# check_gf_bookings.sh
# Detect vulnerable Gravity Bookings Premium versions on a WordPress host.
# Usage: bash check_gf_bookings.sh /path/to/wordpress
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/gf-bookings-premium"
if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
  exit 2
fi

version=""
files=(
  "$PLUGIN_DIR/gf-bookings-premium.php"
  "$PLUGIN_DIR/gravity-bookings.php"
  "$PLUGIN_DIR/gravity-booking.php"
  "$PLUGIN_DIR/readme.txt"
)

extract_version() {
  local f="$1"
  if [[ ! -r "$f" ]]; then
    return 1
  fi

  local v
  v=$(grep -Eim1 '^[[:space:]]*(Version:|Stable tag:)' "$f" 2>/dev/null | sed -E 's/^[[:space:]]*(Version:|Stable tag:)[[:space:]]*//I' | tr -d '\r')
  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi

  v=$(grep -Eom1 "([0-9]+\.){1,3}[0-9]+" "$f" 2>/dev/null | head -n1 | tr -d '\r')
  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi

  return 1
}

for f in "${files[@]}"; do
  if v=$(extract_version "$f"); then
    version="$v"
    src="$f"
    break
  fi
done

if [[ -z "$version" ]]; then
  echo "UNKNOWN - unable to determine plugin version from $PLUGIN_DIR"
  exit 2
fi

# Normalize version by stripping non-version suffixes, e.g. 2.6-beta -> 2.6
norm=$(echo "$version" | grep -Eom1 '([0-9]+\.){1,3}[0-9]+')
if [[ -z "$norm" ]]; then
  echo "UNKNOWN - extracted unreadable version: $version"
  exit 2
fi

if [[ "$norm" == "2.6" ]] || [[ "$norm" == "2.6.0" ]]; then
  echo "PATCHED - Gravity Bookings Premium version $version detected from $src"
  exit 0
fi

if dpkg --compare-versions "$norm" le "2.5.9" 2>/dev/null; then
  echo "VULNERABLE - Gravity Bookings Premium version $version detected from $src"
  exit 1
fi

# Fallback for systems without dpkg semantics or unusual future versions
if printf '%s\n%s\n' "$norm" "2.5.9" | sort -V -C; then
  echo "VULNERABLE - Gravity Bookings Premium version $version detected from $src"
  exit 1
fi

if printf '%s\n%s\n' "2.6" "$norm" | sort -V -C; then
  echo "PATCHED - Gravity Bookings Premium version $version detected from $src"
  exit 0
fi

echo "UNKNOWN - version $version detected from $src but could not be classified confidently"
exit 2

Sources

1. Wordfence vulnerability entry
2. Patchstack database entry
3. NVD record
4. OpenCVE record with CNA timeline and CISA ADP enrichment
5. Atomic Edge metadata-based PoC/WAF writeup
6. Vendor changelog/documentation
7. WordPress.org related Gravity Booking plugin page
8. CISA Known Exploited Vulnerabilities Catalog