Ninja Forms CVE-2026-65050

Exploitation requires an authenticated WordPress account with at least Author-level privileges to embed the ninja-forms/submissions-table Gutenberg block, and the site must run the block editor with Ninja Forms 3.14.8 or earlier and have stored submissions for the targeted formID. The block must be placed on a published (publicly reachable) post so that unauthenticated visitors trigger the vulnerable render callback and receive the injected signed bearer token. Limiting factors: the initial block placement is gated by Author (PR:L) access, so a site that does not grant Author roles to untrusted users, disables the block editor, or has no stored submissions for the referenced form significantly reduces exposure; the actual data disclosure to visitors, however, needs no authentication once the block is live.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, base 7.1) captures the shape well: network reachable, low complexity, no user interaction, but requiring low privileges (PR:L) to plant the block, with high confidentiality impact and no integrity or availability impact. There are two distinct actors - an Author-level insider (or an attacker who has obtained Author credentials) who plants the block, and then any fully unauthenticated visitor who harvests the leaked token - which makes the *disclosure* itself effectively unauthenticated once the block is published. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no signal of active, widespread exploitation; no public POC was identified either. The realistic risk is a targeted data-disclosure/insider or compromised-low-privilege-account scenario rather than mass automated exploitation, but the confidentiality impact on PII is genuine and the precondition (any Author account) is low on many multi-author WordPress sites. Priority should be driven by whether the site grants Author roles broadly and stores sensitive submissions.

An attacker who holds or has phished an Author-level WordPress account publishes an innocuous-looking post containing the ninja-forms/submissions-table block set to the formID of a sensitive contact or registration form. When any unauthenticated visitor loads that public post, their browser receives the signed bearer token via wp_localize_script; the attacker (or an automated scraper) reads that token from the page source and replays it against the REST submissions endpoint to exfiltrate every stored submission's field values, including names, emails, and phone numbers. No public POC was identified at time of analysis, and the low attack complexity means the token harvest and replay are trivial to script.