CVE-2026-78151 in FormLayer Plugin
Summary
by MITRE • 09/02/2026
The FormLayer WordPress plugin before 1.0.9 does not perform any authorization check before returning a form's full stored configuration in the response to its public submission handler, allowing unauthenticated users to disclose notification recipient addresses, confirmation redirect targets and integration settings, including those of unpublished forms.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in FormLayer WordPress plugin versions prior to 1.0.9 represents a critical failure in access control mechanisms within the application's public-facing endpoints. Specifically, the flaw resides in the handler responsible for processing form submissions or retrieving configuration data associated with those forms. In a secure architecture, any operation that exposes sensitive system state or internal configuration must be preceded by rigorous authorization checks to ensure the requesting entity possesses the necessary privileges. However, this implementation fails to validate whether the user initiating the request is authenticated or holds administrative rights before returning the complete stored configuration of a form. This oversight allows unauthenticated actors to interact with the endpoint as if they were authorized administrators, effectively bypassing security boundaries that are intended to restrict access to sensitive data.
From a technical perspective, this issue classifies under CWE-284 Improper Access Control and more specifically aligns with CWE-601 URL Redirection to Untrusted Site 'Open Redirect' when considering the exposure of redirect targets, though the primary vector is information disclosure via improper authorization checks on API endpoints. The attacker can exploit this by sending crafted HTTP requests to the public submission handler without providing valid credentials or session tokens. Because the server does not verify the identity or permission level of the requester before serializing and returning the form's configuration object, it inadvertently leaks a comprehensive snapshot of how that specific form is configured. This includes sensitive details such as notification recipient email addresses, which may contain personal information subject to privacy regulations like GDPR or CCPA, confirmation redirect URLs that could reveal internal infrastructure paths, and integration settings for third-party services.
The operational impact of this vulnerability extends beyond simple data leakage. The disclosure of notification recipient addresses provides attackers with a validated list of active user emails associated with the website's contact forms or lead generation mechanisms. This information is highly valuable for targeted phishing campaigns, such as spear-phishing attacks aimed at compromising administrative accounts or harvesting credentials from end-users. Furthermore, exposure of integration settings may reveal API keys, webhook URLs, or authentication tokens used to connect WordPress with external services like email marketing platforms or CRM systems. If these integrations rely on shared secrets that are partially exposed or if the configuration reveals endpoints for further exploitation, the attacker could potentially escalate their access from passive information gathering to active system compromise. Additionally, since unpublished forms are also affected, this vulnerability undermines the confidentiality of draft content and internal workflows, allowing competitors or malicious actors to窥探 business logic before it is even publicly released.
This behavior closely mirrors techniques documented in the MITRE ATT&CK framework under T1005 Data from Local System Retrieval and specifically relates to data exfiltration over an alternative protocol if the endpoint allows for automated scraping of configuration dumps. The lack of authentication requirements on a function that returns privileged state is a classic example of broken object level authorization, where the application fails to enforce proper checks on specific resources based on user identity. This type of vulnerability often arises during rapid development cycles where security reviews are deprioritized or when developers assume that public-facing submission handlers only handle unauthenticated input data without realizing they also serve as retrieval mechanisms for configuration metadata.
To mitigate this risk, immediate action is required to upgrade the FormLayer plugin to version 1.0.9 or later, which addresses these authorization gaps by implementing proper access control checks on all endpoints returning sensitive configuration data. Administrators should verify that only authenticated users with appropriate roles, such as Administrator or Editor depending on organizational policy, can invoke functions that expose form configurations. In the interim, if upgrading is not immediately feasible, web application firewalls (WAFs) can be configured to monitor and block requests targeting these specific endpoints from unauthenticated sources, although this is a compensatory control rather than a fix for the underlying code flaw. Regular security audits focusing on access control logic in public-facing APIs are essential to prevent similar vulnerabilities where sensitive internal state is exposed due to missing or incorrect permission checks.