Groundhogg EUVD-2026-96095

Requires an authenticated WordPress account at sales_rep role or higher - specifically one holding the default edit_contacts, view_notes, and add_notes capabilities - but critically NOT the edit_users or promote_users capabilities, which is exactly why this is a privilege-escalation flaw. The vulnerable path is the process_edit() function on the Groundhogg contacts admin page (contacts-page.php), which fails to verify ownership or capability on the contact's 'user' parameter, letting the attacker relink a contact to an arbitrary (administrator) WordPress user ID. Exploitation further relies on the {auto_login_link} replacement tag being processable in note content and the resulting permissions-key auto-login URL being stored in and readable from the note. No special non-default server configuration is required beyond having the plugin installed (version <= 4.9) and possessing the sales_rep-or-above account; the primary limiting factor is that the attacker must already hold such an authenticated low-level account, not anonymous access.

This is a genuine high-priority issue rather than an inflated-CVSS artifact. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) and the detailed description agree with each other: a low-privileged but authenticated WordPress user (sales_rep role and above, holding edit_contacts/view_notes/add_notes by default) can achieve full administrator takeover over the network with no user interaction and low attack complexity. The CWE-269 (Improper Privilege Management) classification, the C:H/I:H/A:H impact, and the described end state (authenticating as a targeted administrator) are internally consistent, and the GitHub fix commit directly corroborates the root cause by adding a can_link_contact_to_user() capability gate on the user_id parameter and redacting sensitive auto-login logs. Conflicting/missing signals to note explicitly: no EPSS score, no CISA KEV listing, and no POC indicator were provided, so exploitation probability and in-the-wild activity cannot be quantified from this data - exploitation status is therefore 'no public exploit identified at time of analysis', NOT active exploitation. The practical risk ceiling is high (full admin compromise), but realization depends on an attacker already holding a sales_rep-or-higher account, which bounds the threat to environments that grant such accounts to semi-trusted or externally-reachable users.

An authenticated user with sales_rep-level access edits a contact record and reassigns its linked WordPress user ID to an administrator's account, exploiting the missing ownership/capability check in process_edit(). They then add a note containing the {auto_login_link} replacement tag, read back the generated valid auto-login URL via their default view_notes capability, and visit it to authenticate as the administrator. No public exploit was identified in the provided data, though the attack path is fully described and the fixing commit is public.