Hello,

I’m reporting a security issue in your WordPress plugin “Formidable PRO2PDF” (slug
formidablepro-2-pdf), confirmed on the current release 3.24. I’m sending this privately and have
not published it anywhere. If you issue a fix or advisory, I’d appreciate credit to “Artus KG”.

Summary
——-
A signed PDF download key that authorizes one Formidable entry/layout can be silently reused to
extract a *different* entry through a *different* layout. An unauthenticated visitor who can see any
published [formidable-download] link can therefore read the PDF-mapped field data of other users’
Formidable entries. This is a broken object-level authorization (BOLA / IDOR) issue disclosing other
users’ submitted form data. It is not the previously-patched Subscriber+ SQLi (<= 3.10); it is a
separate, currently-unpatched path.

Affected version
—————-
Formidable PRO2PDF <= 3.24 (latest release; tested on 3.24). No release through 3.24 closes this gap.

Precondition and scope
———————-
The attacker is unauthenticated, but the site must expose at least one published [formidable-download]
page (an intended public download link). A clean activation creates no such page, so this affects
sites that use the plugin’s public-download feature — not every install. No login and no nonce are
required to perform the rebind.

Root cause
———-
1. The public [formidable-download] shortcode signs the original GET dataset/form/layout
tuple with a MAC and puts it in the download URL (formidable-shortcode.php:111).
2. download.php validates that tuple MAC, then calls wpfx_admin() (download.php:18).
3. wpfx_admin() decodes an uploaded postdata JSON payload and overwrites wpfx_dataset and
wpfx_layout in POST/REQUEST (fpropdf.php:947).
4. The PDF-generation branch then consumes the overwritten dataset/layout **without recomputing or
re-validating the MAC** (fpropdf.php:1136, fpropdf.php:1174), so wpfx_extract() loads the
attacker-selected entry’s fields (fpropdf.php:552).

The MAC authorizes tuple A but the code acts on attacker-supplied tuple B.

Reproduction (summary)
———————-
In a local lab (WordPress + Formidable Pro + PRO2PDF 3.24, default settings with security enabled):
1. As an unauthenticated visitor, open a published download page and take the source entry’s signed
download URL (valid MAC for the source entry/layout).
2. Replay that exact URL, unchanged MAC, but attach a postdata payload whose JSON selects a
different (victim) entry id and a different layout id.
3. The tuple MAC still validates; postdata overwrites the dataset/layout; generation proceeds on the
victim entry/layout.
4. Result: the victim entry’s private field data (in my test, a private email marker on victim entry
99102 through layout 99131) was extracted using a key that only authorized the unrelated source
entry. A request with a missing/altered MAC is correctly rejected with “The secret key for this
form is not valid.” before any postdata handling — so the MAC gate works; the flaw is the absent
re-check after the overwrite.

I can share the exact scripted PoC and evidence privately on request.

Impact
——
Unauthenticated disclosure of other users’ Formidable form-entry data (potential PII) mapped into
PDFs, by rebinding a public download key to arbitrary entry/layout ids. No integrity or availability
impact was demonstrated or claimed. A defensible rating is CVSS 3.1 5.9 (Medium),
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — AC:H because it depends on a published download link existing.

Suggested fix
————-
Re-bind authorization to the data actually used for generation: after postdata overwrites
wpfx_dataset/wpfx_layout, recompute and re-validate the tuple MAC against the *final* dataset/
layout before calling wpfx_readlayout()/wpfx_extract(); or refuse to let postdata change the
dataset/layout that the signed key authorized (treat the signed tuple as authoritative and ignore any
conflicting postdata selection). Ensuring the MAC covers the effective, post-overwrite tuple closes
the rebind.

I’m happy to coordinate on timing and to confirm the fix against my PoC. Could you let me know your
expected remediation timeline and whether you’ll request a CVE, so I can align public disclosure with
your fix?

Best regards,
Artus KG