Splunk patches vulnerabilities that can expose sensitive data and trigger DoS attacks

Splunk has released fixes for three vulnerabilities affecting Splunk Enterprise, Splunk Cloud Platform, Splunk AI Toolkit, and the Splunk Archiver app. The flaws can expose sensitive data, weaken role-based access controls, or let low-privileged users make a Splunk instance non-functional.

The issues were disclosed on May 20, 2026, and are tracked as CVE-2026-20238, CVE-2026-20239, and CVE-2026-20240. Splunk administrators should review affected versions, update vulnerable components, and check whether low-privileged users have more access than intended.

The most urgent risks involve sensitive data exposure through internal logs and a denial-of-service path in the Splunk Archiver app. The AI Toolkit issue is lower severity, but it still matters in environments that rely on search filters to separate user access across sensitive indexes.

Three Splunk flaws were patched

The first issue affects Splunk AI Toolkit. The Splunk advisory for CVE-2026-20238 says a low-privileged user without the admin or power roles could access confidential data restricted through custom role srchFilter configurations.

The second issue affects Splunk Enterprise and Splunk Cloud Platform. The Splunk advisory for CVE-2026-20239 says users with access to the _internal index could view session cookies and HTTP response bodies because of missing output buffer sanitization in the TcpChannel component.

The third issue affects Splunk Enterprise and Splunk Cloud Platform deployments using Splunk Archiver. The Splunk advisory for CVE-2026-20240 says a low-privileged user can exploit the coldToFrozen.sh script to rename critical Splunk directories, making the instance non-functional.

CVE	Component	Severity	Main impact
CVE-2026-20238	Splunk AI Toolkit	Medium, CVSS 6.5	Improper access control through role inheritance
CVE-2026-20239	Splunk Enterprise and Splunk Cloud Platform	High, CVSS 7.5	Sensitive data exposure through internal logs
CVE-2026-20240	Splunk Archiver app in Splunk Enterprise and Splunk Cloud Platform	High, CVSS 7.1	Denial of service through unsafe file path handling

The AI Toolkit flaw can bypass restrictive search filters

CVE-2026-20238 affects Splunk AI Toolkit versions below 5.7.3. The flaw comes from how the app modifies the built-in user role through an authorize.conf file that contains an srchFilter entry.

Splunk combines inherited search filters with the OR operator. In affected configurations, the AI Toolkit’s filter can override more restrictive filters on child roles. That means a user with a low-privileged custom role may see data that administrators expected to keep restricted.

This issue is especially important in shared Splunk environments. Many organizations use custom roles and search filters to separate teams, business units, regulated datasets, security logs, and customer information.

Why CVE-2026-20238 matters for access control

Search filters often act as a quiet but important boundary. A user may have access to the same Splunk instance as other teams, but filters limit which events appear in their searches.

If inherited filters merge incorrectly or too broadly, that boundary weakens. The affected user may not need admin privileges, power-user permissions, or direct index-level ownership to reach data that should remain hidden.

The Splunk AI Toolkit advisory recommends upgrading the app to version 5.7.3 or higher. As a temporary workaround, administrators can disable the app or remove or override the srchFilter setting, but they must check whether that exposes the ai_agent_run_history_index more broadly.

TcpChannel logging can expose sensitive data

CVE-2026-20239 affects Splunk Enterprise versions below 10.2.2 and 10.0.5. It also affects Splunk Cloud Platform versions below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13.

The bug sits in the TcpChannel component. When socket errors occur, TcpChannel can log full input and output buffer contents at WARN level while discarding data. Those buffers can include session cookies and HTTP response bodies.

This creates a sensitive-data exposure problem for users who can search the _internal index. If those logs contain session material or response bodies, a user with internal log visibility may gain access to data they should not see.

Access to _internal should stay tightly controlled

Splunk’s _internal index can contain operational logs, service details, component errors, internal activity, and diagnostic data. Administrators often use it for troubleshooting, but broad access can become risky when application components log sensitive information.

For CVE-2026-20239, Splunk recommends upgrading to fixed versions and making sure only administrative roles can access the _internal index.

The Splunk TcpChannel advisory also gives a temporary search-based mitigation that suppresses matching warning messages from TcpChannel. Administrators should treat that as a short-term option, not a replacement for upgrading.

Product branch	Fixed version for CVE-2026-20239
Splunk Enterprise 10.2	10.2.2 or later
Splunk Enterprise 10.0	10.0.5 or later
Splunk Cloud Platform 10.3.2512	10.3.2512.8 or later
Splunk Cloud Platform 10.2.2510	10.2.2510.11 or later
Splunk Cloud Platform 10.1.2507	10.1.2507.21 or later
Splunk Cloud Platform 10.0.2503	10.0.2503.13 or later

The Archiver flaw can make Splunk unusable

CVE-2026-20240 affects the Splunk Archiver app. The issue comes from missing input validation in coldToFrozen.sh, a script used as part of data lifecycle and archiving workflows.

A low-privileged user without the admin or power roles can supply arbitrary file paths. The script can then rename critical Splunk directories instead of limiting operations to safe archiving paths.

