CVE-2026-97644: Groundhogg Privilege Escalation via Contact Identity Rebinding

Overview

Groundhogg — CRM, Newsletters, and Marketing Automation, a WordPress plugin by trainingbusinesspros used to run email marketing, sales pipelines, and automation funnels, is affected by an authenticated privilege-escalation vulnerability tracked as CVE-2026-97644. The flaw affects all versions up to and including 4.9 and carries a CVSS 3.1 score of 8.8 (High), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

The vendor-assigned advisory title describes the issue precisely: "Groundhogg ≤ 4.9 — Authenticated (Sales Person+) Privilege Escalation via Contact Identity Rebinding leading to Administrator Account Takeover via user_id Parameter (v3 /contacts) chained with v4 /emails/test." An attacker holding only a low-privilege Sales Person role can chain two plugin REST endpoints to fully take over an Administrator account — no admin interaction required.

The vulnerability was reserved 2026-09-24, the vendor was notified the same day, it was publicly disclosed 2026-10-02, and the CVE record was published 2026-10-03. The finding is credited to researcher Supakiad S. (m3ez). As of publication there is no entry in the CISA KEV catalog, no public proof-of-concept exploit code, and no known ransomware tie-in.

Vulnerability Details

How It Works

Step 1 — Contact Identity Rebinding via POST /gh/v3/contacts

The root cause sits in the create_contact function behind Groundhogg's v3 REST endpoint, POST /gh/v3/contacts. That endpoint is gated solely by the add_contacts capability — a permission granted to the plugin's Sales Person role and above — and it forwards the entire request payload, including a security-bearing user_id field, straight into the upsert logic of Contacts_DB::add().

The problem is that Contacts_DB::add() does not apply the same ownership checks as Contacts_DB::update(). The update path verifies that a caller can only modify contact records they own or have explicit permission to edit. The add/upsert path skips that guard entirely. A low-privileged user can therefore submit a crafted create_contact request that sets user_id to the numeric ID of an Administrator, creating (or rebinding) a contact record that the application's data layer now treats as belonging to that Administrator — even though the request was authenticated as a Sales Person.

This is the "Contact Identity Rebinding" at the heart of the advisory: the attacker doesn't compromise the Administrator's credentials, they manipulate which WordPress identity a contact record — and by extension, any authentication artifact derived from it — is bound to.

Step 2 — Chaining into POST /gh/v4/emails/test

On its own, a mismatched user_id on a contact record is a data-integrity problem. The advisory escalates it to full account takeover by chaining it with Groundhogg's v4 email-testing endpoint, POST /gh/v4/emails/test. That endpoint is restricted by the send_emails capability, which — like add_contacts — is also available to the Sales Person role.

When invoked against the attacker-rebound contact, the test-email flow generates an auto_login_url containing a one-time permissions key. Because the contact record is now bound to the Administrator's user_id, the generated login link is itself bound to the Administrator identity. Visiting that URL authenticates the attacker's browser session as the Administrator — completing the privilege escalation from Sales Person to full site Administrator in two authenticated API calls.

Attack Summary

1. Attacker authenticates to WordPress/Groundhogg with a low-privilege Sales Person account
2. Attacker sends POST /gh/v3/contacts with a crafted payload setting user_id to an Administrator's ID
3. Contacts_DB::add() upserts the record without the ownership checks Contacts_DB::update() enforces
4. The contact record is now rebound to the Administrator identity in Groundhogg's data layer
5. Attacker sends POST /gh/v4/emails/test targeting the rebound contact
6. Groundhogg issues an auto_login_url with a one-time permissions key bound to the Administrator
7. Attacker visits the link and is authenticated as Administrator — full site takeover

Impact Assessment

Recommendations

For Site Administrators

1. Update Groundhogg to version 4.9.1 or later immediately. The vendor's fix removes the unguarded upsert path in the v3 contacts endpoint. Verify the installed version via Plugins → Installed Plugins or wp plugin get groundhogg --field=version.
2. Audit existing user roles. Review all accounts with the Groundhogg Sales Person role (or any role granting add_contacts / send_emails) and confirm they are still appropriate and necessary.
3. Review contact records for anomalous user_id bindings, particularly any contact tied to an Administrator account that wasn't created through normal onboarding.
4. Rotate WordPress Administrator credentials and force a re-login for all Admin accounts as a precaution if the plugin was running an affected version in production.

For Security Teams

1. Hunt for exploitation indicators: unexpected POST requests to /gh/v3/contacts containing a user_id field, followed shortly by requests to /gh/v4/emails/test for the same contact.
2. Enable WAF rules that flag API payloads to Groundhogg's REST namespace (/wp-json/gh/) containing unexpected user_id parameters.
3. Enforce least privilege on all custom REST endpoints beyond this plugin: validate that the requester's own identity is consistent with any identity attribute (user_id, owner fields, etc.) being written or referenced in a payload — not just that the requester holds the matching capability.
4. Monitor authentication logs for Administrator sessions originating from auto_login_url / one-time permission-key flows that don't correlate with a normal admin login event.

For Users with Sales/Marketing Roles

1. If your organization runs Groundhogg, confirm with IT/security that the plugin has been patched before continuing to use contact-management or email-test features.
2. Report any unexpected permission changes or unfamiliar Administrator activity to your security team immediately.

Key Takeaways

1. CVE-2026-97644 is a High-severity (CVSS 8.8) privilege-escalation flaw in the Groundhogg WordPress plugin, affecting all versions ≤ 4.9.
2. The root cause is that the v3 create_contact REST endpoint (POST /gh/v3/contacts) forwards an unvalidated user_id field into Contacts_DB::add(), which — unlike Contacts_DB::update() — lacks ownership checks.
3. Chaining this with the v4 POST /gh/v4/emails/test endpoint lets an authenticated Sales Person escalate to a full Administrator session via a one-time login link.
4. The flaw is fixed in version 4.9.1 — all sites running Groundhogg should update immediately.
5. No public exploit code or CISA KEV listing exists yet, but the attack requires only low-privilege authenticated access and no admin interaction, making it a realistic risk on any multi-role WordPress/marketing deployment.
6. Defense in depth matters: API endpoints must validate consistency between the authenticated requester and any identity fields in the payload, not rely on capability checks alone.

Sources

• NVD — CVE-2026-97644
• RedPacket Security — CVE Alert: CVE-2026-97644
• VulDB — CVE-2026-97644 in Groundhogg Plugin