CVE-2026-87071 in Forminator Forms Plugin
Summary
by MITRE • 09/23/2026
The Forminator Forms WordPress plugin before 1.57.2.1 does not restrict which metadata keys a form submission may supply, and does not exclude the keys WordPress reserves for its own use, so unauthenticated visitors submitting a public form that collects post content can attach metadata of their choosing to the post their submission creates.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in Forminator Forms versions prior to 1.57.2.1 represents a critical flaw in input validation and data handling within WordPress plugin architecture. This issue stems from an improper restriction on metadata keys during form submissions, allowing unauthenticated users to inject arbitrary metadata into posts created via public forms. In standard WordPress operations, post meta is used to store additional information about a post that does not fit into the core fields like title or content. However, certain meta keys are reserved by WordPress for internal use, such as those starting with an underscore (e.g., _edit_lock, _wp_old_slug), which control editing states, revisions, and other administrative functions. By failing to filter out these reserved keys, the plugin inadvertently exposes a mechanism through which attackers can manipulate post attributes in ways that bypass normal user permissions.
From a technical perspective, this flaw constitutes an Arbitrary Metadata Injection vulnerability. When a public form is configured to create new posts upon submission, it typically maps form fields to WordPress post data and potentially associated meta values. The security failure occurs because the plugin accepts any key-value pair submitted by the user without verifying whether the keys are safe or reserved for system use. This lack of sanitization allows an attacker to supply metadata that overrides default behaviors or sets specific flags on the newly created post. For instance, if an attacker can set a meta key like _edit_lock, they might interfere with the editing process of other users or administrators. More critically, depending on how subsequent plugins or themes interact with these custom fields, this could lead to privilege escalation scenarios where lower-privileged users gain capabilities typically reserved for authors or editors.
The operational impact of this vulnerability is significant due to its unauthenticated nature and potential for abuse in public-facing environments. Attackers do not need valid credentials to exploit this flaw; they simply need access to a form that creates posts publicly available on the internet. The consequences can range from minor data integrity issues, such as corrupting post metadata which might break site functionality or display incorrect information, to more severe security breaches. If specific meta keys are interpreted by other plugins for authorization checks or feature toggles, an attacker could potentially disable security features, alter visibility settings of posts (e.g., making private content public), or even facilitate further attacks like Cross-Site Scripting if the metadata is rendered unsafely on the frontend without proper escaping. This aligns with CWE-94 Improper Control of Generation of Code ('Code Injection') and CWE-770 Allocation of Resources Without Limits or Throttling, as it allows untrusted input to influence system behavior in unintended ways.
In terms of threat modeling, this vulnerability maps closely to the MITRE ATT&CK technique T1195 Supply Chain Compromise if exploited via a compromised plugin update, but more directly relates to T1078 Valid Accounts when considering how injected metadata might be used to maintain persistence or escalate privileges within the application logic. It also reflects CWE-20 Improper Input Validation, as the core issue is the failure to validate and sanitize user-supplied data against an allowlist of safe keys. The absence of strict filtering mechanisms means that any form field mapped to post meta becomes a potential attack vector for manipulating backend state through frontend inputs.
Mitigation strategies must focus on implementing robust input validation and sanitization protocols within the plugin codebase. Developers should enforce a strict whitelist approach, ensuring that only predefined, safe metadata keys are accepted during form submissions. Any attempt to submit reserved WordPress meta keys or arbitrary custom fields not explicitly allowed by the site administrator should be rejected or sanitized immediately upon receipt. Additionally, implementing capability checks is essential; even if metadata injection were possible, verifying that the user has appropriate permissions for the specific post type and action can mitigate some risks. Upgrading to version 1.57.2.1 or later resolves this issue as it includes patches addressing these validation gaps. Site administrators should also consider auditing their forms to ensure they do not expose unnecessary fields that could be leveraged for such attacks, and regularly update all WordPress plugins to incorporate the latest security fixes provided by vendors.