CVE-2026-12793 · JetFormBuilder ≤ 3.6.2 Unauthenticated Privilege Escalation via…

01 · The Real Story

Someone left the master-key blank on a front door anyone can find on Google

CVE-2026-12793 is an unauthenticated privilege escalation in JetFormBuilder ≤ 3.6.2, a WordPress form-builder plugin with 80,000+ active installations. The plugin fails to verify that the _jet_engine_booking_form_id parameter actually references a legitimate JetFormBuilder post type before parsing the referenced post's content as form schema and executing its Advanced Validation server-side callback. An unauthenticated attacker sends a single crafted AJAX POST to ?jet_form_builder_submit=submit&method=ajax with a spoofed form ID, triggering the Register User action (wp_insert_user) and creating a new administrator-level account on the target WordPress site. From there, the attacker uploads a webshell via the plugin editor and owns the underlying server. No credentials, no user interaction, no special configuration on the target — just a live install of the plugin.

The vendor severity of CRITICAL / 9.8 is accurate and, if anything, understates operational urgency. Every precondition in the CVSS vector — network-reachable, low complexity, no privileges, no interaction — maps directly to real-world conditions for WordPress sites, which are internet-facing by definition. Unlike many 9.8s where a contrived lab setup is needed, this one fires against a default install. Two public PoC repositories (murrez, abraxas) lower the skill bar to script-kiddie level. The only thing preventing a KEV listing today is that mass campaigns haven't been *confirmed* yet — but the ingredients are all present.

"Unauthenticated admin creation on any JetFormBuilder site. Patch now or lose the site."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Fingerprint the plugin

The attacker fetches /wp-content/plugins/jetformbuilder/readme.txt or probes for data-form-id attributes on public pages. JetFormBuilder's readme.txt includes a Stable tag: line revealing the exact version. Bulk scanning via tools like WPScan, Nuclei, or custom Python scrapers makes this trivial at scale.

Conditions required:

Target runs WordPress with JetFormBuilder ≤ 3.6.2 active

Where this breaks in practice:

Only ~80,000 sites worldwide run the plugin, limiting the target pool compared to plugins like Contact Form 7 (5M+)

Detection/coverage: WPScan, Nuclei template (community), or WAF log analysis for readme.txt probes

STEP 02

Craft the malicious AJAX request

The attacker constructs a POST to /?jet_form_builder_submit=submit&method=ajax with a spoofed _jet_engine_booking_form_id pointing at any existing WordPress post ID (not necessarily a JetFormBuilder form). The plugin blindly parses that post's content as a form schema. The request includes attacker-chosen user_login, user_email, user_pass, and role=administrator fields. Public PoC tools from murrez and abraxas on GitHub automate this entirely.

Conditions required:

Knowledge of any valid post ID on the target (post ID 1 exists on nearly every WordPress install)

Where this breaks in practice:

None — post ID 1 ("Hello world!") exists on virtually every WordPress site

Detection/coverage: WAF rules matching _jet_engine_booking_form_id in POST body; Wordfence firewall rule (if updated)

STEP 03

Trigger the Register User action

The plugin's form-processing pipeline accepts the spoofed form ID, parses the referenced post content as schema, and reaches the Advanced Validation server-side callback. Because no type-check guards the pipeline entry, the callback executes wp_insert_user() with the attacker's supplied credentials and role. A new administrator account is created in the WordPress wp_users table instantly.

Conditions required:

JetFormBuilder ≤ 3.6.2 is active (no additional configuration required)

Where this breaks in practice:

None — this is a default-config vulnerability

Detection/coverage: WordPress audit log plugins (WP Activity Log, Simple History) will record the user creation event

STEP 04

Log in as administrator

The attacker authenticates with the newly created admin credentials at /wp-login.php. Full WordPress admin dashboard access is achieved, including plugin/theme management, user management, database access via plugins, and file editing.

Conditions required:

WordPress login endpoint is accessible (default)

Where this breaks in practice:

MFA plugins on admin accounts would not help — the new account was created without MFA enrollment

Detection/coverage: Login audit logs; anomalous admin account creation alerts

STEP 05

Achieve RCE via webshell upload

The attacker navigates to Plugins → Plugin Editor (or Appearance → Theme Editor) and injects PHP webshell code into any .php file, or uploads a malicious plugin ZIP. Alternatively, they install a file-manager plugin. The webshell executes as the web server user (www-data, apache, nginx), granting OS-level command execution on the host.

Conditions required:

WordPress admin access (achieved in step 4)
Plugin/theme file editing not disabled via DISALLOW_FILE_EDIT

Where this breaks in practice:

Hardened installations with DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS in wp-config.php block this path, but most sites do not set these

Detection/coverage: File integrity monitoring (OSSEC, Wazuh, Tripwire); EDR on the web server; WAF blocking webshell patterns

