CVE-2026-76341: Splunk Enterprise stored SPL

CISO Take

A Splunk user holding the 'power' role can plant attacker-controlled Search Processing Language inside a shared Table Editor dataset that silently executes with 'admin' privileges the moment an administrator opens it in the browser, bypassing Splunk's normal SPL safeguards for risky commands. This is not an AI/ML-specific flaw — Splunk Enterprise itself isn't an AI package — but it matters to CISOs running Splunk as the SIEM/observability backbone that ingests logs from AI agents, model-serving endpoints, or MLOps pipelines, since a compromised admin session there can expose or tamper with monitoring data used for AI security detection. There's no EPSS score, no CISA KEV listing, no public exploit or Nuclei template, and exploitation requires social engineering (UI:R) plus a specific two-role setup, which caps real-world urgency at moderate rather than critical. Patch to Splunk Enterprise 10.4.2, 10.2.6, 10.0.9, or 9.4.14 (whichever release line applies), and in the interim restrict who holds the 'power' role and review recently shared Table Editor datasets for embedded SPL before any admin opens them.

Sources: NVD vendor advisory (advisory.splunk.com)

What is the risk?

Medium severity (CVSS 5.4, AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N). Exploitability is constrained by a real-world combination of factors: the attacker needs an existing 'power' role account, must craft SPL that evades the Table Editor's safeguard gap, and must successfully phish an 'admin' into opening the shared dataset in their browser. There is no EPSS data, no evidence of active exploitation, no CISA KEV listing, and no public PoC or scanner signature — all of which lower near-term exploitation likelihood despite the high confidentiality impact if successful. The realistic risk is concentrated in multi-tenant or internally-shared Splunk deployments where the 'power' role is broadly granted (common in large SOC/analytics teams), rather than in tightly-scoped single-admin instances.

How does the attack unfold?

Initial access via role abuse

An attacker with a 'power' Splunk role crafts a Table Editor dataset whose initial data embeds SPL that bypasses risky-command safeguards.

Social engineering / phishing

The attacker shares the poisoned dataset and induces a Splunk 'admin'-role user to open it in the Table Editor via their browser.

AML.T0011

Privileged execution

Opening the dataset triggers the embedded SPL, which runs silently with the admin's full search-head permissions.

AML.T0050

Impact: data exposure and limited tampering

The attacker gains read access to all relevant indexed data and can make limited modifications on the search head under the admin's identity.

Initial access via role abuse

An attacker with a 'power' Splunk role crafts a Table Editor dataset whose initial data embeds SPL that bypasses risky-command safeguards.

Social engineering / phishing

The attacker shares the poisoned dataset and induces a Splunk 'admin'-role user to open it in the Table Editor via their browser.

AML.T0011

Privileged execution

Opening the dataset triggers the embedded SPL, which runs silently with the admin's full search-head permissions.

AML.T0050

Impact: data exposure and limited tampering

The attacker gains read access to all relevant indexed data and can make limited modifications on the search head under the admin's identity.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Splunk Enterprise	—	—	No patch

Do you use Splunk Enterprise? You're affected.

How severe is it?

CVSS 3.1

5.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR Low

UI Required

S Unchanged

C High

I Low

A None

What should I do?

1 step

1) Patch Splunk Enterprise to 10.4.2, 10.2.6, 10.0.9, or 9.4.14 depending on your release line, per the vendor advisory SVD-2026-0801. 2) Until patched, restrict the 'power' role to trusted users only and avoid granting it broadly across analytics/SOC teams. 3) Audit existing Table Editor datasets for embedded SPL using risky commands before any 'admin'-role user opens them, especially datasets shared by 'power' users. 4) Review Splunk's 'SPL safeguards for risky commands' documentation and consider tightening the capability model per 'Define roles on the Splunk platform with capabilities'. 5) For detection, monitor for unexpected SPL execution patterns (data export, sensitive lookups, config changes) immediately following an admin opening a shared Table Editor dataset. 6) No workaround fully closes the gap short of patching, since the vulnerability lies in how the Table Editor prepares initial data, not in a configurable safeguard.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Code Execution Social Engineering Training Data AML.T0011 - User Execution AML.T0050 - Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE-4 - AI system risks and benefits are monitored and evaluated post-deployment