That behavior can make the Splunk instance non-functional. In operational terms, this means a user who should not have administrative control may be able to trigger a denial-of-service condition that interrupts search, logging, investigation, or monitoring workflows.

Which versions are affected by CVE-2026-20240

CVE-2026-20240 affects Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.11, and 9.3.12. Splunk Cloud Platform deployments are also affected below several fixed branch releases.

The Splunk Archiver issue matters most where low-privileged users can interact with archiving workflows or where the app is present but not closely monitored. Administrators should not assume that low privileges eliminate operational risk.

The Splunk Archiver advisory recommends upgrading Splunk Enterprise to a fixed version or turning off the Splunk Archiver app if it is not needed. Turning it off may interrupt automated archiving workflows, so teams should check retention and storage processes before making that change.

Product branch	Fixed version for CVE-2026-20240
Splunk Enterprise 10.2	10.2.2 or later
Splunk Enterprise 10.0	10.0.5 or later
Splunk Enterprise 9.4	9.4.11 or later
Splunk Enterprise 9.3	9.3.12 or later
Splunk Cloud Platform 10.4.2603	10.4.2603.1 or later
Splunk Cloud Platform 10.3.2512	10.3.2512.9 or later
Splunk Cloud Platform 10.2.2510	10.2.2510.11 or later
Splunk Cloud Platform 10.1.2507	10.1.2507.21 or later
Splunk Cloud Platform 10.0.2503	10.0.2503.13 or later
Splunk Cloud Platform 9.3.2411	9.3.2411.129 or later

Why these flaws matter for security teams

Splunk often sits at the center of enterprise security operations. It can collect authentication logs, cloud events, endpoint alerts, firewall logs, application logs, incident data, and threat hunting results.

That makes sensitive-data exposure inside Splunk especially dangerous. If internal logs expose session cookies or response bodies, the platform that defenders use to investigate incidents can itself become a source of credential or data leakage.

The denial-of-service risk is also serious. A Splunk outage can slow incident response, interrupt monitoring dashboards, break alerting, and reduce visibility during an attack.

What administrators should do first

Administrators should identify all affected Splunk Enterprise, Splunk Cloud Platform, Splunk AI Toolkit, and Splunk Archiver deployments. They should then prioritize systems that contain sensitive logs, support security operations, or allow many non-admin users to search data.

• Upgrade Splunk AI Toolkit to version 5.7.3 or later.
• Upgrade Splunk Enterprise to the fixed version for each deployed branch.
• Confirm Splunk Cloud Platform deployments have reached the fixed release for their branch.
• Restrict access to the _internal index to administrative roles only.
• Review custom roles that inherit from the built-in user role.
• Check whether srchFilter rules still enforce expected data boundaries.
• Disable Splunk Archiver if it is not needed and patching cannot happen immediately.

Review role inheritance and search filters

Role inheritance can become difficult to reason about in large Splunk environments. A small configuration change at a parent role can affect many custom roles downstream.

After applying the AI Toolkit fix, administrators should still test whether restricted users can access data they should not see. Search filters, index permissions, and app-level permissions should all align with the organization’s access model.

Teams should also check whether AI Toolkit history data, custom indexes, and saved searches expose prompts, query history, internal data references, or sensitive operational details.

Monitor for signs of abuse

Splunk did not state in the advisories that these flaws were exploited in the wild. Still, administrators should review activity where low-privileged users accessed sensitive indexes, triggered TcpChannel warning patterns, or interacted with archiving workflows unexpectedly.

• Search for low-privileged users querying sensitive indexes.
• Review _internal access by roles other than admin.
• Look for WARN-level TcpChannel events around socket errors.
• Check whether internal logs contain session cookies or response bodies.
• Review use of Splunk Archiver by non-admin or non-power users.
• Investigate unexpected renames or missing Splunk directories.
• Check alerting gaps or search failures that may point to availability impact.

Temporary mitigations should not replace patching

Splunk provides mitigations for some environments where immediate upgrades are difficult. These include disabling the AI Toolkit, modifying authorization settings, restricting _internal access, filtering problematic TcpChannel logs, or turning off Splunk Archiver.

Those steps can reduce risk, but they can also create side effects. Removing srchFilter settings may change access to AI Toolkit data. Turning off Splunk Archiver may disrupt cold-to-frozen workflows. Suppressing logs may reduce diagnostic visibility.

For that reason, teams should document each temporary mitigation, test the operational impact, and replace it with the fixed release as soon as possible.

The broader lesson for Splunk environments

These vulnerabilities show how small configuration and validation issues can create large security consequences inside logging platforms. Access control mistakes can expose data, logging mistakes can leak sensitive values, and input validation gaps can break core services.

Splunk administrators should treat upgrades, role reviews, and index access checks as part of the same security process. A patched instance with overly broad _internal access may still carry unnecessary risk.

The safest response is to update affected components, review permissions, restrict sensitive indexes, validate search filters, and confirm that archiving workflows cannot be abused by low-privileged users.

FAQ