CVE-2026-11454

Executive Summary

CVE-2026-11454 is an Insecure Direct Object Reference (IDOR) vulnerability in the Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress, affecting all versions up to and including 4.5.2. The vulnerability exists in the GET /wp-json/gh/v4/contacts/<id> REST API endpoint, where the permission callback only checks the role-level view_contacts capability, but fails to enforce the object-level view_contact ownership check that is applied elsewhere in the codebase. This allows authenticated attackers with only view_contacts permission — notably Groundhogg's built-in Sales Rep role, which is designed to see only its own contacts — to read any contact record on the site, including Personally Identifiable Information (PII), contact metadata, owner IDs, admin edit URLs, and, for contacts linked to WordPress user accounts, the complete user capability set.

The vulnerability has a CVSS score of 6.5 (Medium) with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, indicating a network-exploitable flaw requiring low-privilege authentication, with high confidentiality impact but no integrity or availability impact. No evidence of active exploitation has been confirmed, the CISA KEV catalog does not list this CVE, and no patch has been identified from any tracked source at the time of this analysis.

Technical Analysis

The vulnerability is rooted in an authorization logic gap within the Groundhogg plugin's REST API implementation. The affected endpoint, GET /wp-json/gh/v4/contacts/<id>, is designed to retrieve contact records via sequential integer identifiers. The REST route registration defines a permission callback that validates only whether the authenticated user possesses the role-level view_contacts capability.

The core flaw lies in the read_single() method — the handler invoked when this endpoint is called. This method retrieves and returns the full contact record based purely on the supplied sequential integer ID, without re-validating that the requesting user owns or has explicit object-level access to that specific contact record. The Groundhogg codebase contains an ownership check (view_contact capability) that is applied in other parts of the application to restrict users to contacts they own, but this check is not applied within the read_single() method for this REST endpoint.

The attack surface is exposed to any authenticated user of the WordPress instance running the affected plugin version. The plugin's built-in Sales Rep role is explicitly designed to have the view_contacts capability while lacking the view_others_contacts capability — meaning this role is intended to manage only its own assigned contacts. Due to the missing object-level check, any user in this role can enumerate sequential integer IDs and retrieve arbitrary contact records.

The impact of the data exposure is significant. Each contact record can contain:

• Personally Identifiable Information (PII) captured through CRM data collection
• Contact metadata fields (custom fields configured by site administrators)
• Owner IDs, revealing which user manages which contacts
• The admin edit URL for each contact record
• For contacts linked to a WordPress user account: the full user capability set, which enumerates all roles and permissions assigned to that user

The vulnerability is classified under CWE-639 (Insecure Direct Object Reference), consistent with the authorization bypass pattern where the application uses user-supplied object identifiers without verifying the requester's authorization for that specific object.

Exploitation Scenarios

Scenario: Sales Representative Contact Data Exfiltration

This is the most realistic exploitation path given the plugin's role design. The attack chain proceeds as follows:

1. Reconnaissance and Target Identification: The attacker authenticates to the WordPress site using a valid account with the Sales Rep role (which has view_contacts but lacks view_others_contacts). This role is standard in Groundhogg deployments. The attacker confirms the affected endpoint exists by making a legitimate request to their own contact record, e.g., GET /wp-json/gh/v4/contacts/1, observing a valid response structure.

2. Trigger and Weaponization: The attacker writes a script (Python, bash with curl, or a browser extension) to enumerate contact IDs sequentially. Starting from ID 1, the script issues consecutive authenticated GET requests to GET /wp-json/gh/v4/contacts/<id>, incrementing the ID for each request. Because the permission callback only checks view_contacts, each request returns the full contact record, regardless of ownership.

3. Payload and Execution: The attacker runs the enumeration script. For a CRM database with thousands of contacts, this translates to thousands of HTTP requests. Each response contains the full JSON representation of a contact record, including all PII fields, contact meta, owner IDs, and admin edit URLs. For contacts linked to WordPress users, the response includes the full user capability set, potentially revealing administrative accounts and their privileges.

4. Post-Exploitation Impact: The attacker now possesses a complete copy of the CRM database's contact information. This data can be used for phishing campaigns targeting the contacts, social engineering attacks against the platform administrators, or sold on dark web marketplaces. The admin edit URLs provide direct targets for further attacks against the WordPress admin interface. The leaked capability sets can reveal privileged accounts (e.g., accounts with administrator or manage_options capabilities), informing subsequent privilege escalation attempts.

Scenario: Horizontal Privilege Escalation Reconnaissance

In a multi-tenant or department-segregated deployment where different teams manage separate contact pools, an attacker with access to any view_contacts role can enumerate all contact records across all teams, bypassing organizational access controls. The attacker can identify which contacts belong to executive teams or high-value clients based on owner IDs and contact metadata, enabling targeted attacks against those individuals.

