Forminator Forms EUVD-2026-85192

Requires the target WordPress site to expose a public Forminator form (plugin before 1.57.2.1) that is configured with post-creation functionality - i.e. a form that collects post content and creates a post from each submission. Only such post-generating forms are affected; ordinary contact/lead forms that do not create posts are not exploitable. No authentication or user interaction beyond a normal form submission is needed (PR:N/UI:N), but the non-default post-submission feature must be enabled, which limits real-world exposure. Impact is confined to injecting attacker-chosen and WordPress-reserved metadata keys onto the created post (low integrity impact).

This is a genuine but limited-impact issue best treated as a low-to-moderate priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3) correctly captures a remotely reachable, low-complexity, unauthenticated flaw whose only impact is a low integrity effect (C:N/A:N) - the attacker can inject arbitrary/reserved metadata onto a WordPress post that their form submission creates, not read data or crash the site. A public exploit reference exists via WPScan, so exploitability is demonstrated, but there is NO EPSS score and NO CISA KEV listing supplied, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals and only the former is present here. The realistic risk is gated by a non-default prerequisite: the site must run a public Forminator form that collects post content and creates posts. Note the 'Information Disclosure' tag conflicts with the CVSS impact metrics (C:N, I:L), which indicate an integrity/data-manipulation issue, not disclosure - treat the tag as mislabeled. Net: a real, credible flaw in a very popular plugin, but bounded impact and conditional exposure keep it below true high-priority status.

An unauthenticated visitor finds a public Forminator form configured to create WordPress posts (a post-submission/front-end posting form) and submits it with extra crafted metadata keys - including keys WordPress reserves internally. Because the plugin does not filter or exclude these keys before saving, the attacker-chosen metadata is attached to the newly created post, letting them manipulate post attributes or internal fields. A public exploit/write-up is available via WPScan.