CVE-2026-92975

Executive Summary

CVE-2026-92975 is a privilege escalation vulnerability in the Groundhogg — CRM, Newsletters, and Marketing Automation WordPress plugin affecting all versions up to and including 4.8.3. The flaw resides in the create_support_user() function, which identifies a legitimate support account solely by matching hardcoded constants (user_login 'groundhogg' and emails 'support@groundhogg.io' / 'help@groundhogg.io'), allowing an attacker-controlled account to be silently promoted to administrator — and to super admin on multisite — resulting in full site takeover. The vulnerability carries a CVSS 3.1 base score of 8.1 (High) and, as of this report, remains unpatched with no public proof-of-concept or exploit code available.

Technical Analysis

The vulnerability is a classic privilege escalation (CWE-269, Improper Privilege Management) rooted in flawed identity verification logic. The create_support_user() function is designed to provision or reconcile a vendor support account. Rather than relying on a cryptographic secret, signed token, verified remote callback, or an unforgeable server-side marker, the function determines whether a given account is the trusted support account by comparing user-controlled fields against publicly hardcoded constants:

• user_login equal to 'groundhogg'
• user_email equal to 'support@groundhogg.io' or 'help@groundhogg.io'

The NVD description explicitly identifies the in_array() email-equality check at line 238 as the core defect. The reason this is not a security boundary is that a user fully controls their own email value — an account holder can set their user_email to any of the hardcoded addresses. Likewise, user_login is a value that can be planted at account-creation time through open registration or any other account-creation path. When these two attacker-controllable fields match the hardcoded constants, the function treats the account as the trusted support identity and promotes it — silently — to administrator. On multisite installations where the administrator who triggers the flow additionally holds the manage_network_options capability, the promotion escalates further to super admin.

Two characteristics of this flaw warrant emphasis. First, the trigger is a legitimate administrative action: the promotion is invoked when an administrator uses the support-access feature through the submit_ticket or process_send_support_access entry points. The attacker does not need to exploit a memory-safety bug or inject a payload; they need only ensure a pre-planted or attacker-obtained account satisfies the hardcoded identity constants, then wait for (or induce) the administrator to invoke the support-access feature. This two-actor flow is why the CVSS vector specifies AC:H (High attack complexity) and PR:N (no privileges required by the attacker) with a network attack vector.

From a code-level perspective, the root cause is the conflation of identity with user-supplied attributes. Hardcoded credentials and hardcoded identity markers are functionally secrets only if they cannot be reproduced by an attacker. Here they are public constants embedded in the plugin source, and one of the two matching fields (email) is expressly user-controlled. The check therefore cannot authenticate anything; it merely confirms that the attacker has typed the expected values. A correct implementation would require a server-side secret or a verified, unforgeable session artifact originating from the plugin vendor, none of which is present.

Because the flaw is unpatched, every deployment of Groundhogg at or below 4.8.3 that exposes an account-creation path (notably open user registration) is at risk. No CVSS temporal or environmental adjustments are published, and the absence of any vendor patch means the vulnerability must be mitigated at the WordPress configuration and workflow level.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the NVD description and the vulnerability class.

1. Reconnaissance / target identification. The attacker identifies WordPress sites running the Groundhogg plugin version ≤ 4.8.3. Identification is typically passive: page source inspection for /wp-content/plugins/groundhogg/ paths, plugin enumeration responses, or Shodan-style fingerprinting (http.html:"groundhogg", http.html:"/wp-content/plugins/groundhogg/"). The attacker then checks whether an account-creation path exists — most commonly whether open user registration is enabled (wp-login.php?action=register reachable) or whether any other account-creation mechanism is exposed.

2. Triggering the flaw class. The attacker needs an account whose user_login is 'groundhogg' and whose user_email matches one of the hardcoded support constants. The NVD description states this account can be obtained or pre-planted when open user registration is enabled or another account-creation path exists. The attacker registers (or otherwise causes the creation of) such an account. There is no injection, overflow, or malformed input required — the account simply satisfies the hardcoded constants.

