The Divi Form Builder plugin for WordPress is vulnerable to privilege escalation in versions up to

CVE-2026-5118 is an improper privilege-management bug in the WordPress Divi Form Builder plugin. In versions up to and including 5.1.2, the registration flow trusts a user-supplied role value from POST data instead of forcing the configured default registration role. If an attacker can hit the vulnerable form workflow, they can register a new administrator account and take over the site; 5.1.3 changes registration so the configured form role is always enforced.

The vendor's 9.8/CRITICAL rating is technically understandable because successful exploitation is unauthenticated and ends in full WordPress admin. But it overstates the average enterprise risk because not every plugin install is reachable: the attacker still needs a publicly exposed Divi Form Builder registration-capable workflow on an internet-facing site. That exposure gate is real and materially narrows the victim pool, so this lands as HIGH, not blanket-CRITICAL.

Why this verdict

• Down from 9.8: vendor CVSS assumes reachable vulnerable functionality, but real exploitation requires a public Divi Form Builder registration-capable path rather than mere plugin installation.
• Another downgrade: this is a premium/niche WordPress plugin, not a ubiquitous platform service, so the exposed population is meaningfully smaller than a raw internet-RCE-style CVSS suggests.
• Held at HIGH: if the path is exposed, the attacker is unauthenticated and the outcome is administrator account creation, which is operationally equivalent to site takeover and often a short hop to code execution.

Why not higher?

I am not calling this CRITICAL because the attack surface is conditional, not universal. No KEV entry, very low EPSS, and no primary-source proof of mass exploitation mean the fleetwide urgency should be driven by reachability of registration workflows, not by the headline CVSS alone.

Why not lower?

I am not dropping this to MEDIUM because there is no auth barrier once the workflow is exposed. An internet attacker creating a WordPress admin account is a severe control-plane compromise with direct business impact, especially on customer-facing sites, e-commerce content, and any host where admins can install or edit code.

1. Disable unneeded public registration flows — Turn off Divi Form Builder user-registration use cases that are not business-critical, or temporarily remove those pages from public reach. This is the highest-value compensating control because it removes the vulnerable path entirely; for a HIGH finding, deploy within 30 days.
2. Block anonymous access to the vulnerable AJAX action — At the WAF or reverse proxy, challenge or block unauthenticated POSTs to /wp-admin/admin-ajax.php where action=de_fb_ajax_submit_ajax_handler, unless the business explicitly requires it. This is imperfect but useful containment while patching; deploy within 30 days.
3. Hunt for rogue administrator creation — Review WordPress users, audit logs, and database changes for new admin accounts and suspicious role changes starting 2026-05-20 and 2026-05-21. This catches both successful exploitation and earlier testing; deploy within 30 days.
4. Reduce post-compromise blast radius — Disable in-dashboard plugin/theme editing and require stronger authentication controls for admin logons where possible. This will not stop initial account creation, but it can slow the jump from admin access to persistent code execution; deploy within 30 days.

Run this on the WordPress host with filesystem access to the site root or plugin directory. Invoke it as sudo bash verify-cve-2026-5118.sh /var/www/html or point it straight at the plugin dir like sudo bash verify-cve-2026-5118.sh /var/www/html/wp-content/plugins/divi-form-builder; root is not strictly required, but you need read access to the plugin files.

#!/usr/bin/env bash
# verify-cve-2026-5118.sh
# Checks Divi Form Builder version on a WordPress host.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN"
  exit 2
fi

PLUGIN_DIR=""
if [[ -d "$TARGET/wp-content/plugins/divi-form-builder" ]]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/divi-form-builder"
elif [[ -d "$TARGET" && "$(basename "$TARGET")" == "divi-form-builder" ]]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN"
  exit 2
fi

MAIN_FILE=""
for f in "$PLUGIN_DIR"/*.php; do
  [[ -e "$f" ]] || continue
  if grep -qiE '^\s*Plugin Name:\s*Divi Form Builder' "$f" 2>/dev/null; then
    MAIN_FILE="$f"
    break
  fi
done

VERSION=""
if [[ -n "$MAIN_FILE" ]]; then
  VERSION="$(grep -iE '^\s*Version:\s*' "$MAIN_FILE" | head -n1 | sed -E 's/^\s*Version:\s*//I' | tr -d '\r' | xargs || true)"
fi

if [[ -z "$VERSION" && -f "$PLUGIN_DIR/readme.txt" ]]; then
  VERSION="$(grep -iE '^\s*Stable tag:\s*' "$PLUGIN_DIR/readme.txt" | head -n1 | sed -E 's/^\s*Stable tag:\s*//I' | tr -d '\r' | xargs || true)"
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN"
  exit 2
fi

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

if verlte "$VERSION" "5.1.2"; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi

Sources

1. Wordfence advisory
2. Divi Engine changelog
3. Divi Form Builder overview documentation
4. Divi Form Builder form module documentation
5. CISA Known Exploited Vulnerabilities Catalog
6. GitHub public PoC repository
7. CraftedSignal threat brief
8. CVE record URL