CVE-2026-76270

Executive Summary

CVE-2026-76270 is a SQL injection vulnerability (CWE-89) in Splunk Enterprise and Splunk Cloud Platform SPL2 module filtering, affecting versions below 10.4.3. Any authenticated user holding a role with the list_spl2_modules capability can exploit the flaw to access all data reachable through the affected REST API, including private SPL2 module definitions owned by other users. The root cause is that Splunk does not parameterize user-supplied values before embedding them in database queries for SPL2 module filtering.

Technical Analysis

The vulnerability resides in the SPL2 module filtering functionality exposed through a Representational State Transfer (REST) API endpoint. SPL2 modules are reusable search artifacts; module permissions are governed by role capabilities, and the list_spl2_modules capability is intended to allow a user to enumerate SPL2 modules to which the user should legitimately have access. According to the NVD description, the affected REST API accepts user-supplied input for filtering SPL2 modules and passes that value, unparameterized, into a database query. Because the value is concatenated (or otherwise interpreted) as SQL rather than bound as a parameter, an attacker who controls the filter value can alter the semantics of the underlying query.

The privilege model is the key constraint and the key amplifier. The flaw does not grant unauthenticated access; it requires an authenticated principal with a role that holds the list_spl2_modules capability. This is a low-privilege requirement in most Splunk deployments, since SPL2 module management is a common feature for power users. The confidentiality impact is rated High (C:H) and the integrity and availability impacts are None (I:N/A:N), which is consistent with a read-only SQL injection primitive: the attacker can manipulate a SELECT-style filtering query to return rows from other users' module definitions (and other data reachable through the affected REST API) but is not described as able to write, modify, or delete data.

Two aspects of the description are important for precision. First, the exposure is bounded by what the affected REST API can reach: the description states access to "all relevant data available through the affected REST API," including private SPL2 module definitions belonging to other users. It does not claim full database compromise or arbitrary table reads across the entire Splunk instance. Analysts should not overstate the blast radius. Second, the flaw is described as affecting both Splunk Enterprise (below 10.4.3) and Splunk Cloud Platform; the explicitly unaffected Enterprise branches are 10.2.x, 10.0.x, and 9.4.x. The network attack vector is applicable (AV:N) and no user interaction beyond the attacker's own authenticated actions is required (UI:N), with attack complexity rated Low (AC:L).

No public proof-of-concept, exploit code, or Nuclei template is known for this CVE, and the EPSS score is very low (0.00245, roughly the 14th percentile of exploited CVEs), indicating that exploitation in the wild has not been observed or widely anticipated at the time of writing.

Exploitation Scenarios

1. Reconnaissance / target identification: The attacker identifies an internet-exposed or internally reachable Splunk Enterprise or Splunk Cloud Platform deployment. Because exploitation requires authentication, the attacker must first obtain valid credentials — for example, via phishing, credential stuffing, reuse of leaked credentials, or a low-privileged account provisioned for legitimate use. The attacker then verifies that their role holds the list_spl2_modules capability, which is the minimum precondition for reaching the vulnerable filter path. Shodan-style reconnaissance (e.g., product:"Splunk", http.title:"Splunk", port:8089) can identify candidate management interfaces, though authentication still gates exploitation.

2. Triggering the flaw class (SQL injection): The attacker issues a request to the SPL2 module filtering REST API, supplying a crafted value in the module-filter input. Because Splunk does not parameterize this value before using it in the database query, SQL metacharacters and boolean/union-style constructs in the filter alter the query's logic. This is the classic CWE-89 pattern: user-controlled data crosses from the request into a query string without binding. No specific endpoint path or parameter name is disclosed in the NVD description, so the exact request shape should be confirmed by inspecting the deployed SPL2 module listing API in a lab environment.