3. Execution / invocation method. The promotion is not self-triggered. A legitimate administrator must invoke the support-access feature via one of the named entry points, submit_ticket or process_send_support_access. When that administrator initiates the flow, create_support_user() runs, matches the attacker's account against the constants (user_login and the in_array() email check at line 238), and silently promotes it to administrator. Because the NVD text describes this as "silently promoted," the administrator receives no obvious confirmation of a privilege change to the attacker-controlled account. The attacker may increase the probability of the trigger by making ordinary use of the plugin-generated support/ticket interface so that the administrative workflow is exercised.

4. Post-exploitation impact. With the account promoted to administrator, the attacker has full administrative control of the WordPress site. On multisite, if the administrator who triggered the promotion holds manage_network_options, the account is additionally promoted to super admin, yielding control of the entire network — full site takeover. From that position, attackers can install or edit plugins and themes, deploy webshells, exfiltrate the user and customer database, redirect traffic, and persist through rogue administrator accounts.

Impact Assessment

Successful exploitation yields complete site takeover, which maps directly to the CVSS subscores: Confidentiality: High, Integrity: High, and Availability: High. The vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (base 8.1) encodes the following interpretation:

• AV:N — the attack surface is network-reachable; the attacker interacts with web endpoints, not local resources.
• AC:H — High attack complexity, reflecting the two-actor flow: the attacker must plant or obtain a qualifying account and a legitimate administrator must independently invoke the support-access feature. The outcome is not fully attacker-controlled, which is why complexity is rated High rather than Low.
• PR:N — the attacker needs no privileges to begin; account creation via open registration is unprivileged.
• UI:N — no victim UI interaction is modeled in the base score for the attacker's own actions.
• S:U — scope is unchanged; impact is confined to the vulnerable WordPress installation.
• C/I/A: High — full compromise of site data, integrity, and availability.

The blast radius is significant. Groundhogg is a CRM, newsletter, and marketing automation plugin, meaning affected sites often store customer PII, subscriber lists, and possibly payment or transactional data. Post-takeover, attackers can exfiltrate this data, use the site for spam/phishing distribution (leveraging the marketing automation stack), or pivot into connected third-party integrations whose API keys sit in the WordPress database. On multisite deployments, the escalation to super admin dramatically expands the blast radius from one site to the entire network.

Affected systems are any WordPress installation running Groundhogg ≤ 4.8.3 where an account-creation path exists. The vulnerability is not known to be in CISA KEV and no exploit code is publicly available, currently lowering the likelihood of opportunistic mass exploitation — but the ease of positioning a qualifying account and the value of the resulting admin access make targeted exploitation plausible.

Detection Guidance

Detection focuses on (a) account creation using the hardcoded identity constants, (b) unexpected role changes to administrator/super admin, and (c) invocations of the submit_ticket / process_send_support_access support-access entry points. Because the promotion is silent, role-change monitoring and creation of the anomalous 'groundhogg' login are the highest-value signals.

Sigma Rule

title: Groundhogg Support Account Privilege Escalation (CVE-2026-92975)
id: 7e6c5f2a-92975-4f0e-9d3c-groundhoggpe
status: experimental
description: Detects creation or modification of a user account using the hardcoded Groundhogg support identity constants, or unexpected promotion of such an account to administrator.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-92975
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1068
  - attack.persistence
logsource:
  product: wordpress
  service: audit
detection:
  selection_login:
    user_login: 'groundhogg'
  selection_email:
    user_email:
      - 'support@groundhogg.io'
      - 'help@groundhogg.io'
  selection_role:
    role:
      - 'administrator'
      - 'super_admin'
  condition: (selection_login or selection_email) and selection_role
falsepositives:
  - Legitimate Groundhogg support accounts provisioned by the vendor under strict change control
level: critical

YARA Rule

rule CVE_2026_92975_Groundhogg_PrivEsc
{
    meta:
        description = "Detects Groundhogg plugin source containing hardcoded support account identity constants (CVE-2026-92975)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-92975"
        date = "2026-01-01"
        severity = "high"
    strings:
        $fn     = "create_support_user" ascii
        $login  = "'groundhogg'" ascii
        $email1 = "support@groundhogg.io" ascii
        $email2 = "help@groundhogg.io" ascii
        $inarr  = "in_array" ascii
    condition:
        $fn and $inarr and $login and (1 of ($email1, $email2))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-92975 Groundhogg support-access privilege escalation attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"submit_ticket"; nocase; http.uri; content:"groundhogg"; nocase; classtype:attempted-admin; reference:cve,2026-92975; sid:202692975; rev:1;)

