Splunk has patched a critical vulnerability in Splunk Enterprise that lets an attacker with network access to a search head cluster member run operating-system commands on it without logging in. The flaw, tracked as CVE-2026-76268, carries a CVSS v3.1 score of 9.8 out of 10 and was published on October 7 in Splunk's security advisory SVD-2026-1001.
Peru's National Digital Security Center (CNSD) flagged the bug to local organizations a day later in its integrated alert 195-2026, calling it a critical unauthenticated remote command-execution risk. Splunk sits at the heart of many security operations centers, so a bug that hands its servers to an outsider is a problem for the defenders as much as for the data.
A cluster API with no front door
According to Splunk, the problem is missing authentication (CWE-306) on the Patroni REST API exposed by search head cluster members. Patroni is an open-source manager for PostgreSQL databases, and Splunk's own workaround ties it to the [postgres] service in the product's configuration. Splunk says an unauthenticated user who can reach that API could execute attacker-controlled operating-system commands, and the CVSS vector rates the attack as network-reachable, low complexity and requiring no privileges or user interaction.
Splunk credits its own researcher, Gabriel Nitu, with finding the issue. The advisory does not report any exploitation in the wild, and the CNSD alert does not mention any either.
Who is exposed
Only the two newest release lines are affected:
- Splunk Enterprise 10.4.0 to 10.4.2 (fixed in 10.4.3)
- Splunk Enterprise 10.2.0 to 10.2.6 (fixed in 10.2.7)
Splunk lists the 10.0.x and 9.4.x branches as not affected by this CVE. The same advisory, however, ships fixes for 16 other, lower-severity issues across all four supported branches, including a CVSS 7.7 local privilege escalation in Linux package upgrades, so 10.0 and 9.4 customers still have reasons to update to 10.0.10 and 9.4.15. This is not the first serious Splunk fix of the year; IntelFusions covered a session-leak bug in shared Splunk reports in August.
Upgrade to 10.4.3 or 10.2.7, or switch the database off
The fix is to upgrade to Splunk Enterprise 10.4.3 or 10.2.7 or later. For teams that cannot patch immediately, Splunk documents a workaround: set disabled = true in the [postgres] stanza of server.conf and restart, but only if the deployment does not use Edge Processor, OpAmp or SPL2 pipelines, which depend on that database.
Beyond the patch, network reachability is the whole attack. Search head cluster members should never expose internal cluster services to the internet or to broad internal networks, and restricting access to the Patroni API to the cluster members themselves shrinks the pool of people who could try this to almost nobody. For organizations in Latin America following the CNSD's guidance, our Peru country profile tracks the national response setup.
A tool that watches everything else is an attractive place to land. Getting the security platform itself patched before someone goes looking for unprotected cluster APIs is the cheapest win on this week's list.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.