CVE-2026-89286 in FormFlow for GoHighLevel Plugin
Summary
by MITRE • 10/19/2026
The FormFlow for GoHighLevel (GHL) WordPress plugin through 1.0.0 does not restrict access to a log file it writes inside the publicly accessible uploads directory, allowing unauthenticated attackers to read its contents, which include connected-CRM identifiers and, on sites that have linked the integration, a third-party access token.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in the FormFlow for GoHighLevel WordPress plugin version 1.0.0 represents a critical failure in file permission management within the application's logging mechanism. The plugin is designed to facilitate integrations between WordPress sites and the GoHighLevel customer relationship management platform, requiring the storage of sensitive configuration data such as CRM identifiers and authentication tokens. To manage operational logs or debug information, the software writes content into files located within the wp-content/uploads directory, a standard location for user-generated media in WordPress environments that is inherently accessible via HTTP requests by default. The core technical flaw lies in the absence of access controls on these specific log files. While the parent uploads directory may have certain restrictions depending on server configuration, the individual log files created by this plugin are not secured against direct web access. This oversight allows any unauthenticated user who can identify or guess the file path to retrieve the contents directly through a browser or automated script without needing valid credentials for the WordPress administration panel.
From an operational impact perspective, this vulnerability facilitates unauthorized information disclosure that compromises both privacy and security integrity. The exposed log files contain connected-CRM identifiers which reveal internal business structures and integration points, potentially aiding attackers in mapping out target environments. More critically, on sites where the GoHighLevel integration has been linked, these logs store third-party access tokens. These tokens serve as credentials for API interactions with external services. If an attacker obtains such a token, they can impersonate the legitimate user or application to interact with the GoHighLevel platform. This could lead to unauthorized data exfiltration from the CRM, manipulation of customer records, injection of malicious content into communications managed by the platform, or further lateral movement if other systems are linked via similar authentication mechanisms. The severity is amplified because the attack vector requires no user interaction beyond visiting a crafted URL, classifying it as an unauthenticated remote code execution precursor in terms of data theft potential.
This vulnerability aligns with CWE-200: Information Exposure and CWE-538: File and Directory Information Exposure. It also maps to MITRE ATT&CK technique T1005: Data from Local System, specifically the sub-technique for file discovery or direct access to stored data. The lack of proper sanitization of output paths and failure to restrict read permissions on sensitive files are classic indicators of insecure default configurations often found in third-party plugins that prioritize functionality over security hardening. Attackers can leverage automated tools to scan common WordPress upload directories for predictable log filenames, such as those generated by the plugin's internal naming conventions, thereby automating the exploitation process at scale.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade the FormFlow for GoHighLevel plugin to a version where this issue has been patched by the developer, ensuring that log files are written outside of publicly accessible directories or have strict file permissions set to prevent web server access. If an update is not immediately available, administrators should manually move any generated log files from the uploads directory to a location such as wp-content/debug.log or another non-public path and ensure appropriate filesystem-level restrictions are applied using chmod commands to remove read permissions for group and others. Additionally, implementing Web Application Firewall rules can help block requests targeting suspicious file extensions commonly associated with debug logs in WordPress environments. Regular auditing of plugin code for similar patterns where sensitive data is written to accessible locations should be conducted as part of routine security maintenance to prevent recurrence of such information leakage vulnerabilities.