CVE-2026-18387

Executive Summary

CVE-2026-18387 is a generic SQL injection vulnerability in the Groundhogg CRM, Newsletters, and Marketing Automation plugin for WordPress, affecting all versions up to and including 4.5.14. An authenticated attacker holding at least vendor-level access can inject arbitrary SQL clauses through the tag_query parameter, abusing a legacy contact query code path that is reachable by submitting an unknown filter type such as filters[0][0][type]=force_fallback. Successful exploitation grants the attacker read access to the entire WordPress database, including password hashes, customer PII, and other sensitive records. The vulnerability currently has no vendor patch, no public exploit code, and no evidence of in-the-wild exploitation, with an EPSS score of 0.00392 indicating a low immediate exploitation likelihood.

Technical Analysis

The vulnerability resides in the Groundhogg plugin's contact query functionality. The NVD description identifies two root causes:

1. Insufficient escaping of the user-supplied tag_query parameter.
2. Lack of sufficient preparation on the existing SQL query in which the parameter is embedded.

Because the parameter value is concatenated into a SQL statement without proper parameterization, an attacker can break out of the intended query context and append arbitrary SQL syntax. The class of flaw is CWE-89 (SQL Injection), and the description explicitly characterizes it as generic SQL injection — meaning the injection point accepts a broad range of SQL syntax rather than being constrained to a narrow predicate, enabling techniques such as stacked queries or UNION-based data extraction.

A notable aspect of this CVE is the specific code path required to reach the vulnerable logic. The modern query handler normally processes contact filters. However, when an attacker submits an unknown filter type — for example filters[0][0][type]=force_fallback — the plugin raises a FilterException. This exception dispatches execution to the legacy code path, Legacy_Contact_Query, which lacks the same protections as the modern handler. The injection is then delivered through the tag_query parameter in a subsequent request or in the same request batch.

The attack surface is the WordPress admin/HTTP interface that exposes the contact query functionality to authenticated users with vendor-level privileges or higher. The plugin is a marketing automation/CRM plugin, so the vulnerable feature is likely reachable from contact-list management screens or AJAX endpoints that process filter arrays. The requirement for authentication and a vendor-level role reduces the exposure relative to unauthenticated vulnerabilities, but it also means any compromised low-privilege account (or malicious insider) with vendor access can escalate to full database read access.

The full internal architecture — including the exact SQL query structure, the function signatures within Legacy_Contact_Query, and the precise request endpoint handling the filter array — is not disclosed in the NVD description. Accordingly, technical detail beyond the named parameter (tag_query), the trigger value (filters[0][0][type]=force_fallback), the exception class (FilterException), and the fallback code path (Legacy_Contact_Query) cannot be independently verified.

Exploitation Scenarios

No public proof-of-concept is available, and no Nuclei template or exploit code has been observed. The attack chain below is therefore inferred from the vulnerability class and the specific details present in the NVD description.

Step 1 — Reconnaissance / target identification. An attacker identifies WordPress sites running the Groundhogg plugin. The plugin version can be fingerprinted via the readme.txt file in the plugin directory, the plugin asset URL (/wp-content/plugins/groundhogg/...), or WordPress page source markers. Sites running version 4.5.14 or earlier are within the affected range.

Step 2 — Obtaining vendor-level access. The attacker must authenticate as a user with vendor-level access (the Groundhogg "vendor" role or higher). Options include: compromising an existing vendor/vendor-manager account through phishing or credential stuffing; exploiting a separate credential leak; or, in insider scenarios, abusing legitimate access already held.

Step 3 — Triggering the vulnerable code path. The attacker submits a contact query request that includes an unknown filter type — filters[0][0][type]=force_fallback — causing a FilterException and redirecting execution to the Legacy_Contact_Query code path. This defeats any safe handling present in the modern query handler.

Step 4 — SQL injection via tag_query. Within the legacy path, the attacker supplies a malicious value to the tag_query parameter, e.g., tag_query=<legitimate value>' UNION SELECT ... FROM wp_users--. Because the parameter is insufficiently escaped and the surrounding query is not prepared, the injected SQL is appended to the existing query. The attacker can extract arbitrary table contents — WordPress user records (login names, password hashes), system user meta, Groundhogg CRM customer records, contact details, email lists, and other sensitive data.

Step 5 — Post-exploitation. With password hashes extracted, the attacker may attempt offline cracking. Successful recovery of an administrator credential enables full WordPress compromise, plugin/code modification, and potentially remote code execution via the theme/plugin editor. Non-credential data such as customer PII can be monetized or leveraged in further phishing campaigns.

The following should be noted explicitly: no public PoC exists, so all intermediate payload syntax above is illustrative of the SQL injection class and not a confirmed exploit string.