Scenario: WordPress User Enumeration and Capability Harvesting

For contacts with linked WordPress user accounts, the attacker gains insight into internal user roles. This capability enumeration allows the attacker to map the user base, identify high-privilege accounts, and tailor further attacks. Combined with the admin edit URLs, the attacker has a strategic map of the WordPress installation.

Impact Assessment

Business Impact: The confidentiality breach exposes the organization's complete customer relationship data. CRM systems typically store sensitive PII including names, email addresses, phone numbers, physical addresses, purchase history, and communication logs. Unauthorized access to this data constitutes a data breach with potential regulatory implications under GDPR, CCPA, or other data protection legislation, depending on the organization's jurisdiction and the nature of the stored data.

Affected Systems: All WordPress installations running Groundhogg — CRM, Newsletters, and Marketing Automation plugin versions up to and including 4.5.2.

Blast Radius: The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) confirms:

• Attack Vector: Network — The vulnerability is exploitable remotely via the REST API
• Attack Complexity: Low — No special conditions are required beyond authentication
• Privileges Required: Low — Only the view_contacts capability is needed
• User Interaction: None — No victim interaction is required
• Confidentiality Impact: High — Complete disclosure of contact records
• Integrity Impact: None — No data modification is possible
• Availability Impact: None — No denial-of-service impact

The combination of low privileges required and high confidentiality impact makes this a particularly concerning vulnerability for organizations that rely on role-based access control to protect customer data. The EPSS score of 0.00395 (32.3% percentile) indicates a relatively low probability of exploitation in the wild, but this metric pertains to current observed exploitation and does not diminish the severity of the data exposure risk.

Detection Guidance

The following detection analytics focus on identifying the characteristic traffic patterns of sequential ID enumeration against the affected endpoint, as well as anomalously high volumes of contact record retrieval by a single authenticated user.

Sigma Rule

title: Groundhogg Contact Enumeration via REST API
id: d6f8a2b4-9c3e-4f7a-8b1d-2e5f9a1c3b7e
status: experimental
description: Detects sequential enumeration of the Groundhogg contacts REST endpoint (CVE-2026-11454)
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-11454
    - https://cwe.mitre.org/data/definitions/639.html
author: Security Analyst
date: 2025/01/28
logsource:
    category: webserver
    product: apache
    definition: Requires web server access logs or WAF logs containing URI paths and HTTP status codes
detection:
    selection:
        cs-uri-path:
            - '/wp-json/gh/v4/contacts/*'
        sc-status: 200
    timeframe: 5m
    condition: selection | count() by c-ip > 50
fields:
    - c-ip
    - cs-uri-path
    - sc-status
    - cs-username
falsepositives:
    - Legitimate CRM sync tools or plugins that bulk-read contact records
    - Administrative users performing bulk contact exports
level: medium
tags:
    - attack.t1190
    - cve.2026-11454
    - cwe.639

YARA Rule

