The Everest Forms Pro plugin for WordPress is vulnerable to Remote Code Execution via PHP Code Injection in…

CVE-2026-3300 is a server-side PHP code injection bug in Everest Forms Pro for WordPress affecting all versions through 1.9.12, fixed in 1.9.13. Per Wordfence and NVD, attacker-controlled values from string-type form fields are concatenated into PHP code and passed to eval() inside the Calculation add-on flow, which can yield unauthenticated remote code execution when a form uses the Complex Calculation feature. The vulnerable condition is not just “plugin installed”; the exposed form has to actually use that calculation path.

The vendor/assigned 9.8 CRITICAL score is technically fair in a lab because this is no-auth, network-reachable RCE with full site compromise. In the field, though, the reachable population is materially narrower: you need the paid Pro plugin, a vulnerable version, and a publicly reachable form wired to Complex Calculation. That friction is real enough to downgrade from CRITICAL to HIGH, but not lower, because once the feature is exposed the attacker gets the whole WordPress box.

Why this verdict

• Downgrade: requires the paid Pro plugin rather than the broader free-plugin population, which materially shrinks the exposed enterprise set.
• Downgrade: requires a specific workflow — a form must be publicly reachable and use the Complex Calculation feature, which is a real deployment filter, not edge-case trivia.
• Still HIGH: no auth and full compromise — if the feature is exposed, the attacker can go straight from internet access to PHP execution and site takeover.

Why not higher?

I am not keeping this at CRITICAL because the attack path is narrower than the vendor CVSS implies in day-to-day enterprise reality. CVSS does not account for the fact that many Everest deployments are basic forms, not public calculator/payment logic backed by the vulnerable path, and I could not validate authoritative active-exploitation evidence.

Why not lower?

This is not MEDIUM because the bug is still unauthenticated remote code execution with server-side execution, not a post-auth admin bug or a local foothold issue. When the prerequisites are met, blast radius is immediate and severe: WordPress compromise, credential theft, persistent backdoor, and possible host pivot.

1. Disable vulnerable calculation forms — If patching cannot happen immediately, take the exploit path away by disabling or unpublishing Everest Forms that use Complex Calculation, especially public quote, pricing, BMI, booking, and payment-style forms. For a HIGH verdict, deploy this compensating control within 30 days, and faster on any internet-facing business-critical site.
2. Apply a virtual patch at the edge — Use a WAF or managed WordPress firewall rule to block suspicious POST bodies hitting Everest form submission endpoints, especially payloads containing PHP metacharacters or formula-breaking strings. This is mitigation, not cure; deploy within 30 days for HIGH, or sooner anywhere public forms are exposed.
3. Hunt for post-exploit persistence — Review WordPress admin users, plugin/theme file integrity, unexpected wp-content/uploads PHP artifacts, and recent changes to forms/plugins. Do this immediately on internet-facing sites because this vulnerability, once hit, gives an attacker everything needed for quiet persistence.
4. Restrict who can reach high-risk forms — Where business allows it, put sensitive calculator/order forms behind authentication, IP allowlists, or temporary geo/rate restrictions. This does not remove the vulnerability, but it cuts the unauthenticated attack surface while you work through patching; for HIGH, enforce within 30 days.

Run this on the target WordPress host from a shell that can access the site files and database via wp-cli. Example: sudo ./check_cve_2026_3300.sh /var/www/html. It needs read access to the WordPress install and enough privilege for wp plugin and wp db query; root is not strictly required if the web app owner account can run wp.

#!/usr/bin/env bash
# check_cve_2026_3300.sh
# Detect likely exposure to CVE-2026-3300 on a WordPress host.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

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

if ! command -v wp >/dev/null 2>&1; then
  echo "UNKNOWN: wp-cli not found"
  exit 2
fi

if [[ ! -f "$WP_PATH/wp-config.php" ]]; then
  echo "UNKNOWN: wp-config.php not found at $WP_PATH"
  exit 2
fi

wp_safe() {
  wp --path="$WP_PATH" --skip-plugins --skip-themes "$@" 2>/dev/null
}

plugin_installed="no"
if wp_safe plugin is-installed everest-forms-pro; then
  plugin_installed="yes"
fi

if [[ "$plugin_installed" != "yes" ]]; then
  echo "PATCHED: Everest Forms Pro not installed"
  exit 0
fi

version="$(wp_safe plugin get everest-forms-pro --field=version || true)"
if [[ -z "$version" ]]; then
  echo "UNKNOWN: unable to determine everest-forms-pro version"
  exit 2
fi

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

if ! version_le "$version" "1.9.12"; then
  echo "PATCHED: everest-forms-pro version $version"
  exit 0
fi

# We know the installed version is vulnerable. Now try to determine whether
# the calculation feature is likely present/exposed.
plugin_list="$(wp --path="$WP_PATH" plugin list --format=csv 2>/dev/null || true)"
calc_plugin_hit="no"
if echo "$plugin_list" | grep -Eiq 'everest.*calc|calc.*everest'; then
  calc_plugin_hit="yes"
fi

# Search WordPress DB content for likely calculation/formula markers.
# This is intentionally heuristic because plugin internals and table names vary.
db_dump="$(wp --path="$WP_PATH" db export - --quiet 2>/dev/null | strings 2>/dev/null | grep -Eio 'enable_calculation|complex calculation|expression_field|formula is valid|calculations addon|if \(\$FIELD_|elseif\(\$FIELD_|endif;' | sort -u || true)"

if [[ "$calc_plugin_hit" == "yes" ]]; then
  echo "VULNERABLE: everest-forms-pro version $version with calculation-related plugin evidence"
  exit 1
fi

if [[ -n "$db_dump" ]]; then
  echo "VULNERABLE: everest-forms-pro version $version with calculation-related data found"
  exit 1
fi

# Vulnerable version present, but we could not prove whether Complex Calculation is enabled.
echo "UNKNOWN: everest-forms-pro version $version is vulnerable by version, but no calculation-feature evidence was found"
exit 2

Sources

1. NVD CVE-2026-3300
2. Wordfence advisory for Everest Forms Pro <= 1.9.12
3. Everest Forms vendor changelog
4. WordPress.org plugin page for Everest Forms
5. Everest Forms documentation: Calculations
6. Patchstack advisory
7. Wordfence weekly report listing CVE-2026-3300
8. SecurityOnline secondary report claiming exploitation