3. Payload / execution method at the vulnerability-class level: The attacker iteratively submits filter values that (a) confirm injectability (e.g., truthy/falsy condition changes reflected in the response) and (b) widen the result set returned by the filtering query. The objective is to cause the query to return rows the requester is not entitled to see — specifically, private SPL2 module definitions owned by other users. No public PoC is available; the attack chain is inferred from the vulnerability class (SQL injection in an unparameterized filter) and the stated impact (read access to data reachable via the affected REST API).

4. Post-exploitation impact: Successful exploitation yields read access to other users' private SPL2 module definitions and other data reachable through the affected REST API. Because SPL2 module definitions can contain search logic, references, and potentially embedded configuration, this represents an information-disclosure risk that can support follow-on activity: module contents may reveal internal data sources, naming conventions, or credentials embedded in search definitions, enabling lateral movement or more targeted searches. There is no evidence in the description of write capability, so persistence and data destruction are not described impacts.

Impact Assessment

The CVSS 3.1 base score is 6.5 (Medium). Subscores: AV:N (remotely reachable), AC:L (no special conditions), PR:L (valid low-privileged account with list_spl2_modules required), UI:N (no victim interaction), S:U (impact confined to the vulnerable component), C:H / I:N / A:N (high confidentiality loss only). Business impact is primarily data confidentiality: leakage of SPL2 module definitions and other data reachable via the affected REST API may expose proprietary search logic, internal data-source names, and potentially sensitive embedded values. Blast radius is bounded by the permissions of the REST API and the SQL query path, not the entire Splunk configuration store. However, note the privilege boundary: any user with a role carrying list_spl2_modules is a viable attacker, which in many organizations includes a broad set of search users. The lack of known exploitation and the low EPSS score reduce urgency relative to actively exploited CVEs, but the low privilege requirement and the pre-authentication-free (for authenticated users) nature of the flaw warrant prioritization in environments with large SPL2 user populations or internet-exposed search heads.

Detection Guidance

Sigma Rule

title: Potential SQL Injection in Splunk SPL2 Module Filtering (CVE-2026-76270)
id: 7c2f1e9a-4b3d-4f6e-9a21-cve202676270
status: experimental
description: Detects SQL metacharacter patterns against Splunk SPL2 module filtering REST API requests.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-76270
author: Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
  product: splunk
detection:
  selection_uri:
    cs-uri-query|contains:
      - 'list_spl2'
      - 'spl2_module'
      - 'module_filter'
  selection_sqli:
    cs-uri-query|contains:
      - "'"
      - 'UNION'
      - 'SELECT'
      - 'OR 1=1'
      - '--'
      - '/*'
  condition: selection_uri and selection_sqli
falsepositives:
  - Legitimate module names containing apostrophes
level: high

YARA Rule

