CVE-2026-76273

Executive Summary

CVE-2026-76273 is an input validation weakness (CWE-20) in Splunk Enterprise in which the collect Search Processing Language (SPL) command fails to validate an index name before processing it, allowing a user who holds a role with the run_collect capability to inject attacker-controlled content into system-level messages on the Splunk instance. Exploitation requires an authenticated account with the run_collect capability and network reachability to the Splunk management or search interface; the CVSS 3.1 score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), reflecting a low-integrity impact with no confidentiality or availability impact. The practical risk is integrity abuse of platform messaging, which can be leveraged for content spoofing, misleading operators, or as a foothold for follow-on social engineering against Splunk administrators.

Technical Analysis

The vulnerability resides in the collect SPL command. Per the vendor description, the command "does not validate the index name before processing the value." An index name is a user-supplied argument to the command; because the value is not validated prior to processing, a caller holding the run_collect capability can supply content that is subsequently written into "system-level messages on the Splunk platform instance."

Two properties of the flaw drive its security significance. First, the trust boundary is crossed at the search-command layer: search-time input normally flows into indexer/search results, but here unvalidated input reaches a system message channel that is read by administrators and possibly surfaced in REST system endpoints. Second, the authorization gate is a capability (run_collect) rather than a privileged platform role — any role granted this capability inherits the attack surface, which in many deployments extends well beyond platform administrators.

The root cause class is improper input validation: insufficient allow-listing or canonicalization of the index name before it is used in a processing path that emits system-level messages. Because the description does not disclose the exact encoding, transformation, or storage mechanism, the precise injection semantics — whether the attacker-controlled content appears as an index identifier verbatim, as a message field, or via a parsing side effect — cannot be stated with certainty. What is determinate is the class: unvalidated user input reaching a message-generation sink.

Impact per the CVSS vector is integrity-only and low (C:N/I:L/A:N). There is no evidence in the provided data of remote code execution, privilege escalation, authentication bypass, or data exfiltration. The exploitability subscore is favorable to an attacker (AV:N/AC:L/PR:L/UI:N), and the missing user-interaction requirement means an attacker with a suitable session does not need to induce any administrator action to trigger the write.

The affected surface is the collect command across Splunk Enterprise branches: versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15. Because the flaw is in the search command layer, any interface that can submit SPL to the instance — the search UI, the REST search job endpoints, or programmatic API clients — is a potential vector, provided the authenticated principal holds run_collect.

Exploitation Scenarios

No public proof-of-concept, Nuclei template, or exploit code is known. The attack chain below is inferred from the vulnerability class (CWE-20, missing index-name validation in the collect command) and the explicit authorization prerequisite stated by the vendor.

1. Reconnaissance and target identification. The attacker identifies a Splunk Enterprise instance at a vulnerable version level and determines whether the acquired account holds the run_collect capability. Capability assignment is visible in role definitions, and the vendor references "Define roles on the Splunk platform with capabilities" as the relevant configuration surface. An attacker with existing low-privilege credentials — a compromised analyst account, a service account, or a mis-scoped integration — can check whether collect executes within their authorization context.

2. Triggering the flaw class. With an authenticated session, the attacker invokes the collect SPL command and supplies an index name value that is not constrained by validation. Because the command does not validate the index name before processing it, the crafted value is accepted and flows into the system-level message path on the instance. The attacker-controlled content is therefore written into a channel the platform treats as system messaging.

3. Payload and execution method at the class level. The payload is data, not code: attacker-controlled text delivered as the index name argument. There is no evidence in the description of code execution, template expansion, or command substitution. The weaponization value is therefore content injection and integrity abuse — planting attacker-controlled strings inside messages that operators consume.

