CVE-2026-97644 in Groundhogg Plugin
Summary
by MITRE • 10/03/2026
The Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress is vulnerable to Privilege Escalation via Contact Identity Rebinding in all versions up to, and including, 4.9 The vulnerability exists because the `create_contact` function in the v3 REST endpoint (`POST /gh/v3/contacts`) is gated solely by the `add_contacts` capability and forwards the full request payload — including the security-bearing `user_id` column — into the upsert path of `Contacts_DB::add()`, which bypasses the ownership guard that `Contacts_DB::update()` enforces, allowing an attacker to rebind any existing contact record to an arbitrary WordPress user ID. This makes it possible for authenticated attackers with Sales Representative-level access and above to upsert their own contact row to point to an Administrator's user ID, then invoke the v4 email-test endpoint (`POST /gh/v4/emails/test`) — also accessible to the Sales Representative role via the `send_emails` capability — to generate an `{auto_login_url}` one-time permissions key bound to the rebound contact, and consume that link to call `wp_set_auth_cookie()` and gain a fully authenticated session as the WordPress Administrator.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The Groundhogg plugin for WordPress, which provides CRM, newsletter, and marketing automation functionalities, contains a critical privilege escalation vulnerability affecting all versions up to 4.9. This flaw stems from an insecure direct object reference mechanism within the REST API implementation, specifically in how contact records are created or updated via the v3 endpoint. The core technical deficiency lies in the `create_contact` function associated with the POST /gh/v3/contacts route. While this endpoint is correctly gated by the add_contacts capability to restrict access to authenticated users such as Sales Representatives and above, it fails to sanitize input data before processing. Specifically, the function accepts a user_id field within the request payload without validating whether the requesting user has permission to assign that identity to the new or existing contact record. This design oversight allows an attacker to manipulate the ownership of contact entities by supplying arbitrary WordPress user IDs in the submission data.
The vulnerability is exacerbated by the internal database handling logic, particularly the interaction between Contacts_DB::add and Contacts_DB::update methods. When a request is processed, the system forwards the entire payload, including the maliciously injected user_id column, into an upsert operation via Contacts_DB::add. Unlike the update path enforced by Contacts_DB::update, which includes ownership guards to ensure users can only modify records they own or have explicit permission to edit, the add path lacks these restrictive checks. Consequently, an attacker with Sales Representative-level access and higher privileges can insert a new contact row that is explicitly bound to an Administrator's WordPress user ID rather than their own. This effectively rebinding of identity allows lower-privileged users to masquerade as high-privilege accounts within the application's data layer, bypassing standard role-based access controls designed to isolate administrative functions from marketing or sales operations.
The operational impact of this vulnerability is severe, leading directly to full system compromise through a chained attack sequence. Once an attacker has successfully rebound a contact record to an Administrator’s user ID using the v3 endpoint, they can leverage another accessible feature within Groundhogg to escalate privileges further. The plugin exposes a v4 email testing endpoint at POST /gh/v4/emails/test, which is also restricted by the send_emails capability available to Sales Representatives and above. By invoking this endpoint with the compromised contact data, the system generates an auto_login_url containing a one-time permissions key bound to the rebound Administrator identity. When the attacker accesses this URL, it triggers wp_set_auth_cookie(), establishing a fully authenticated session as the WordPress Administrator without requiring valid credentials for that account. This chain of exploitation transforms a minor input validation flaw into complete administrative takeover, allowing attackers to modify site settings, install malicious plugins, access sensitive customer data, and potentially compromise the underlying server infrastructure.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management due to the failure to enforce appropriate authority levels for specific actions involving user identity assignment. It also reflects CWE-345 Insufficient Verification of Data Authenticity as the system accepts untrusted input that alters critical security attributes without validation. In terms of offensive tactics, this exploit maps to ATT&CK technique T1078 Valid Accounts, specifically utilizing legitimate credentials with lower privileges to gain higher-level access through application logic flaws rather than credential theft or brute force attacks. The attack vector is remote and requires authentication, classifying it under the initial access phase where attackers leverage existing valid accounts to move laterally within the environment by exploiting trust relationships between different user roles.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Users running Groundhogg versions up to 4.9 should immediately update to the latest patched version released by the vendor, which likely implements strict validation on the user_id field during contact creation operations. Until an official patch is applied or if updating is not feasible in a legacy environment, administrators can temporarily disable the affected REST endpoints via server-level configuration rules such as Nginx deny directives or Apache mod_rewrite conditions to block access to /gh/v3/contacts and /gh/v4/emails/test for non-administrative roles. Additionally, implementing Web Application Firewall (WAF) rules that detect anomalous patterns in JSON payloads containing unexpected user_id fields can provide a layer of defense against exploitation attempts. Long-term remediation requires enforcing principle of least privilege by ensuring that all API endpoints validate not only the requester’s role but also the consistency between the requester and any identity attributes being modified or created within the payload, thereby preventing unauthorized rebinding of contact records to privileged accounts.