Frequently Asked Questions

What is CVE-2026-76341?

A Splunk user holding the 'power' role can plant attacker-controlled Search Processing Language inside a shared Table Editor dataset that silently executes with 'admin' privileges the moment an administrator opens it in the browser, bypassing Splunk's normal SPL safeguards for risky commands. This is not an AI/ML-specific flaw — Splunk Enterprise itself isn't an AI package — but it matters to CISOs running Splunk as the SIEM/observability backbone that ingests logs from AI agents, model-serving endpoints, or MLOps pipelines, since a compromised admin session there can expose or tamper with monitoring data used for AI security detection. There's no EPSS score, no CISA KEV listing, no public exploit or Nuclei template, and exploitation requires social engineering (UI:R) plus a specific two-role setup, which caps real-world urgency at moderate rather than critical. Patch to Splunk Enterprise 10.4.2, 10.2.6, 10.0.9, or 9.4.14 (whichever release line applies), and in the interim restrict who holds the 'power' role and review recently shared Table Editor datasets for embedded SPL before any admin opens them.

Is CVE-2026-76341 actively exploited?

No confirmed active exploitation of CVE-2026-76341 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-76341?

1) Patch Splunk Enterprise to 10.4.2, 10.2.6, 10.0.9, or 9.4.14 depending on your release line, per the vendor advisory SVD-2026-0801. 2) Until patched, restrict the 'power' role to trusted users only and avoid granting it broadly across analytics/SOC teams. 3) Audit existing Table Editor datasets for embedded SPL using risky commands before any 'admin'-role user opens them, especially datasets shared by 'power' users. 4) Review Splunk's 'SPL safeguards for risky commands' documentation and consider tightening the capability model per 'Define roles on the Splunk platform with capabilities'. 5) For detection, monitor for unexpected SPL execution patterns (data export, sensitive lookups, config changes) immediately following an admin opening a shared Table Editor dataset. 6) No workaround fully closes the gap short of patching, since the vulnerability lies in how the Table Editor prepares initial data, not in a configurable safeguard.

What systems are affected by CVE-2026-76341?

This vulnerability affects the following AI/ML architecture patterns: SIEM/observability platforms ingesting AI/ML telemetry, MLOps and AI security monitoring pipelines routed through Splunk.

What is the CVSS score for CVE-2026-76341?

CVE-2026-76341 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.23%.

What is the AI security impact?

Affected AI Architectures

SIEM/observability platforms ingesting AI/ML telemetryMLOps and AI security monitoring pipelines routed through Splunk

MITRE ATLAS Techniques

AML.T0011 User Execution

AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

NIST AI RMF: MANAGE-4

What are the technical details?

Original Advisory

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands), and 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) in the Splunk documentation.

Exploitation Scenario

An attacker who has obtained or been granted a low-trust 'power' role account (e.g., a contractor, junior analyst, or compromised low-privilege credential) crafts a Table Editor dataset whose 'initial data' definition embeds SPL that would normally be blocked by risky-command safeguards elsewhere in Splunk. The attacker shares this dataset with, or otherwise induces, a Splunk 'admin' to open it — for example via an internal message claiming it's a useful dashboard covering AI/ML pipeline alerts or SOC metrics. The moment the admin opens the dataset in the Table Editor, the embedded SPL executes silently with the admin's full privileges, letting the attacker exfiltrate sensitive indexed data (which may include AI system logs, credentials, or API keys) or make limited configuration changes on the search head — all without the admin realizing SPL was ever executed.

Weaknesses (CWE)

CWE-863 Incorrect Authorization

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.