Splunk Patches Multiple Vulnerabilities Enabling DoS Attacks and Data Exposure

Splunk has released security updates to fix three newly disclosed vulnerabilities that could allow low-privileged users to access sensitive data or disrupt Splunk Enterprise deployments through denial-of-service (DoS) conditions.

The patches address issues in both Splunk Enterprise and the Splunk Cloud Platform, as well as the Splunk AI Toolkit app.

The flaws include improper access control, sensitive data exposure in logs, and unsafe handling of file paths that can be abused to break an instance.

The three advisories are:

• SVD-2026-0502 / CVE-2026-20238 – Improper access control in Splunk AI Toolkit (Medium).
• SVD-2026-0503 / CVE-2026-20239 – Sensitive information disclosure through log files in Splunk Enterprise and Splunk Cloud Platform (High).
• SVD-2026-0504 / CVE-2026-20240 – Denial of service via coldToFrozen.sh in Splunk Enterprise and Splunk Cloud Platform (High).

CVE-2026-20238 – Splunk AI Toolkit Improper Access Control

Splunk AI Toolkit versions below 5.7.3 contain a misconfiguration in the authorize.conf file that weakens role-based access control for search filters.

The app modifies the built-in “user” role using a srchFilter entry, and when combined with Splunk’s role inheritance logic (filters joined with OR), this can override more restrictive search filters on custom child roles.

As a result, low-privileged users who do not have “admin” or “power” roles can query data that srchFilter-based restrictions, including confidential AI-related content in the ai_agent_run_history_index index, should hide.

Splunk rates this issue as CVSS 6.5 (Medium), with impact focused on confidentiality (CWE-863: Incorrect Authorization).

Recommended actions:

• Upgrade Splunk AI Toolkit to version 5.7.3 or later.
• As a temporary workaround, disable Splunk AI Toolkit 5.7.2 and earlier until the patch can be applied.
• If the app must remain enabled, remove the srchFilter line from the default authorize.conf, or override it with an empty srchFilter in the local file. Then restart Splunk and explicitly restrict ai_agent_run_history_index via srchIndexesAllowed on AI-specific roles.

CVE-2026-20239 – Sensitive Data in Splunk Internal Logs

CVE-2026-20239 affects Splunk Enterprise versions below 10.2.2 and 10.0.5, as well as specific Splunk Cloud Platform builds below the fixed maintenance releases.

In vulnerable versions, any user role with access to the _internal index can view session cookies and HTTP response bodies that may contain sensitive information.

The issue stems from missing output buffer sanitization in the TcpChannel component, which logs full I/O buffer contents at WARN level when discarding data due to socket errors.

This behavior can leak authentication-related data and application responses into _internal logs, raising both confidentiality and potential integrity/availability concerns, reflected in the 7.5 High CVSS score.

Splunk’s guidance:

• Upgrade Splunk Enterprise to 10.2.2, 10.0.5, or later; Splunk is also rolling out fixes to Splunk Cloud Platform customers.
• Immediately review and tighten role definitions so that access to the _internal index is restricted to admin-level roles only.

CVE-2026-20240 – DoS via coldToFrozen.sh in Splunk Archiver

The third flaw, CVE-2026-20240, impacts the splunk_archiver component in Splunk Enterprise and Splunk Cloud Platform and is rated 7.1 (High) for availability impact.

In affected builds, a low-privileged user without admin or power roles can exploit the coldToFrozen.A script to rename critical Splunk directories, rendering the instance non-functional.

The root cause is missing input validation in coldToFrozen.sh, which accepts arbitrary file paths and performs rename operations without restricting them to safe directories used for cold-to-frozen bucket transitions.

This allows a malicious or compromised low-privilege account to trigger a denial-of-service attack by targeting core Splunk paths.

The fix matrix requires:

• Upgrading Splunk Enterprise to 10.2.2, 10.0.5, 9.4.11, or 9.3.12, depending on the deployment branch, and applying corresponding maintenance releases for Splunk Cloud Platform (for example, 10.4.2603.1, 10.3.2512.9, 10.2.2510.11).
• As a mitigation, Splunk recommends turning off the Splunk Archiver app. If you do not use it, there should be no operational impact, and the effective severity becomes informational.

Organizations running Splunk should treat these issues as a priority, especially in multi-tenant environments or where many users hold low-privilege roles.

Immediate steps include upgrading to the fixed versions, temporarily turning off vulnerable apps (AI Toolkit, Splunk Archiver) where patching is delayed, and tightening access to the _internal index and AI-specific indexes.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.