03 · Compensating Control

CRITICAL 9.8→LOW 2.0

SEVERITY REDUCED

Block the _jet_engine_booking_form_id parameter at the WAF — Deploy a WAF rule (Cloudflare, AWS WAF, ModSecurity, Wordfence) that blocks or sanitizes any POST request containing _jet_engine_booking_form_id with a value that doesn't match a known JetFormBuilder form ID. This surgically breaks step 2 of the attack chain. Per the noisgate mitigation SLA for CRITICAL, deploy within 3 days.

CRITICAL 9.8→IGNORE 0.0

SEVERITY REDUCED

Update JetFormBuilder to ≥ 3.6.6.1 immediately — The definitive fix. Version 3.6.2.1 introduced Block_Helper::is_valid_form_post() to restrict accepted post types. Version 3.6.6.1 includes additional hardening for SSR validation, CSRF, CAPTCHA, and XSS. Per the noisgate remediation SLA for CRITICAL, complete within 90 days — but given the trivial exploit, treat this as an emergency patch and deploy within hours to days.

CRITICAL 9.8→HIGH 8.0

SEVERITY REDUCED

Enable DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS in wp-config.php — Add define('DISALLOW_FILE_EDIT', true); and define('DISALLOW_FILE_MODS', true); to wp-config.php. This prevents an attacker who gains admin access from editing PHP files or uploading plugins through the dashboard, breaking the admin-to-RCE escalation path (step 5). Does NOT prevent admin account creation or site-level takeover — only limits the blast radius to WordPress-layer damage.

CRITICAL 9.8→CRITICAL 9.8

Audit and remove rogue administrator accounts — Immediately query wp_users and wp_usermeta for any administrator accounts created after 2026-09-16 (disclosure date). Use WP-CLI: wp user list --role=administrator --fields=ID,user_login,user_registered. Remove any unrecognized accounts. If rogue admins are found, assume full compromise: rotate all credentials, check for webshells, and rebuild from backup.

CRITICAL 9.8→LOW 2.0

SEVERITY REDUCED

Deploy WordPress-aware WAF with virtual patching — Wordfence Premium and Patchstack include virtual patch rules for CVE-2026-12793. These rules intercept the malicious AJAX request before it reaches the plugin. Deploy within 3 days per noisgate mitigation SLA.

What doesn't work

MFA on WordPress admin accounts — does not help because the attacker *creates* a new admin account without MFA enrollment; MFA only protects existing accounts
IP allowlisting on wp-login.php — the exploit uses the AJAX endpoint (/?jet_form_builder_submit=submit), not wp-login.php; the account creation happens before any login
Disabling XML-RPC — the attack uses the standard WordPress AJAX/form submission pipeline, not XML-RPC
Generic rate limiting — a single request is sufficient to create the admin account; rate limiting provides no protection against a one-shot exploit

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No confirmed mass campaigns as of 2026-10-09. Not on CISA KEV. However, the trivial attack path and public PoCs make opportunistic scanning imminent. No GreyNoise tags observed yet for this CVE.
Proof-of-Concept Availability	Two public GitHub PoC repositories: murrez/CVE-2026-12793 (unauth Register User / admin creation) and abraxas/CVE-2026-12793 (unauthorized RCE framing). Both provide Python exploit scripts. Also indexed on Sploitus. Lowering the bar to script-kiddie level.
EPSS Score	0.00517 (0.517%) — roughly 75th–80th percentile. Indicates moderate but growing probability of exploitation in the next 30 days. For a 23-day-old CVE with public PoCs, this is likely to climb.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — Network-reachable, low complexity, no authentication, no user interaction, full confidentiality/integrity/availability impact. Every metric is at its worst-case value except Scope (Unchanged). This is the textbook worst-case for a web application vulnerability.
Affected Versions	JetFormBuilder ≤ 3.6.2 (all versions). The plugin has been available since 2021.
Fixed Versions	3.6.2.1 (minimum fix). Current latest is 3.6.6.1 which includes additional hardening (SSR validation, CSRF, CAPTCHA). Recommended target: latest release.
Install Base / Exposure	80,000+ active WordPress installations per wordpress.org. WordPress sites are internet-facing by nature. Any site running JetFormBuilder ≤ 3.6.2 is directly exploitable without authentication.
Disclosure Timeline	Disclosed 2026-09-16 via Wordfence (CNA). Wordfence advisory ID: `a61b2ecc-d4e1-4e71-9187-ddc3d3616a29`. WordPress Plugin Repository changeset #3575346.
Reporter / Credit	Reported by daroo via the Wordfence Bug Bounty Program. Wordfence acted as CNA and assigned the CVE.
Scanner Coverage	WPScan has coverage. Nuclei community templates available. Wordfence premium firewall includes a virtual patch rule. Patchstack database includes this CVE.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

