Splunk Patches 24 Flaws — Four Critical Vulnerabilities in Enterprise and SOAR Addressed

Splunk has released a set of security updates correcting 24 vulnerabilities across Splunk Enterprise and Splunk SOAR. The fixes, published in advisories on October 21, 2026, include four critical flaws with CVSS scores as high as 9.9 and a mix of issues that range from improper access control and unsafe input handling to the potential for remote code execution and denial-of-service. Because Splunk often occupies a central role in security monitoring, these vulnerabilities warrant swift attention from administrators and security teams.

What the advisories cover

Splunk grouped its updates into advisories that address access control weaknesses, unsafe input handling, exposed files or directories, opportunities for remote code execution, denial-of-service conditions, and weak authorization checks. Some of the highest-severity CVEs were found internally; others were reported through normal disclosure channels. While several flaws require an authenticated user to exploit, they remain dangerous in environments with stolen credentials, overly permissive roles, or internet-facing services that expose management functionality.

Critical Severity :

CVE	Product	CVSS	CWE
CVE-2026-76299	Splunk Enterprise	9.9	CWE-284
CVE-2026-76302	Splunk Enterprise	9.9	CWE-707
CVE-2026-76407	Splunk SOAR	9.3	CWE-284
CVE-2026-76531	Splunk SOAR	9.9	CWE-552

Notable high-risk examples

– CVE-2026-76299 and CVE-2026-76302 (both 9.9) are high-impact Splunk Enterprise issues tied to access control and improper neutralization that could allow dangerous actions when exploited.

– CVE-2026-76531 (9.9) in Splunk SOAR may expose files or directories to unauthorized parties.

– CVE-2026-76407 (9.3) is another SOAR issue involving improper access control.

High Severity :

CVE	Product	CVSS	CWE
CVE-2026-76291	Splunk Enterprise	8.8	CWE-284
CVE-2026-76298	Splunk Enterprise	8.8	CWE-321
CVE-2026-76300	Splunk Enterprise	8.8	CWE-664
CVE-2026-76408	Splunk SOAR	8.8	CWE-664
CVE-2026-76526	Splunk SOAR	8.8	CWE-707
CVE-2026-76530	Splunk SOAR	8.8	CWE-647
CVE-2026-76301	Splunk Enterprise	7.6	CWE-693
CVE-2026-76288	Splunk Enterprise	7.5	CWE-400
CVE-2026-76290	Splunk Enterprise	7.5	CWE-400
CVE-2026-76529	Splunk SOAR	7.5	CWE-424
CVE-2026-76293	Splunk Enterprise	7.2	CWE-94

Risk scenarios called out by Splunk

Several issues could allow attackers to escalate privileges or run system commands. For example, one high-severity issue could let a user with scheduled-search rights bypass safeguards and execute risky SPL commands; another could allow a low-privileged user to derive the PostgreSQL sidecar superuser password and execute OS-level commands on search head cluster members. There are also at least two unauthenticated denial-of-service (DoS) vulnerabilities—CVE-2026-76288 and CVE-2026-76290—that can impact services via crafted web requests or repeated downloads without any account.

Immediate actions for administrators

• Prioritize patching high- and critical-severity CVEs first. Splunk’s guidance calls for upgrading Splunk Enterprise to one of: 10.4.4, 10.2.8, 10.0.11, or 9.4.16. Splunk SOAR should be moved to 8.7.0 or later. Splunk Secure Gateway should be updated to 3.10.12, 3.9.26, or 3.8.73 where applicable.
• If immediate patching is not possible, apply temporary mitigations: disable unused Splunk Web, Pipeline Builders, Secure Gateway, or PostgreSQL sidecar features as relevant to the affected CVE. Carefully evaluate dependencies before turning off features; these steps can reduce exposure but may break functionality.
• Review user roles and permissions to reduce the blast radius of compromised or excessive accounts. Enforce least privilege, rotate service credentials, and tighten scheduled-search and edit capabilities.
• Restrict access to Splunk management interfaces from the public internet; place systems behind VPNs, network ACLs, or allowlists where practical. Pay special attention to internet-facing instances due to the unauthenticated DoS issues.
• Monitor logs for unusual activity tied to the CVEs (unexpected SPL commands, changes to field extraction, suspicious REST API calls, or abnormal file access). Integrate threat intelligence feeds to spot exploitation attempts earlier.

Longer-term defensive measures

Treat Splunk instances as crown-jewel infrastructure: maintain a documented update cadence, test patches in staging before wide rollout, and run periodic configuration audits. Use multi-factor authentication, robust role design, and continuous monitoring to detect misuse. Consider isolating or hardening components like the PostgreSQL sidecar, pipeline builders, and any modules that can execute commands or manage data extraction.

Closing thoughts

The scope of these 24 fixes underscores how even security platforms can become points of failure when their components are compromised. Rapid patching, careful access controls, and visibility into Splunk activity are the best ways to reduce exposure. Teams should map which CVEs affect their specific deployment, follow Splunk’s upgrade guidance, and use compensating controls where patching cannot be completed immediately.