Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-11454

CVE-2026-11454: Groundhogg WordPress Plugin IDOR Vulnerability

CVE-2026-11454 is an Insecure Direct Object Reference flaw in the Groundhogg WordPress plugin that exposes contact PII to unauthorized users. This article covers the technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-11454 Overview

CVE-2026-11454 is an Insecure Direct Object Reference (IDOR) vulnerability in the Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress. The flaw affects all versions up to and including 4.5.2. The GET /wp-json/gh/v4/contacts/<id> REST endpoint enforces only the role-level view_contacts capability and omits the object-level view_contact ownership check. Authenticated attackers holding the view_contacts capability — including the built-in Sales Rep role — can read any contact record by iterating sequential integer IDs. The exposed data includes personally identifiable information (PII), contact metadata, owner IDs, admin edit URLs, and the full capability set of any linked WordPress user.

Critical Impact

Any authenticated Sales Rep can enumerate and read every contact stored in the CRM, exposing PII and privileged WordPress user capability data.

Affected Products

  • Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress
  • All versions up to and including 4.5.2
  • Sites using the built-in Sales Rep role or any custom role holding view_contacts without view_others_contacts

Discovery Timeline

  • 2026-08-05 - CVE-2026-11454 published to NVD
  • 2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-11454

Vulnerability Analysis

The vulnerability is classified as an Insecure Direct Object Reference [CWE-639]. Groundhogg exposes a REST route at GET /wp-json/gh/v4/contacts/<id> for retrieving individual contact records. The permission callback for this route validates only the caller's role-level view_contacts capability. The route's read_single() handler then loads and returns the full contact record identified by the integer path parameter.

Elsewhere in the codebase, Groundhogg enforces an object-level view_contact check that verifies whether the current user owns the target contact or holds the view_others_contacts capability. That ownership check is not applied on this endpoint. As a result, contact records are addressable purely by sequential integer ID, and the API returns them without ownership validation.

The response payload includes PII, contact meta, owner IDs, the admin edit URL, and for contacts linked to a WordPress user, that user's full capability set. Attackers can therefore map role assignments across the site by walking contact IDs.

Root Cause

The root cause is missing object-level authorization on the single-contact REST endpoint. The permission callback confirms the caller can view contacts in general, but does not confirm the caller can view this specific contact. The upstream fix, introduced in version 4.5.3, adds the object-level check to the endpoint's authorization logic, as reflected in the plugin's changeset moving the validation into contacts-api.php at line 437.

Attack Vector

Exploitation requires authenticated access with the view_contacts capability but without view_others_contacts. The Sales Rep role shipped with Groundhogg matches this profile. An attacker issues successive authenticated GET requests to /wp-json/gh/v4/contacts/1, /wp-json/gh/v4/contacts/2, and so on, harvesting each returned record. No user interaction is required beyond the attacker's own session, and the request pattern is indistinguishable from legitimate API usage other than by volume and ID sweep behavior.

The vulnerability mechanism is described in the Wordfence Vulnerability Report and the WordPress Groundhogg Contacts API source.

Detection Methods for CVE-2026-11454

Indicators of Compromise

  • Sequential access patterns against /wp-json/gh/v4/contacts/<id> where a single authenticated user requests many distinct contact IDs in a short window.
  • Requests to contact IDs that fall outside the requesting user's assigned ownership scope in the Groundhogg database.
  • Sales Rep or lower-privileged accounts making REST calls that return contact records they did not create or own.

Detection Strategies

  • Enable WordPress REST API request logging and alert on rate anomalies against the gh/v4/contacts/ route per authenticated user.
  • Correlate the requesting user's user_id with the returned owner_id field and flag mismatches when the user lacks view_others_contacts.
  • Inspect web server access logs for enumeration patterns such as monotonically increasing integer path segments on the contacts endpoint.

Monitoring Recommendations

  • Baseline normal contact-read volume per role and alert when a Sales Rep exceeds the baseline.
  • Forward WordPress and web server logs to a centralized analytics platform for cross-user correlation.
  • Review Groundhogg audit trails for bulk contact views originating from non-administrative accounts.

How to Mitigate CVE-2026-11454

Immediate Actions Required

  • Update the Groundhogg plugin to version 4.5.3 or later on every WordPress site running the plugin.
  • Audit existing user accounts that hold the view_contacts capability and remove access from any accounts that no longer require it.
  • Review Groundhogg REST API logs for prior enumeration activity against /wp-json/gh/v4/contacts/<id>.

Patch Information

The vendor released the fix in Groundhogg 4.5.3. The plugin changeset from 4.5.2 to 4.5.3 adds the object-level view_contact ownership check to the single-contact REST handler, as shown in the updated contacts-api.php at line 437.

Workarounds

  • Temporarily revoke the view_contacts capability from the Sales Rep role and any custom roles that do not also hold view_others_contacts.
  • Restrict access to the /wp-json/gh/v4/contacts/ route at the web server or WAF layer to trusted administrator IPs until the patch is applied.
  • Disable the Groundhogg REST API for non-administrator users through role management until an upgrade to 4.5.3 is completed.
bash
# Example WAF rule to block non-admin access to the vulnerable endpoint
# (adapt to your WAF syntax; this is illustrative)
SecRule REQUEST_URI "@rx ^/wp-json/gh/v4/contacts/[0-9]+$" \
    "id:1026114540,phase:1,deny,status:403,\
    msg:'Block Groundhogg contacts IDOR CVE-2026-11454',\
    chain"
    SecRule REQUEST_HEADERS:X-WP-Role "!@streq administrator"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.