JetFormBuilder CVE-2026-12793: Update to 3.6.5.3 — Unauthenticated Admin Account Creation

JetFormBuilder — Dynamic Blocks Form Builder contains a flaw that lets an entirely unauthenticated attacker create a new administrator-level user account. This is CVE-2026-12793. WordPress.org reports roughly 80,000 active installs.

The plugin does not verify that a submitted form ID actually belongs to a JetFormBuilder form. Point it at some other post and the plugin parses that post's content as a form schema and executes the Advanced Validation server-side callback defined there.

This CVE itself is fixed in 3.6.2.1. But stopping there is not enough. Five other vulnerabilities in this plugin were published earlier in September, and clearing all six requires 3.6.5.2 or later. The current release is 3.6.5.3 (14 September 2026), which hardens the same callback machinery again, so 3.6.5.3 is the version to aim for. The list is below.

Do this now

• ✓Check whether you are affected. In WP Admin → Plugins, find JetFormBuilder — Dynamic Blocks Form Builder and read its version. This CVE lists 3.6.2 and earlier as affected, and is fixed in 3.6.2.1.
• ✓Update to 3.6.5.3. That is the current release, published 14 September 2026. Apply it from Plugins → Update. 3.6.2.1 is enough for this CVE alone, but the other five September CVEs run to 3.6.5.2 — the next section explains why you should not stop short.
• ✓Updating does not remove accounts that were already created. It closes the entry point, nothing more. Open Users and confirm there is no administrator you do not recognise.
• ✓Update it even if it is deactivated. Deactivated plugins still have their files on disk. If you no longer use it, delete it rather than update it.
• ✓The CVE record lists no workaround. No configuration-level mitigation is published, so treat updating as the only option.

Where this score comes from. The 9.8 was assigned by Wordfence, the CNA, using CVSS v3.1. The vector is `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` and the weakness type is CWE-269 (Improper Privilege Management).

As of 16 September 2026 the NVD entry is still in "Received" status — NIST has not completed its own analysis and has published no independent score. The 9.8 shown on NVD is Wordfence's value passed through. No score has been published under any other CVSS version.

The CVE record's timeline: discovered 11 June 2026, vendor notified 20 June 2026, disclosed 15 September 2026, credited to "daroo". Roughly three months passed between the report and disclosure, so fixed builds were already shipping when this became public.

Six CVEs in September alone — 3.6.3 is not the answer

This is the part worth your attention. If you pick your target version from this CVE alone, you will leave holes open.

Counting this one, six JetFormBuilder vulnerabilities were published in September 2026, by three different CNAs, with different affected ranges.

• ▸CVE-2026-12793 (published 16 Sep / CVSS v3.1 9.8 CRITICAL / Wordfence) — this article. 3.6.2 and earlier. Unauthenticated administrator account creation.
• ▸CVE-2026-84817 (published 8 Sep / CVSS v3.1 7.1 HIGH / Patchstack) — 3.6.5.1 and earlier. Unauthenticated cross-site scripting. The CVE record explicitly marks 3.6.5.2 as unaffected.
• ▸CVE-2026-19858 (published 5 Sep / CVSS v3.1 7.5 HIGH / WPScan) — before 3.6.5.2. Unauthenticated disclosure of password hashes and arbitrary metadata via Dynamic Preset.
• ▸CVE-2026-19859 (published 6 Sep / CVSS v3.1 6.5 MEDIUM / WPScan) — before 3.6.5.2. A request parameter is not sanitised.
• ▸CVE-2026-19862 (published 6 Sep / CVSS v3.1 4.8 MEDIUM / WPScan) — before 3.6.5.2. Line breaks are not validated or stripped.
• ▸CVE-2026-19861 (published 5 Sep / CVSS v3.1 4.7 MEDIUM / WPScan) — before 3.6.5.2.

Five of the six require 3.6.5.2 or later. Update to 3.6.3 or 3.6.4 on the strength of CVE-2026-12793 alone and you are still exposed to CVE-2026-19858 (7.5 HIGH), which leaks password hashes to unauthenticated callers.

On top of that, 3.6.5.3 (14 September 2026) is described in the changelog as "Secure SSR callbacks with admin-managed registry" — another pass over the same server-side callback machinery this CVE abuses.

The lowest version that covers all six is 3.6.5.2. Beyond that, 3.6.5.3 is the current release and tightens the same callback path again, so 3.6.5.3 is the sensible target.