Zero-friction attack chain: The exploit requires no authentication, no user interaction, no special target configuration, and works against a default JetFormBuilder install. Post ID 1 exists on every WordPress site, giving the attacker all they need to spoof the form reference.
Public PoCs lower the bar to zero: Two GitHub repositories (murrez, abraxas) provide turnkey Python exploit scripts. Sploitus indexes them. Any attacker with curl and 30 seconds can create an admin account on a vulnerable site.
Internet-facing by definition: WordPress sites are designed to be publicly accessible. Unlike vulnerabilities requiring internal network access or VPN, every affected site is reachable from the open internet. No friction from network segmentation.
Admin → RCE is a one-click hop: WordPress admin access trivially converts to server-level RCE via plugin/theme editor or ZIP upload. This makes the impact equivalent to unauthenticated remote code execution.
Role multiplier: WordPress sites occupy the *typical* role (company websites, marketing, small e-commerce) and occasionally *high-value* roles (e-commerce with payment data via WooCommerce, membership portals with PII, corporate intranets). JetFormBuilder is a form plugin, not a canonical high-value-role component (not AD, not hypervisor, not CI/CD), so the deployment-role floor does not force a CRITICAL verdict — but the zero-friction, unauthenticated, internet-facing RCE-equivalent chain justifies CRITICAL on its own merits. For the ~80K sites running this plugin, compromise means full site takeover and potential lateral movement into hosting infrastructure.
EPSS trajectory: At 0.517% just 23 days post-disclosure with public PoCs, this score is likely to rise. The combination of PoC availability, trivial exploitation, and internet-facing targets historically precedes mass scanning campaigns within 4-6 weeks of disclosure.

Why not higher?

A 9.8 is already effectively the ceiling for a web application vulnerability with Scope:Unchanged. The only way to reach 10.0 would be Scope:Changed (impacting resources beyond the vulnerable component's authorization scope), which doesn't technically apply here since the WordPress application boundary contains the initial exploit — even though RCE extends impact to the host OS.

Why not lower?

Downgrading would require meaningful friction in the attack chain, and there is none. The 80K install base is small relative to WordPress's ecosystem, but for any organization running JetFormBuilder, 100% of their instances are exploitable with zero prerequisites. No authentication barrier, no complex configuration dependency, no race condition, no memory corruption reliability issues. Every mitigating factor that typically justifies a downgrade — internal-only exposure, authentication requirements, non-default configs — is absent here.

06 · Verification

Crowdsourced verification payload.

Run this script on any host that can reach the target WordPress site over HTTPS. Invoke with: bash check_cve_2026_12793.sh https://example.com. No special privileges required — it only reads the plugin's readme.txt to determine the installed version.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_12793.sh — CVE-2026-12793 JetFormBuilder version checker
# Usage: bash check_cve_2026_12793.sh <wordpress_url>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <wordpress_url>"
  echo "Example: $0 https://example.com"
  exit 2
fi

BASE_URL="${1%/}"
README_URL="${BASE_URL}/wp-content/plugins/jetformbuilder/readme.txt"

echo "[*] Checking JetFormBuilder version at: ${README_URL}"

HTTP_RESPONSE=$(curl -s -o /tmp/jfb_readme.txt -w "%{http_code}" --max-time 10 "${README_URL}" 2>/dev/null || true)

if [ "${HTTP_RESPONSE}" != "200" ]; then
  echo "[?] UNKNOWN — Could not retrieve readme.txt (HTTP ${HTTP_RESPONSE:-timeout})"
  echo "    Plugin may not be installed, or readme.txt is blocked."
  echo "    Manually verify: wp plugin list --status=active | grep jetformbuilder"
  exit 2
fi

VERSION=$(grep -i '^Stable tag:' /tmp/jfb_readme.txt | head -1 | sed 's/[Ss]table tag:[[:space:]]*//' | tr -d '[:space:]')
rm -f /tmp/jfb_readme.txt

if [ -z "${VERSION}" ]; then
  echo "[?] UNKNOWN — readme.txt found but no Stable tag detected."
  exit 2
fi

echo "[*] Detected JetFormBuilder version: ${VERSION}"

# Version comparison: vulnerable if <= 3.6.2
# Convert version to comparable format
version_lte() {
  [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

FIXED_VERSION="3.6.2.1"

if version_lte "${VERSION}" "3.6.2"; then
  echo "[!] VULNERABLE — JetFormBuilder ${VERSION} is affected by CVE-2026-12793"
  echo "    Unauthenticated admin account creation via spoofed form ID."
  echo "    Update to >= ${FIXED_VERSION} immediately."
  exit 1
else
  echo "[+] PATCHED — JetFormBuilder ${VERSION} is not affected by CVE-2026-12793"
  echo "    Fixed version: >= ${FIXED_VERSION}"
  exit 0
fi