CVE-2026-92975: Groundhogg WordPress Privilege Escalation

CVE-2026-92975 Overview

The Groundhogg CRM, Newsletters, and Marketing Automation plugin for WordPress contains a privilege escalation vulnerability affecting all versions up to and including 4.8.3. The flaw resides in the create_support_user() function within admin/help/help-page.php, which identifies the plugin's support account using only publicly hardcoded constants. An attacker who pre-plants an account using the user_login value 'groundhogg' and either 'support@groundhogg.io' or 'help@groundhogg.io' as the email address can have that account silently promoted to administrator when a legitimate administrator triggers the support-access flow. On multisite installations, the account can be promoted to super admin if the triggering administrator holds manage_network_options.

Critical Impact
Full WordPress site takeover through silent privilege escalation to administrator, or super admin on multisite deployments.

Affected Products

Groundhogg CRM, Newsletters, and Marketing Automation plugin for WordPress
All versions up to and including 4.8.3
WordPress multisite installations are at elevated risk due to super admin promotion

Discovery Timeline

2026-10-10 - CVE-2026-92975 published to NVD
2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-92975

Vulnerability Analysis

The vulnerability is a Privilege Escalation issue classified under [CWE-269] Improper Privilege Management. The create_support_user() function in admin/help/help-page.php attempts to re-adopt a pre-existing support account by matching user records against hardcoded identifiers. At line 238, the function uses in_array() to compare a user's user_email value against the constants 'support@groundhogg.io' and 'help@groundhogg.io'. Because end users fully control their own email addresses on registration, this equality check does not form a security boundary. Any account whose login equals 'groundhogg' and whose email matches one of the hardcoded values is treated as the trusted support user and promoted to administrator.

Root Cause

The root cause is reliance on attacker-controllable attributes to establish trust. Both user_login and user_email are values selectable by registrants, yet the function treats them as authoritative identifiers for the plugin's internal support account. No prior-state check was performed to confirm the matched account already held administrator privileges before promotion.

Attack Vector

Exploitation requires a two-actor flow. First, the attacker must obtain or pre-plant a WordPress account with the user_login'groundhogg' and a user_email of 'support@groundhogg.io' or 'help@groundhogg.io'. This is feasible when open registration is enabled or another account-creation path exists. Second, a legitimate administrator must invoke the support-access feature through either the submit_ticket or process_send_support_access entry points, which triggers the silent promotion.

php

// Vendor patch excerpt - admin/help/help-page.php
/**
 * Find a support user created before the support user's ID was stored.
 *
 * The login and email of an account are chosen by its owner, so they can't
 * be used to identify the support user on their own. Only an account that
 * is already an administrator is adopted, so matching it can't be used to
 * escalate privileges.
 *
 * @return false|WP_User
 */
protected function get_legacy_support_user() {

    foreach ( [ self::SUPPORT_EMAIL, self::HELP_EMAIL ] as $email ) {

        $user = get_user_by( 'email', $email );

        if ( $user && in_array( 'administrator', (array) $user->roles, true ) ) {
            return $user;
        }
    }

    return false;
}

The fix adds an explicit check that the matched account already holds the administrator role before adoption, closing the escalation path. Source: Groundhogg patch commit 4b413aa6e.

Detection Methods for CVE-2026-92975

Indicators of Compromise

Presence of a WordPress user account with user_login set to 'groundhogg' that was not created by the plugin's documented support flow.
WordPress user records with user_email matching 'support@groundhogg.io' or 'help@groundhogg.io' created outside normal support workflows.
Unexpected role changes elevating a groundhogg account to administrator or super_admin.

Detection Strategies

Audit the wp_users table for accounts matching the hardcoded support identifiers and review their wp_usermeta role assignments.
Review WordPress audit logs for invocations of the submit_ticket or process_send_support_access endpoints in Groundhogg.
Correlate new user registrations using the groundhogg login against subsequent role elevation events.

Monitoring Recommendations

Monitor plugin version inventory for installations of Groundhogg at or below version 4.8.3.
Alert on any WordPress user capability change that grants administrator or super_admin outside sanctioned provisioning.
Track access to /wp-admin/admin-ajax.php requests referencing Groundhogg help-page actions.

How to Mitigate CVE-2026-92975

Immediate Actions Required

Update the Groundhogg plugin to a version later than 4.8.3 that incorporates the patch from commit 4b413aa6e.
Enumerate and delete any pre-existing user accounts matching the groundhogg login or the hardcoded support email addresses that are not legitimate.
Disable open user registration on affected WordPress sites until the plugin is patched.

Patch Information

The vendor addressed the issue in a patched release following commit 4b413aa6e. The fix introduces get_legacy_support_user(), which only adopts an existing user when that user already holds the administrator role, removing the escalation primitive. Review the Wordfence Vulnerability Report for additional vendor-provided detail.

Workarounds

Disable the Groundhogg plugin until it can be updated to a fixed version.
Set users_can_register to false in WordPress general settings to block attacker-controlled account creation.
Instruct administrators to avoid triggering the support-access feature (submit_ticket, process_send_support_access) until patching is complete.

bash

# Verify no pre-planted support accounts exist (run via wp-cli)
wp user list --search="groundhogg" --fields=ID,user_login,user_email,roles
wp user list --search="support@groundhogg.io" --fields=ID,user_login,user_email,roles
wp user list --search="help@groundhogg.io" --fields=ID,user_login,user_email,roles

# Disable open registration
wp option update users_can_register 0

# Update the plugin once a patched release is available
wp plugin update groundhogg