4. Post-exploitation impact. The injected content persists in system-level messaging (subject to the platform's message lifetime and retention behavior, which is not disclosed). Attackers can use controlled content in operator-visible messages for social engineering: fabricating security warnings, impersonating administrative notices, embedding misleading links or instructions, or degrading trust in the platform's own telemetry. Because the change is confined to messaging integrity, the immediate blast radius is human rather than machine, but it can become a pivot for credential phishing aimed at Splunk administrators or for disruption of incident-response decision-making. The REST "System endpoint descriptions" documentation referenced by the vendor indicates the class of administrative interfaces where such messages may be surfaced.

Risk is materially gated by two factors: whether non-administrative roles in a given deployment possess run_collect (common in custom roles built for data onboarding or summary operations), and whether the injected message content is later surfaced to a privileged human or automation pipeline.

Impact Assessment

Business impact is bounded but non-trivial. CVSS 3.1 base 4.3 with AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N characterizes a low-severity integrity issue: no data disclosure, no service interruption, no scope change. The integrity impact is "Low" because the attacker can modify some system data (messages) but not protected security-relevant records in a way that directly grants control.

Affected systems: Splunk Enterprise deployments on the four vulnerable release branches listed above, specifically any instance where at least one role grants run_collect to a principal the attacker can control or obtain. Environments that withheld this capability from non-privileged roles reduce exposure but are still affected at the code level and should upgrade.

Blast radius considerations:

• Multi-tenant or MSSP deployments where many customers or internal teams hold search accounts are at greater risk because the population of possible run_collect holders is larger.
• SOC environments are disproportionately sensitive to messaging integrity: fabricated system messages can cause analysts to chase false leads, suppress real alerts, or follow attacker-authored instructions.
• Automation pipelines that parse administrative messages could be misled or, in poorly built cases, act on injected content. No evidence in the provided data supports automated exploitation of downstream consumers, and this should be treated as a hardening concern rather than a confirmed capability.

EPSS is 0.00166 (5.3rd percentile), and the CVE is not in CISA KEV, consistent with the absence of public exploit code and the low severity rating. The immediate operational priority is capability hygiene plus upgrade, not emergency response.

Detection Guidance

Detection for this CVE centers on two planes: (a) SPL/audit telemetry showing misuse of the collect command with anomalous index-name values, and (b) message-integrity monitoring of system-level messages. Because the flaw is an input-validation error rather than a network signature with a stable byte pattern, network-layer rules must target the SPL submission path (search job REST calls) and will be low-fidelity by design.

Sigma Rule

title: Splunk collect Command Abuse - Potential Index Name Validation Bypass (CVE-2026-76273)
id: 3f1a9c2e-5b7d-4c21-9a8e-0d6f4b2c7e10
status: experimental
description: Detects execution of the Splunk collect SPL command where a user-supplied index value may be unvalidated, per CVE-2026-76273. Requires audit or search-job telemetry.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-76273
author: Valters IT Threat Intelligence
date: 2026/01/01
logsource:
  product: splunk
  service: audit
detection:
  selection_command:
    action: 'search'
    search|contains: '| collect'
  selection_suspicious_index:
    search|contains:
      - 'index="'
      - 'index=..'
      - 'index=$'
      - 'index=%'
      - 'index=<'
      - 'index=*'
  filter_known_automation:
    user|endswith:
      - '-svc'
      - '-service'
  condition: selection_command and selection_suspicious_index and not filter_known_automation
falsepositives:
  - Legitimate summary indexing and data onboarding jobs using collect with dynamic index naming
  - Automated saved searches that template index names
level: medium
tags:
  - attack.t1059
  - cve.2026.76273

YARA Rule

rule CVE_2026_76273_Splunk_Collect_Abuse
{
    meta:
        description = "Detects references to Splunk collect command with suspicious index-name constructs in logs or stored search artifacts"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76273"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $collect = "| collect" ascii wide nocase
        $collect2 = "collect index=" ascii wide nocase
        $idx_quote = "index=\"" ascii wide
        $idx_angle = "index=<" ascii wide
        $idx_pct = "index=%" ascii wide
        $idx_dollar = "index=$" ascii wide
        $idx_dotdot = "index=.." ascii wide

    condition:
        $collect or $collect2 and any of ($idx_*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-76273 Splunk collect SPL Command with Anomalous Index Value - Possible Index Name Validation Bypass"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/services/search/jobs"; http.request_body; content:"|7C| collect"; http.request_body; pcre:"/index\s*=\s*[\x22\x3c\x25\x24\x2e]{1,2}/Ri"; classtype:attempted-user; reference:cve,2026-76273; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-76273; metadata:affected_product Splunk_Enterprise, attack_target Server, deployment Perimeter, signature_severity Minor, created_at 2026_01_01; sid:202676273; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.category == "authentication" and event.outcome == "success" ]
  [ any where process.command_line : "*| collect*" and process.command_line : ("index=\"*" or "index=<*" or "index=%*" or "index=..*") ]

Splunk SPL Query

index=_audit action=search
| search search="*| collect*"
| rex field=search "collect\s+(?<collect_args>.+)$"
| eval idx_arg = coalesce(collect_args, search)
| where match(idx_arg, "index\s*=\s*[\"<%\$.]{1,2}")
| stats count min(_time) as firstTime max(_time) as lastTime values(search) as searches by user, idx_arg, src
| convert ctime(firstTime) ctime(lastTime)
| sort - count

Companion message-integrity hunt: enumerate recent system-level messages and flag any whose content includes unexpected index identifiers or operator-instruction-like phrasing.

index=_internal (sourcetype=splunkd OR sourcetype=splunk_web_service) ("system message" OR "system_message")
| where match(_raw, "\| collect|collect index=")
| stats count by host, sourcetype, _raw

Wazuh OSSEC Rule

<group name="splunk,cve_2026_76273,">
  <rule id="202676273" level="8">
    <decoded_as>json</decoded_as>
    <field name="search">\.collect</field>
    <description>CVE-2026-76273: Splunk collect SPL command executed - possible index name validation bypass</description>
    <mitre>
      <id>T1059</id>
    </mitre>
    <options>no_full_log</options>
  </rule>

  <rule id="202676274" level="10">
    <if_sid>202676273</if_sid>
    <field name="search" type="pcre2">index\s*=\s*[\"&lt;%\$\.]{1,2}</field>
    <description>CVE-2026-76273: Splunk collect invoked with anomalous index value - probable exploitation attempt</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Affected ranges per the vendor description: Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15. No vendor workaround is published in the provided data.

1. Immediate mitigations

• Capability hygiene: audit every role for the run_collect capability and remove it from roles that do not operationally require summary indexing, data onboarding, or collect-based workflows. This is the single most effective exposure reduction because authorization is the binding constraint on the vulnerability.
• Least privilege on API accounts: identify service accounts and integrations holding run_collect and confirm each is scoped to a dedicated, non-interactive principal. Rotate credentials for any such account whose activity cannot be explained.
• Segment management access: restrict access to the search/REST interfaces to trusted administrative networks and enforce MFA on all Splunk-authenticated accounts.
• Monitor rather than block: until a patch is confirmed deployed, run the detection queries above in alert mode; collect is a legitimate command and blanket blocking risks breaking summary indexing.

2. Patch/upgrade steps

• Track the Splunk security advisory page for the fixed releases: 10.4.3, 10.2.7, 10.0.10, and 9.4.15. No vendor advisory URL or CVE-to-fix mapping confirmation is available in the provided data, so validate the fix against the official Splunk security advisory before relying on it.
• Upgrade to the fixed release on the appropriate maintenance branch for each instance (search heads, indexers, heavy forwarders, and management components running the affected code).
• Because the code-level flaw is not remediated by configuration, configuration changes are compensating controls only; treat upgrade as the only durable fix.
• After upgrading, re-verify that run_collect remains restricted where it is not required, and re-run the detection queries to establish a clean baseline.

3. Long-term hardening

• Establish a capability-review process so that run_collect and similarly powerful search capabilities are granted only through a documented approval path and reviewed on a recurring schedule.
• Monitor integrity of system-level messaging as a standing control, not a reactive one; operator-visible messages are a social-engineering surface and should be baselined for unexpected content.
• Enforce role separation between search users and platform administrators so that injected content cannot be paired with an administrative context in the same session.
• Keep Splunk Enterprise on a supported maintenance branch with a defined patch SLA, and subscribe to Splunk security advisories so that advisories like this one are triaged within hours rather than discovered during unrelated work.
• Extend input-validation review to custom SPL saved searches and macros that pass user-controlled values into commands that write to internal or system channels.

References

• National Vulnerability Database — CVE-2026-76273: https://nvd.nist.gov/vuln/detail/CVE-2026-76273
• Splunk documentation — collect search command: https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/10.4/search-commands/collect
• Splunk documentation — Define roles on the Splunk platform with capabilities: https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities
• Splunk documentation — System endpoint descriptions (REST API): https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.4/system-endpoints/system-endpoint-descriptions
• CWE-20: Improper Input Validation — https://cwe.mitre.org/data/definitions/20.html

Threat actor and exploitation status: no public PoC, Nuclei template, or exploit code is known; the CVE is not listed in CISA KEV (as of the data provided). EPSS is 0.00166 (5.3rd percentile), indicating a low modeled probability of exploitation in the near term. No campaign, actor, or in-the-wild exploitation reporting is available for this CVE.