Description

The Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.8.3 via the `create_support_user()` function. This is due to the function identifying the support account solely by matching against publicly hardcoded constants — `user_login` `'groundhogg'` and email addresses `'support@groundhogg.io'` / `'help@groundhogg.io'` — where the `in_array()` email-equality check at line 238 is not a security boundary because any user fully controls their own email value. This makes it possible for an attacker with an account whose `user_login` is `'groundhogg'` and whose `user_email` matches one of the hardcoded support constants to have that account silently promoted to administrator — and additionally to super admin on multisite when the triggering administrator holds `manage_network_options` — resulting in full site takeover. Exploitation requires a two-actor flow: the attacker must first obtain or pre-plant an account with the hardcoded credentials (possible when open user registration is enabled or another account-creation path exists), after which a legitimate administrator must invoke the support-access feature via the `submit_ticket` or `process_send_support_access` entry points to trigger the promotion.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-10T06:16:44.253Z",
  "pubdate": "2026-10-10T06:16:44.253Z",
  "executiveSummary": "Groundhogg versions up to and including 4.8.3 contain a critical Privilege Escalation vulnerability within the create_support_user() function.\nThe vulnerability stems from improper authentication logic where the system identifies a support account based on hardcoded constants rather than verifiable credentials.\nAn attacker can exploit this by registering an account with the username 'groundhogg' and configuring its email address to match one of the predefined support constants.\nWhen a site administrator invokes support access functionality, the plugin incorrectly elevates the attacker's account to administrator privileges.\nIn multisite environments, this escalation may extend to super admin status, granting the attacker full control over the WordPress installation.\nThe vulnerability requires an account with specific identifiers and the interaction of a legitimate administrator triggering the support feature.\nSuccessful exploitation results in total site compromise, allowing for unauthorized data access, code execution, or administrative modification.",
  "technicalDetails": "The vulnerability resides within the create_support_user() function, which is responsible for managing administrative access for support purposes. The function improperly validates the user account to be promoted by relying on hardcoded constants: 'user_login' set to 'groundhogg' and 'user_email' matching 'support@groundhogg.io' or 'help@groundhogg.io'.\nThe root cause is a flawed equality check implemented via in_array() at line 238. This check fails to act as a secure boundary because the user_email attribute of a WordPress account is fully controllable by the account owner. Because the function does not verify the authenticity of the support user through a cryptographic token or a hardcoded password check, it erroneously trusts any account matching these parameters as a legitimate support entity.\nThe attack vector necessitates a two-actor synchronization. First, the attacker must successfully register an account on the target system with the username 'groundhogg'. This is feasible if open user registration is enabled or if other vectors for account creation exist. The attacker then updates the profile's email address to one of the hardcoded support values. The account effectively enters a 'dormant' malicious state.\nThe second phase of the attack flow requires a legitimate site administrator to interact with the Groundhogg plugin's support features, specifically by invoking the 'submit_ticket' or 'process_send_support_access' entry points. Upon this trigger, the vulnerable code executes. It scans for the user matching the hardcoded constants and updates their role to administrator. If the triggering administrator possesses 'manage_network_options' capability on a multisite installation, the attacker is further promoted to super admin.\nThis vulnerability effectively bypasses WordPress privilege management by leveraging administrative functions meant for system maintenance. Since the application provides elevated privileges to the user identity identified by the flawed function, the attacker achieves persistence and full administrative control, enabling them to modify plugins, themes, and site configurations post-exploitation."
}