If your security team relies on Splunk Enterprise to collect logs and spot attacks, this month's Splunk update deserves prompt attentionas the most serious flaw lets someone with no username or password take over a Splunk server in a clustered deployment, simply by being able to reach one of its internal management interfaces over the network. Splunk is where an organisation's security evidence lives, so an attacker in control of it can read sensitive data from across the business, harvest the credentials Splunk uses to reach other systems, and quietly delete or alter the very records that would reveal an intrusion. There are no public reports of attacks yet, the fix is available now, and there is a straightforward interim measure for teams that cannot upgrade immediately.
The flaw, CVE-2026-76268, carries a CVSS score of 9.8 out of 10. It affects Splunk Enterprise 10.4.0 to 10.4.2 and 10.2.0 to 10.2.6 when running as a search head cluster, and is fixed in 10.4.3 and 10.2.7. The same release also fixes two more critical issues identified internally, a long list of authenticated flaws that let low-privileged users see or change things they should not, a token-leaking bug in Splunk MCP Server, and outdated third-party components in the Splunk Add-on for Amazon Web Services. The sections below cover what each issue needs to be exploitable, how to check your deployment, and what to do in what order.
Why this one matters
A SIEM is one of the most privileged systems in any environment. It receives data from nearly everything, it often holds service account credentials and API tokens for the systems it collects from, and it is the place investigators go to reconstruct what happened during an incident. Compromising it gives an attacker three things at once: a searchable copy of the organisation's sensitive data, a store of credentials for moving elsewhere, and the ability to blind the defenders who depend on it.
CVE-2026-76268 is the worst case for that kind of system. It requires no authentication and no user interaction, and a successful attack lets the attacker run operating system commands on the search head cluster member. In practical terms, that is full control of the server running Splunk.
The limiting factor is reachability. The attacker needs network access to the Patroni REST API on a search head cluster member. That interface should never be exposed to the internet, but in many environments it will be reachable from much of the internal network, which means anyone who has already gained a foothold on a workstation or server could use it to take over the SIEM.
How this came to light
Splunk published five advisories on October 7, 2026 as part of its September/October security release:
- SVD-2026-1001 covers 17 vulnerabilities in Splunk Enterprise, including CVE-2026-76268 (CVSS 9.8).
- SVD-2026-1002 is a hardening advisory grouping internally identified issues by weakness type, including two more critical CVEs.
- SVD-2026-1003 covers 24 CVEs in third-party packages bundled with Splunk Enterprise.
- SVD-2026-1004 covers CVE-2026-76286 in Splunk MCP Server.
- SVD-2026-1005 covers 44 CVEs in third-party packages bundled with the Splunk Add-on for Amazon Web Services.
CVE-2026-76268 was found internally by Gabriel Nitu of Splunk, who is also credited with most of the other Splunk Enterprise flaws in SVD-2026-1001. We have found no public reports of exploitation or public proof-of-concept code for any of these issues at the time of writing, and none are in CISA's Known Exploited Vulnerabilities catalog.
How the flaws work
The Patroni REST API (CVE-2026-76268)
Patroni is an open-source tool for running highly available PostgreSQL databases. Recent versions of Splunk Enterprise ship a PostgreSQL "sidecar" that supports newer features such as Edge Processor, OpAmp, and SPL2 data pipelines, and Patroni manages that database on search head cluster members.
Patroni exposes a REST API for configuration and cluster management. In the affected Splunk versions, that API does not require authentication for critical configuration operations (CWE-306, missing authentication for critical function). Splunk's advisory says an unauthenticated user with network access to it on a search head cluster member could use it to execute attacker-controlled operating system commands.
Three details matter for deciding how exposed you are:
- Only 10.2 and 10.4 are affected. Splunk Enterprise 10.0.x and 9.4.x do not include the vulnerable component.
- The advisory specifies search head cluster members. Deployments with clustered search heads are the ones to prioritise.
- The sidecar is on by default. Splunk Enterprise ships with the PostgreSQL sidecar enabled, so if you are on an affected version and run a search head cluster, assume you are exposed unless you have deliberately turned it off. Do not assume the Patroni API is on a particular port; Patroni's common default is 8008, but check what is actually listening.
The other critical issues (SVD-2026-1002)
Splunk's hardening advisory groups a batch of internally identified findings by weakness category and assigns one CVE per group, scored at the highest severity within it. Splunk has published no per-finding detail, so there is little to act on beyond upgrading, but two of the groups are rated critical:
| CVE | Highest CVSS | Weakness category |
|---|---|---|
| CVE-2026-76281 | 9.8 | Improper access control (CWE-284) |
| CVE-2026-76284 | 9.0 | Improper neutralization, the family that covers injection flaws (CWE-707) |
| CVE-2026-76282 | 8.8 | Improper control of a resource through its lifetime (CWE-664) |
| CVE-2026-76283 | 7.6 | Protection mechanism failure (CWE-693) |
| CVE-2026-76285 | 4.4 | Improper adherence to coding standards (CWE-710) |
These affect every supported branch, including 10.0 and 9.4, which is one reason the whole estate should be upgraded and not only the 10.2 and 10.4 search head clusters.
Authenticated flaws worth knowing about (SVD-2026-1001)
The remaining 16 flaws in SVD-2026-1001 all require a Splunk login, and most are rated Medium. Individually none is an emergency, but together they matter in any environment where many people hold Splunk accounts, because several let ordinary users see or change things meant only for administrators. The ones we would highlight:
| CVE | What a logged-in user could do | CVSS |
|---|---|---|
| CVE-2026-76266 | On Linux, a local user able to act as the Splunk service account could plant commands that run as root the next time Splunk is upgraded using the RPM or DEB package | 7.7 |
| CVE-2026-76269 | Read other users' search jobs, including query text and results, without the admin or power role | 6.5 |
| CVE-2026-76274 | Redirect a request from the Splunk App for Splunk Observability Cloud to an attacker's server and capture the configured Observability Cloud API token (requires read_o11y_content) |
6.5 |
| CVE-2026-76265, CVE-2026-76272 | Get Splunk Secure Gateway to sign attacker-controlled payloads without the admin or power role | 6.5, 4.3 |
| CVE-2026-76280 | Modify Splunk Secure Gateway alert and mobile-device recipient data | 6.3 |
| CVE-2026-76270 | Use SQL injection to read other users' private SPL2 modules (10.4 only; requires list_spl2_modules) |
6.5 |
| CVE-2026-76264 | Create or edit scripted lookup definitions without the admin or power role | 4.3 |
| CVE-2026-76279 | Write events into internal indexes the user's role should not reach (requires run_collect) |
4.3 |
The rest cover log injection, a regular-expression denial of service, source code exposure through JavaScript source maps, SPL2 permission disclosure, search job listing leaks, and two input validation issues. All are fixed by the same upgrade.
Splunk MCP Server (CVE-2026-76286)
Splunk MCP Server lets AI assistants and agents query Splunk through custom tools. In versions below 1.2.1, a user with the mcp_tool_admin capability can point a custom API tool at a URL they control; when another user with mcp_tool_execute runs that tool, MCP Server sends that user's Splunk authentication token to the URL. The attacker can then act as the victim. It is rated Medium (5.3) because it needs a privileged configurer and a victim to run the tool, but it is a good example of the new kinds of trust problems that come with connecting AI tooling to sensitive data.
Third-party components (SVD-2026-1003 and SVD-2026-1005)
Splunk Enterprise's bundled Go components (including etcd, the agent manager, and SPL2 tooling) were updated to address critical-rated CVEs in Go's networking and cryptography libraries, alongside libcurl and OpenTelemetry updates. The Splunk Add-on for AWS was updated to 8.2.2 to address 44 CVEs in its bundled Go compiler, networking, gRPC, Thrift, and Python cryptography libraries. Splunk has not described how these could be exploited through its products, but they ship in components that run with Splunk's privileges and should be patched on the normal upgrade.
Who is affected
| Product | Affected versions | Fixed version | Exposed to CVE-2026-76268? |
|---|---|---|---|
| Splunk Enterprise 10.4 | 10.4.0 to 10.4.2 | 10.4.3 | Yes, on search head cluster members |
| Splunk Enterprise 10.2 | 10.2.0 to 10.2.6 | 10.2.7 | Yes, on search head cluster members |
| Splunk Enterprise 10.0 | 10.0.0 to 10.0.9 | 10.0.10 | No, but affected by other flaws |
| Splunk Enterprise 9.4 | 9.4.0 to 9.4.14 | 9.4.15 | No, but affected by other flaws |
| Splunk Secure Gateway | Below 3.10.11, 3.9.25, 3.8.72 | 3.10.11, 3.9.25, 3.8.72 | No |
| Splunk MCP Server | Below 1.2.1 | 1.2.1 | No |
| Splunk Add-on for AWS | Below 8.2.2 | 8.2.2 | No |
These advisories cover customer-managed Splunk Enterprise and apps. If you use Splunk Cloud Platform, the platform itself is maintained by Splunk, but apps and add-ons you have installed may still need updating; confirm with Splunk if you are unsure.
What you should do
1. Find out which deployments are exposed to CVE-2026-76268
On each search head, check the version and whether the PostgreSQL sidecar is enabled:
$SPLUNK_HOME/bin/splunk version
$SPLUNK_HOME/bin/splunk btool server list postgres --debug
If the version is 10.2.0 to 10.2.6 or 10.4.0 to 10.4.2, the host is a search head cluster member, and the [postgres] stanza does not show disabled = true, treat it as exposed. Then check which ports the sidecar is actually listening on and which networks can reach them; do not assume a default.
2. Upgrade Splunk Enterprise across the environment
Upgrade to 10.4.3, 10.2.7, 10.0.10, or 9.4.15 or later. Start with 10.2 and 10.4 search head clusters, then move through indexers, heavy forwarders, deployment servers, and every other Splunk Enterprise instance, since the critical hardening fixes and most authenticated flaws apply to all branches.
On Linux, Splunk's mitigation for CVE-2026-76266 is to upgrade using the tar file rather than the RPM or DEB package. If you have any reason to doubt the integrity of the Splunk service account on a host, use the tar file for this upgrade.
3. Complete the extra steps the upgrade does not cover
Four of the flaws need more than the core upgrade:
- CVE-2026-76265, CVE-2026-76272, CVE-2026-76280: upgrade Splunk Secure Gateway to 3.10.11, 3.9.25, or 3.8.72 or later. If you do not use Splunk Mobile, Spacebridge, or Mission Control, Splunk says you can turn the app off instead.
- CVE-2026-76264: after upgrading, set
scripted_lookup_raw_write_enforcement = blockunder[lookup]inlimits.conf, then restart.
Also upgrade Splunk MCP Server to 1.2.1 and the Splunk Add-on for AWS to 8.2.2 wherever they are installed.
4. If you cannot upgrade a search head cluster right away
If you do not use Edge Processor, OpAmp, or SPL2 data pipelines, turn off the PostgreSQL sidecar by setting disabled = true in the [postgres] stanza of $SPLUNK_HOME/etc/system/local/server.conf and restarting Splunk. This removes the vulnerable interface entirely. If you do use those features, restrict network access to the Patroni API so that only other search head cluster members can reach it, using host firewalls or network ACLs, until you can upgrade.
For other flaws with interim mitigations: turn off the Splunk App for Splunk Observability Cloud and the Discover Splunk Observability Cloud app if you do not use them, remove the run_collect capability from roles that should not touch internal indexes, and turn off Splunk MCP Server if it is not in active use.
5. Review who has Splunk accounts and what they can do
Most of this month's flaws are only reachable by logged-in users, so the size of your user base is part of your attack surface. Remove dormant accounts, check which roles hold capabilities such as run_collect, edit_user, mcp_tool_admin, and read_o11y_content, and rotate the Observability Cloud API token if untrusted users have held read_o11y_content.
6. Watch for signs of tampering
Look in network flow and firewall logs for connections to the Patroni API from anything other than search head cluster peers, and on the hosts themselves for unexpected processes started by the PostgreSQL sidecar or the Splunk service account. Because Splunk is the system you would normally use to investigate, make sure at least some of its own audit and host logs are copied somewhere an attacker with control of Splunk could not easily reach.
A note on the pattern
Security tooling is software, and it is increasingly targeted precisely because it is trusted and privileged. A SIEM, an EDR console, or a vulnerability scanner can see and reach more of the environment than almost anything else, and an attacker who controls one gains both access and cover. That makes these platforms worth the same patching discipline and network isolation as domain controllers, rather than being treated as background infrastructure owned by "the security team."
This release also illustrates a quieter trend: newer platform features bring new internal components, and each component brings its own management interfaces. Patroni and its PostgreSQL sidecar arrived to support newer Splunk capabilities, are enabled by default, and introduced an unauthenticated interface that many administrators may not have known was there. Knowing what is running and listening on your own security infrastructure, and turning off what you do not use, is one of the cheapest ways to stay ahead of the next advisory.
Summary
| Headline CVE | CVE-2026-76268 |
| Other critical CVEs | CVE-2026-76281 (9.8), CVE-2026-76284 (9.0) |
| Component | Patroni REST API for the PostgreSQL sidecar on Splunk Enterprise search head cluster members |
| Type | Missing authentication for critical function (CWE-306) |
| CVSS | 9.8 (Critical) |
| Impact | Unauthenticated execution of operating system commands on the search head |
| Affected | Splunk Enterprise 10.4.0 to 10.4.2 and 10.2.0 to 10.2.6 search head clusters; all branches affected by other flaws in the release |
| Not affected by CVE-2026-76268 | Splunk Enterprise 10.0.x and 9.4.x |
| Disclosed | October 7, 2026 (SVD-2026-1001, SVD-2026-1002, SVD-2026-1003, SVD-2026-1004, SVD-2026-1005) |
| Exploited in the wild? | No public reports at time of writing |
| CISA KEV? | No |
| Workaround | Set disabled = true in the [postgres] stanza of server.conf if Edge Processor, OpAmp, and SPL2 data pipelines are not used, or restrict Patroni API access to cluster peers |
| Detection | splunk version and splunk btool server list postgres; unexpected connections to the Patroni API |
| Full fix | Splunk Enterprise 10.4.3, 10.2.7, 10.0.10, or 9.4.15; Secure Gateway 3.10.11, 3.9.25, or 3.8.72; MCP Server 1.2.1; Add-on for AWS 8.2.2; plus the limits.conf change for CVE-2026-76264 |
A critical, unauthenticated flaw in the system your defenders depend on, with no attacks reported yet and a simple interim fix: that is a window worth using. Check your search head clusters for the sidecar, switch it off if you do not need it, and get the upgrade scheduled across the whole Splunk estate, including the extra Secure Gateway and configuration steps.
If you need help assessing your Splunk exposure, hardening the platform your detection depends on, or making sure your logging would survive an attacker who reached it, get in touch. The system that watches everything else needs someone watching it too.