Impact Assessment

The CVSS v3.1 score is 6.5 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. The attack is network-based and requires no user interaction; complexity is low. The only material limitation is the need for authentication at vendor level or above.

The confidentiality subscore is High — the entire database contents are exposed to the attacker. The integrity and availability components are None, meaning this specific flaw does not directly allow data modification or denial of service; however, extracted credentials (especially wp_users password hashes) can be a stepping stone to higher-integrity attacks.

Business impact for affected organizations:

• Data breach exposure: Groundhogg is a CRM, so the database commonly contains customer names, email addresses, phone numbers, purchase history, and marketing preferences. Depending on jurisdiction, this may invoke breach-notification obligations (GDPR, CCPA).
• Credential compromise: WordPress user hashes are recoverable, enabling lateral privilege escalation within the CMS.
• Reputation / trust: A CRM data leak undermines customer trust and may trigger compliance penalties.
• Regulatory impact: Sensitive personal data is frequently stored in marketing automation DBs; exposure of such data is reportable in many jurisdictions.

Blast radius is limited to the WordPress database of the affected single installation; the plugin does not appear to introduce cross-site or supply-chain propagation. However, for WordPress multi-site deployments, a single vulnerable instance could expose a large aggregated user base.

Detection Guidance

The following detection content targets the distinctive request pattern for this CVE: the presence of the force_fallback trigger value together with SQL injection markers in the tag_query parameter. Since no public payload exists, these rules are designed around the vulnerability's unique fingerprint and are intentionally tolerant of payload variation.

Sigma Rule

title: Groundhogg CVE-2026-18387 SQL Injection via tag_query
id: 0b9c6f8e-2c3d-4e5f-8a1b-6c7d8e9f0a1b
status: experimental
description: Detects HTTP requests attempting to trigger the Groundhogg Legacy_Contact_Query SQL injection using the force_fallback filter and tag_query parameter.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-18387
author: Valters IT Threat Intelligence
date: 2026/06/01
logsource:
    category: webserver
    definition: Web server access logs (Apache/nginx) or WAF/HTTP proxy logs with URL query string fields mapped to cs-uri-query.
detection:
    selection_trigger:
        cs-uri-query|contains:
            - "filters[0][0][type]=force_fallback"
            - "filters%5B0%5D%5B0%5D%5Btype%5D=force_fallback"
    selection_target:
        cs-uri-query|contains:
            - "tag_query="
            - "tag_query%3D"
    selection_payload:
        cs-uri-query|contains|any:
            - "UNION"
            - "SELECT"
            - "SLEEP("
            - "WAITFOR"
            - "INFORMATION_SCHEMA"
            - "0x"          # hex-encoded payload marker
            - "%27"         # URL-encoded single quote
    condition: selection_trigger and selection_target and selection_payload
    falsepositives:
        - Legitimate Groundhogg queries that coincidentally include the string "SELECT" in a tag name (rare).
    level: high

YARA Rule

rule CVE_2026_18387_Groundhogg_SQLi {
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Detects evidence of CVE-2026-18387 exploitation: Groundhogg tag_query SQL injection with force_fallback trigger."
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-18387"
        cve = "CVE-2026-18387"
        date = "2026-06-01"
    strings:
        $trigger_a = "filters[0][0][type]=force_fallback" ascii nocase
        $trigger_b = "filters%5B0%5D%5B0%5D%5Btype%5D=force_fallback" ascii nocase
        $param_a   = "tag_query=" ascii nocase
        $param_b   = "tag_query%3D" ascii nocase
        $sql_union = "UNION" ascii nocase
        $sql_sel   = "SELECT" ascii nocase
        $sql_sleep = "SLEEP(" ascii nocase
        $sql_wait  = "WAITFOR" ascii nocase
        $sql_schema= "INFORMATION_SCHEMA" ascii nocase
        $quote     = "%27" ascii
    condition:
        (any of ($trigger*) and any of ($param*)) and
        (any of ($sql_union, $sql_sel, $sql_sleep, $sql_wait, $sql_schema) or $quote)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2026-18387 Groundhogg WordPress SQL Injection (tag_query)";
    flow:established,to_server;
    http.uri;
    content:"force_fallback"; nocase;
    content:"tag_query"; nocase; distance:100;
    pcre:"/tag_query(=|%3d)[^&]*?(union|select|sleep\s*\(|waitfor|information_schema|0x|%27)/i";
    reference:cve,2026-18387;
    classtype:web-application-attack;
    sid:202618387;
    rev:1;
)

Elastic Detection