rule Groundhogg_IDOR_Enumeration_Logs
{
    meta:
        author = "Security Analyst"
        description = "Detects log entries indicating sequential ID enumeration against Groundhogg contacts endpoint (CVE-2026-11454)"
        cve = "CVE-2026-11454"
        cwe = "CWE-639"
        date = "2025-01-28"
        severity = "high"
    strings:
        $endpoint = "/wp-json/gh/v4/contacts/" ascii nocase
        $id_pattern = /\/wp-json\/gh\/v4\/contacts\/\d{1,6}(?:\/)?\s+HTTP\/1\.[01]/ ascii
        $success = " 200 " ascii
        $user_agent_hits = "GET /wp-json/gh/v4/contacts/" ascii nocase
    condition:
        uint16(0) == 0x0A0D or uint16(0) == 0x0D0A or filesize > 0
        and any of ($endpoint, $user_agent_hits)
        and $success
        and #id_pattern >= 50
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-11454 Groundhogg Contact Enumeration Attempt"; flow:established,to_server; content:"GET"; http_method; content:"/wp-json/gh/v4/contacts/"; http_uri; pcre:"/\/wp-json\/gh\/v4\/contacts\/\d{1,6}$/U"; threshold:type=both, track=by_src, count=50, seconds=300; reference:cve,2026-11454; reference:cwe,639; classtype:attempted-recon; sid:202611454; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where dns.question.name : "*.wp-json" or http.request.body.content : "*wp-json*" ]
  [ http where http.request.method == "GET" and http.request.uri : "/wp-json/gh/v4/contacts/*" and http.response.status_code == 200 ]
  | count >= 50

Alternative simple EQL:

any where
  http.request.method == "GET" and
  http.request.uri : "/wp-json/gh/v4/contacts/*" and
  http.response.status_code == 200
| stats count = count() by source.ip
| where count >= 50

Splunk SPL Query

index=web sourcetype=access_combined
| rex field=uri_path "(?<contact_id>\d+)$" 
| where uri_path LIKE "/wp-json/gh/v4/contacts/%" 
| regex contact_id="^\d+$"
| eval id_num=tonumber(contact_id)
| stats count as req_count, earliest(_time) as first_req, latest(_time) as last_req, dc(contact_id) as unique_ids by src_ip, user
| where unique_ids > 25
| eval duration_minutes=round((last_req-first_req)/60, 2)
| table _time src_ip user unique_ids req_count duration_minutes first_req last_req
| sort - unique_ids
| rename src_ip AS "Source IP", user AS "Authenticated User", unique_ids AS "Unique Contact IDs Retrieved", req_count AS "Total Requests", duration_minutes AS "Duration (minutes)"

Wazuh OSSEC Rule

<group name="web,cve-2026-11454,attack,">
  <rule id="114540" level="10">
    <decoded>apache-accesslog</decoded>
    <match>GET /wp-json/gh/v4/contacts/</match>
    <regex>contacts/\d+ </regex>
    <description>Groundhogg contact endpoint accessed with numeric ID (CVE-2026-11454)</description>
    <mitre><id>T1190</id></mitre>
    <group>recon,accesslog</group>
    <options>no_full_log</options>
    <if_sid>31100,31101</if_sid>
  </rule>

  <rule id="114541" level="12" frequency="50" timeframe="300" ignore="60">
    <if_matched_sid>114540</if_matched_sid>
    <same_source_ip />
    <description>Potential Groundhogg contact enumeration - multiple sequential IDs requested from single source (CVE-2026-11454)</description>
    <mitre><id>T1190</id></mitre>
    <group>recon,attack,accesslog</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Status: The patch confidence is rated 0/4, indicating UNPATCHED status — no patch evidence has been identified from any tracked source. The affected version range is all versions up to and including 4.5.2. The NVD description indicates the vendor has confirmed the vulnerability exists in versions prior to 4.5.3, but no vendor patch has been publicly identified at the time of this analysis. Organizations should monitor the official Groundhogg changelog and WordPress plugin repository for a patched release.

Immediate Mitigations (apply as interim measures until a patch is available):

1. Restrict the Sales Rep role: Where possible, remove or reassign the built-in Sales Rep role if it is not actively used. If it is required, consider creating a custom role with view_contacts but restricted access, and document that the role currently has the ability to view all contacts due to this vulnerability.
2. Disable the REST endpoint: Implement a WordPress filter or a security plugin (e.g., a Web Application Firewall or WordPress security plugin with REST API restrictions) to block unauthenticated or unauthorized access to the /wp-json/gh/v4/contacts/ route. This can be done by hooking into the rest_pre_dispatch filter to return a WP_Error for this specific route.
3. Restrict API access by IP: If the CRM is used internally, restrict access to the /wp-json/gh/v4/contacts/ endpoint to known administrative IP ranges via .htaccess rules or a WAF.
4. Increase monitoring: Deploy the detection rules provided in this report to identify and alert on enumeration activity.

Patch/Upgrade Steps:

1. Monitor the WordPress plugin repository for Groundhogg — CRM, Newsletters, and Marketing Automation updates. When version 4.5.3 or later is released, update the plugin immediately through the WordPress admin dashboard (Plugins → Installed Plugins → Update) or via WP-CLI: wp plugin update groundhogg
2. After patching, verify the fix by testing the endpoint with a Sales Rep role account and confirming that the view_contact ownership check is enforced.
3. Review the plugin changelog for the specific fix details and any additional security improvements.

Long-Term Hardening:

1. Apply the principle of least privilege: periodically audit all user roles and capabilities to ensure no role has more permissions than necessary.
2. Implement a Web Application Firewall (WAF) with rules to detect and block sequential ID enumeration patterns across all API endpoints.
3. Monitor the Groundhogg security announcements and WordPress security mailing lists for advisory updates.
4. Conduct regular penetration testing of the WordPress environment, focusing on REST API endpoints and authorization logic.
5. Consider using a WordPress security plugin that provides login and API activity monitoring, rate limiting, and anomaly detection.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-11454
2. MITRE CWE-639: https://cwe.mitre.org/data/definitions/639.html
3. WordPress Plugin Repository: https://wordpress.org/plugins/groundhogg/
4. Groundhogg Official Site: https://www.groundhogg.io/

No known threat actor campaigns or exploit-in-the-wild evidence have been associated with this CVE at the time of writing. The CISA KEV catalog does not list this CVE. Public exploit code availability is unknown; no PoC or Nuclei template has been identified.