Elastic Detection

sequence by process.entity_id
  [ process where process.name : "php*" and
      process.args : "*create_support_user*" ]
  [ process where process.name : "php*" and
      process.args : ( "*submit_ticket*" or "*process_send_support_access*" ) ]

Splunk SPL Query

index=wordpress (uri_path="*submit_ticket*" OR uri_path="*process_send_support_access*")
    OR (event_type="user_role_change" AND (role="administrator" OR role="super_admin"))
| search user="groundhogg" OR user_email="support@groundhogg.io" OR user_email="help@groundhogg.io" OR role="administrator" OR role="super_admin"
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, user, user_email, role
| where count > 0

Wazuh OSSEC Rule

<group name="wordpress,groundhogg,">
  <rule id="929750" level="12">
    <decoded_as>json</decoded_as>
    <field name="user_login">groundhogg</field>
    <description>CVE-2026-92975: Groundhogg hardcoded support login 'groundhogg' observed in WordPress audit log</description>
    <mitre>
      <id>T1068</id>
    </mitre>
  </rule>
  <rule id="929751" level="13">
    <decoded_as>json</decoded_as>
    <field name="user_email">support@groundhogg.io|help@groundhogg.io</field>
    <description>CVE-2026-92975: Groundhogg hardcoded support email observed during account event</description>
    <mitre>
      <id>T1068</id>
    </mitre>
  </rule>
  <rule id="929752" level="14">
    <decoded_as>json</decoded_as>
    <field name="role">administrator|super_admin</field>
    <field name="user_login">groundhogg</field>
    <description>CVE-2026-92975: Possible silent promotion of Groundhogg support account to administrator/super admin</description>
    <mitre>
      <id>T1068</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version metadata is currently published beyond the ≤ 4.8.3 range.

1) Immediate mitigations

• Disable open user registration (Settings > General > Membership unchecked) and audit any other account-creation paths on the site. This removes the primary means of planting a qualifying account.
• Restrict the ability to set the user_login 'groundhogg' and the hardcoded support emails. If a legitimate account with login 'groundhogg' already exists, verify its ownership and rotate its credentials.
• If the Groundhogg support-access feature is not operationally required, disable or restrict the workflow that invokes submit_ticket and process_send_support_access.
• Enforce least privilege on manage_network_options on multisite so that administrators invoking the support flow cannot escalate accounts to super admin.
• Monitor for unexpected administrator or super admin role assignments and for any account whose login is 'groundhogg'.

2) Patch / upgrade steps

• No patch is available as of this writing. Track the vendor (Groundhogg) for a fixed release and apply it immediately upon publication. Given zero patch confidence from all tracked sources, treat any version ≤ 4.8.3 as vulnerable and do not assume a silent fix.
• Until a patch exists, consider temporarily deactivating the plugin where the support-access feature is not essential to operations.

3) Long-term hardening

• Treat all identity checks as security boundaries only when backed by an unforgeable, server-side secret or signed token; never authenticate on user-controllable fields such as email or on publicly embedded string constants.
• Implement role-change alerting and periodic reconciliation of WordPress user roles against an authoritative baseline.
• Apply the principle of least privilege to all administrator and multisite super admin capabilities, and separate the "support access" workflow from privilege-granting logic.
• Maintain an inventory of installed plugins and versions with automated alerting on known-vulnerable releases.

References

• NVD — CVE-2026-92975: https://nvd.nist.gov/vuln/detail/CVE-2026-92975
• Groundhogg plugin (WordPress.org): https://wordpress.org/plugins/groundhogg/
• MITRE CWE-269 — Improper Privilege Management: https://cwe.mitre.org/data/definitions/269.html
• MITRE ATT&CK T1068 — Exploitation for Privilege Escalation: https://attack.mitre.org/techniques/T1068/
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-92975 not listed as of this report)

No public proof-of-concept, exploit code, or Nuclei template exists for this CVE, and there is no evidence of exploitation in the wild or attribution to a specific threat actor campaign at the time of writing.