The fix is 3.6.2.1 — and an SVN revision proves it

The CVE record never says "fixed in X." It gives an affected range — "3.6.2 and earlier" — plus a default status of unaffected for everything else. Read literally, that already places 3.6.2.1 and later outside the range.

That reading can be confirmed independently. The CVE record cites one code reference: changeset 3575346 in the official WordPress repository. WordPress.org plugins live in Subversion, and you can list a directory as it stood at a specific revision. So compare the tag list either side of that changeset.

At revision 3575345 the newest 3.6.x tag is 3.6.2; at 3575346 the tag 3.6.2.1 appears. In other words, the changeset this CVE points at is the 3.6.2.1 release itself — consistent with the affected range.

So the fix for this CVE shipped in 3.6.2.1. The changelog entries for 3.6.2.2 ("SSR validation privilege escalation hardening") and 3.6.5.3 ("Secure SSR callbacks with admin-managed registry") read naturally as later hardening of the same area, not as the original fix.

For completeness: the text of the Wordfence advisory and the trac diff itself could not be retrieved — both return bot challenges (HTTP 202 / 403) to automated requests. The conclusion above rests only on primary sources: the CVE record's version range and a revision comparison against the official WordPress SVN.

Checking whether you were already hit

The flaw creates administrators without authentication, so the thing to look for is an administrator you did not create. With WP-CLI you can list them with registration dates.

# List administrator accounts with their registration dates
wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered

# Newest registrations first
wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered \
  --orderby=registered --order=DESC

From the dashboard alone, open Users → All Users and count the rows whose role is Administrator. If one looks unfamiliar, record the username, email address and registration date before deleting it. You will want them if this turns into an investigation.

If you go to the logs, the parameter named in the CVE title, `_jet_engine_booking_form_id`, is the obvious string to search for. Two traps here.

First, standard Apache and Nginx access logs do not record POST bodies. They record the request line (method, path, query string) and headers. Form submissions travel in the POST body, so grepping a standard access log will return nothing even if the site was attacked. Only logs that retain request bodies — a WAF, an audit log, a reverse proxy configured to capture bodies — can answer this question.

Second, a hit is not proof of compromise. Sites that legitimately use JetEngine booking forms record the same parameter during ordinary use.

So neither a hit nor a miss settles anything. The administrator list is the primary check; treat logs as supporting evidence only.

• ✓List the administrator accounts and look for ones you do not recognise. Pay particular attention to anything registered on or after 15 September 2026, the disclosure date.
• ✓If you find one, document it before removing it — username, email address, registration timestamp.
• ✓A rogue administrator is the entry point, not the whole story. Assume further access and check posts, pages, theme files and the uploads directory for files you did not put there.
• ✓Rotate every administrator password and end existing sessions. Each WordPress profile page has a "Log Out Everywhere Else" button.

KEV and JVN status as of 16 September 2026

This CVE is not in CISA's Known Exploited Vulnerabilities catalog — the version checked was 2026.09.14. It is also absent from Japan's JVN iPedia (zero results for JetFormBuilder).

Neither absence means the issue is minor. KEV lists vulnerabilities with confirmed in-the-wild exploitation, and a WordPress plugin flaw published hours ago is not going to appear there yet. JVN registration lags similarly.

Disclosure was in the early hours of 16 September Japan time. Plugin vulnerabilities typically draw mass scanning once the details circulate, so the window before exploitation reports appear is the calmest time to patch, not a reason to wait.

Sources used

• ▸CVE ID, score, affected range, CWE, timeline: the CVE record on CVE.org (CNA: Wordfence) and the NVD page, opened and cross-checked against each other.
• ▸That the fix is 3.6.2.1: the CVE record's affected range, plus a comparison of the tag listing at revisions 3575345 and 3575346 in the official WordPress SVN (`plugins.svn.wordpress.org`), which shows that changeset creating the 3.6.2.1 tag.
• ▸Current version and changelog: the official WordPress.org plugin API (`api.wordpress.org`) — version 3.6.5.3, updated 14 September 2026, about 80,000 active installs.
• ▸The other five September CVEs: each CVE record plus its NVD page. Affected ranges are quoted as those records state them.
• ▸What could not be checked: the body of the Wordfence advisory and the trac diff itself, both of which return bot challenges. The SVN comparison above was sufficient to identify the fixed version without them.