rule CVE_2026_76270_Splunk_SPL2_SQLi
{
    meta:
        description = "Detects SQL injection payloads targeting Splunk SPL2 module filtering (CVE-2026-76270)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76270"
        cve = "CVE-2026-76270"
        severity = "high"
    strings:
        $sqli1 = "list_spl2_modules" nocase ascii wide
        $sqli2 = "spl2" nocase ascii wide
        $pat1 = "UNION SELECT" nocase ascii wide
        $pat2 = "OR 1=1" nocase ascii wide
        $pat3 = "' OR '" nocase ascii wide
        $pat4 = "sleep(" nocase ascii wide
    condition:
        any of ($sqli1, $sqli2) and any of ($pat1, $pat2, $pat3, $pat4)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-76270 Splunk SPL2 module filtering SQL injection attempt"; flow:established,to_server; http.uri; content:"spl2"; nocase; http.uri; content:"module"; nocase; http.uri; pcre:"/(%27|'|\bUNION\b|\bSELECT\b|OR\+1%3D1|\bOR 1=1\b|--)/i"; classtype:web-application-attack; reference:cve,2026-76270; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-76270; sid:2026762700; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ authentication where event.outcome == "success" and source.ip != null ]
  [ network where network.protocol == "http" and
      url.path : "*spl2*" and
      url.query : ("*UNION*" or "*SELECT*" or "* OR 1=1*" or "*%27*" or "*--*") ]

Splunk SPL Query

index=_internal sourcetype=splunkd_web_access
| where match(uri_query, "(?i)(union[\s\+]+select|or[\s\+]+1=1|%27|'|--|/\*)")
| where match(uri_path, "(?i)spl2")
| stats count min(_time) as first_seen max(_time) as last_seen values(clientip) as src_ips by user, uri_path, uri_query
| where count > 0
| sort - count

Recommended Splunk-side telemetry note: Because the vulnerable component is Splunk itself, run the SPL query above against _internal web-access logs (sourcetype splunkd_web_access) and REST activity logs (sourcetype splunkd_rest / splunkd_access) on the search head tier. Also alert on anomalous list_spl2_modules REST calls returning unexpectedly large result counts per user.

Wazuh OSSEC Rule

<group name="splunk,web,sql_injection,">
  <rule id="202676" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">\.*spl2.*</field>
    <regex type="pcre2">(?i)(union\s+select|or\s+1=1|%27|'|\-\-) </regex>
    <description>CVE-2026-76270: Possible SQL injection attempt against Splunk SPL2 module filtering</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web_attack,sql_injection,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (compensating controls while awaiting vendor patch artifact):

• Restrict the list_spl2_modules capability to the smallest possible set of trusted roles; remove it from broad power-user or search-user roles.
• If the SPL2 module listing REST API is not required, disable or restrict access to the relevant REST endpoint via role-based capability removal and network ACLs.
• Place the search head / management interface behind a reverse proxy or WAF and enable SQL-injection signatures; restrict access to trusted management networks only. Do not expose the Splunk REST API (/services, default management port 8089) to the internet.
• Enforce strong authentication and MFA; rotate credentials of any account holding list_spl2_modules, since exploitation requires authenticated access.
• Monitor _internal web-access and REST logs for SQL metacharacters in SPL2-related requests.

2. Patch/upgrade steps:

• NVD identifies Splunk Enterprise 10.4.3 as the fixed release. Upgrade affected Splunk Enterprise deployments below 10.4.3 to 10.4.3 or later once the vendor advisory and download artifacts are confirmed through official Splunk channels.
• For Splunk Cloud Platform, coordinate with Splunk Support / your cloud account team; customers cannot self-upgrade the cloud service.
• No vendor fix reference (Vendor Fix: N/A) and no workaround reference (Workarounds: N/A) were provided in the ingested intelligence. Validate the availability and integrity of the fix against the official Splunk security advisory before deploying.
• Explicitly note: versions 10.2.x, 10.0.x, and 9.4.x are stated as NOT affected; do not apply unnecessary emergency changes to those branches.

3. Long-term hardening:

• Adopt least-privilege role design for all Splunk capabilities, especially those that reach REST APIs backed by database queries.
• Maintain an inventory of Splunk search heads and their exposure; ensure management interfaces are never internet-facing.
• Add regression testing / synthetic canary checks for input-validation controls on REST API filters in CI and change-management processes.
• Track Splunk security advisories and subscribe to vendor notifications; treat Splunk infrastructure as a high-value target given the sensitivity of indexed data.

References

• NVD — CVE-2026-76270: https://nvd.nist.gov/vuln/detail/CVE-2026-76270
• Splunk Documentation — Manage SPL2 modules: https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules
• Splunk Documentation — Module permissions: https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions
• CWE-89 — Improper Neutralization of Special Elements used in an SQL Command: https://cwe.mitre.org/data/definitions/89.html
• CISA Known Exploited Vulnerabilities Catalog (not listed as of the intelligence cutoff — verify current status): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild status: No public PoC, no exploit code, and no Nuclei template are known for CVE-2026-76270. The CVE is not listed in CISA KEV, and the EPSS score (0.00245, ~14.4th percentile) indicates no observed exploit activity; no named threat actor campaigns are associated with this CVE in the provided intelligence.