any where
  event.category == "web" and
  url.query != null and
  url.query contains "force_fallback" and
  url.query contains "tag_query" and
  (
    url.query contains "UNION" or
    url.query contains "union" or
    url.query contains "SLEEP" or
    url.query contains "WAITFOR" or
    url.query contains "INFORMATION_SCHEMA" or
    url.query contains "%27"
  )

Splunk SPL Query

index=web* sourcetype=access_combined
    ("filters[0][0][type]=force_fallback" OR "filters%5B0%5D%5B0%5D%5Btype%5D=force_fallback")
    ("tag_query=" OR "tag_query%3D")
    (UNION OR SLEEP( OR WAITFOR OR INFORMATION_SCHEMA OR "%27")
| eval indicator="CVE-2026-18387-tag_query-sqli"
| stats count min(_time) max(_time) values(uri) as uris by src_ip, host, indicator
| where count >= 1
| sort - count

Wazuh OSSEC Rule

<group name="web_application_attack,sql_injection,">
  <rule id="100387" level="12">
    <decoded>apache-accesslog</decoded>
    <match>filters[0][0][type]=force_fallback|filters%5B0%5D%5B0%5D%5Btype%5D=force_fallback</match>
    <regex>tag_query(=|%3d).*(UNION|SELECT|SLEEP|WAITFOR|INFORMATION_SCHEMA|%27)</regex>
    <description>Possible CVE-2026-18387 Groundhogg SQL injection attempt detected via tag_query parameter.</description>
    <group>web_application_attack,sql_injection,pci_dss_6.5,gdpr_32,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source, no fixed version has been released, and no vendor workaround has been published. The following actions are recommended in the interim.

Immediate mitigations:

1. Restrict vendor-level access. Audit all WordPress users with Groundhogg vendor/vendor-manager roles. Remove unnecessary accounts, enforce MFA, and rotate passwords for any account that might have been exposed in prior credential leaks. If vendor-level users are not essential, demote them to subscriber-level roles.
2. Web Application Firewall (WAF) rules. Deploy virtual-patch rules blocking requests that combine the force_fallback trigger and the tag_query parameter, or that contain obvious SQL metacharacters (', UNION, SELECT, SLEEP, etc.) in tag_query. Both raw and URL-encoded variants should be covered.
3. Monitor for the trigger pattern. Enable alerting on filters[*][*][type]=force_fallback in web access logs. This value is not expected in legitimate contact-query traffic.
4. Database least privilege. Ensure the WordPress database account used by the application cannot access other databases and lacks FILE and SUPER privileges. A dedicated reader role with only SELECT/INSERT/UPDATE/DELETE on the WordPress schema limits damage if injection occurs.

Patch / upgrade steps:

• No patched version is currently available. Monitor the WordPress plugin repository (wordpress.org/plugins/groundhogg) and the vendor's site for a release newer than 4.5.14, and upgrade immediately upon publication.
• Prior to upgrading, validate the new version changelog contains a fix referencing Legacy_Contact_Query, tag_query, and FilterException.
• If the vendor never releases a fix, plan a permanent replacement of the plugin or a full removal if the CRM data can be migrated to an alternative solution.

Long-term hardening:

• Adopt a plugin vulnerability-scanning workflow (e.g., WPScan, Patchstack, or commercial equivalents) to detect this and similar plugin flaws early.
• Implement a periodic credential review for all WordPress roles, especially roles that provide access to customer-facing CRM functionality.
• Take regular encrypted backups of the database and store them offline; verify restore procedures.
• Run WordPress with a restrictive file permissions policy and disable file editing in wp-config.php to prevent post-exploitation code modification.
• If the organization is subject to compliance frameworks, treat CRM data as regulated personal data and apply compensating controls (encryption at rest, access logging, anomaly detection).

References

1. NVD Entry for CVE-2026-18387 — https://nvd.nist.gov/vuln/detail/CVE-2026-18387
2. WordPress Plugin Directory — Groundhogg — https://wordpress.org/plugins/groundhogg/
3. MITRE CWE-89: SQL Injection — https://cwe.mitre.org/data/definitions/89.html
4. OWASP SQL Injection Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
5. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-18387 is NOT listed as of this report) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat-actor campaigns, exploit-in-the-wild evidence, or third-party researcher analyses are publicly available for CVE-2026-18387 at the time of writing. The vulnerability is absent from the CISA KEV catalog, and no public proof-of-concept, Nuclei template, or Metasploit module has been observed. EPSS places the likelihood of exploitation in the near term at 0.39% (32.3rd percentile of scored CVEs), which is below average. Analyst recommendation: treat as a moderate-priority risk requiring prompt remediation once a patch ships, with compensating WAF controls applied now.