Splunk's three Critical Enterprise CVEs: one is explained, two are only a weakness class and a score

Three Critical Splunk Enterprise scores, and one comes with an explanation

Splunk published five security advisories on 7 October 2026: three for Splunk Enterprise, one for the Splunk MCP Server and one for the Splunk Add-on for Amazon Web Services. Their headers list 91 CVE identifiers, of which 83 are distinct, because eight appear in both package advisories (derived). Of the 83, 23 are flaws in Splunk's own code, numbered CVE-2026-76264 to CVE-2026-76286, and 60 are CVEs in third-party packages that Splunk fixed by upgrading components (derived). Three of the 23 score 9.0 or more, the CVSS 3.1 Critical band: CVE-2026-76268 at 9.8, CVE-2026-76281 at 9.8 and CVE-2026-76284 at 9.0. SVD-2026-1001 describes the first. SVD-2026-1002 gives the other two only as a weakness class and a score.

What the advisory says about the first. Splunk says that in Splunk Enterprise builds below 10.4.3 and 10.2.7, an unauthenticated user with network access to the Patroni REST API on a search head cluster member could run operating-system commands, because the interface does not require authentication for critical configuration operations. Branches 10.0 and 9.4 are not affected by this one. What it says about the other two. The page is titled "Security Hardening in Splunk Enterprise" and says each CVE groups internally identified findings under one weakness class and carries the highest score among them. CVE-2026-76281 is Improper Access Control (CWE-284), 9.8. CVE-2026-76284 is Improper Neutralization (CWE-707), 9.0. Splunk gives no component, no authentication requirement, no vector, no mitigation and no count of findings for either, and lists all four supported branches as affected.

SecurityWeek reported on 8 October that the Splunk Enterprise updates fix three critical-severity bugs that could be exploited for arbitrary command execution, unauthorized access and code injection. It lists no identifiers, so matching its three phrases to these three CVEs is our reading, and the match is loose. Command execution is Splunk's wording for CVE-2026-76268. Unauthorised access paraphrases the class label Improper Access Control. Code injection appears nowhere in Splunk's text: the CVE record's definition of CWE-707 speaks of structured data that is not well formed and does not mention code. Where SecurityWeek and the advisories differ, this briefing follows the advisories.

What the count does not establish. It does not say anyone is exploiting any of these CVEs: none of the five pages says Splunk is aware of exploitation, or that it is not. It does not say the two unexplained scores need an account, a role or a setting, because Splunk does not say so either. It does not say how many separate findings sit behind each of the two group CVEs, or whether Splunk Cloud Platform is affected. And the scores are Splunk's. Splunk is part of Cisco; it wrote the advisories, assigned the identifiers through Cisco as the CVE numbering authority, chose the scores, and sells both the software and the cloud service it says it patches. That is a commercial interest, not a reason to doubt a statement, but it is whose figures these are.

What each Critical score comes with, and what the release leaves out

The first table sets the three Critical scores against what Splunk's pages state about each. The second does the same for the release as a whole.

What Splunk states and does not state about each Critical CVE. Sources: SVD-2026-1001 and SVD-2026-1002 on advisory.splunk.com and the CVE Services API, read on 8 October 2026.

1. Critical score

   CVE-2026-76268, missing authentication in the Patroni REST API, 9.8 (SVD-2026-1001)

   Stated by Splunk

   Unauthenticated, network access to the Patroni REST API on a search head cluster member, no user interaction; operating-system commands; builds below 10.4.3 and 10.2.7; 10.0.x and 9.4.x not affected; mitigation: turn off the PostgreSQL sidecar if you do not use Edge Processor, OpAmp or SPL2 data pipelines

   Not stated

   Which account runs the commands; whether the interface is reachable beyond the cluster by default; any exploitation; whether Splunk Cloud Platform is affected

2. Critical score

   CVE-2026-76281, Improper Access Control, 9.8 (SVD-2026-1002)

   Stated by Splunk

   CWE-284; the highest score in a group of internally identified findings; affected 10.4.0 to 10.4.2, 10.2.0 to 10.2.6, 10.0.0 to 10.0.9 and 9.4.0 to 9.4.14

   Not stated

   Component; role or setting needed; whether authentication is needed; vector; mitigation; number of findings in the group

3. Critical score

   CVE-2026-76284, Improper Neutralization, 9.0 (SVD-2026-1002)

   Stated by Splunk

   CWE-707; the highest score in a group of internally identified findings; the same four branches

   Not stated

   What is neutralised or injected; whether code can run; component; role or setting needed; vector; mitigation

Critical score	Stated by Splunk	Not stated
CVE-2026-76268, missing authentication in the Patroni REST API, 9.8 (SVD-2026-1001)	Unauthenticated, network access to the Patroni REST API on a search head cluster member, no user interaction; operating-system commands; builds below 10.4.3 and 10.2.7; 10.0.x and 9.4.x not affected; mitigation: turn off the PostgreSQL sidecar if you do not use Edge Processor, OpAmp or SPL2 data pipelines	Which account runs the commands; whether the interface is reachable beyond the cluster by default; any exploitation; whether Splunk Cloud Platform is affected
CVE-2026-76281, Improper Access Control, 9.8 (SVD-2026-1002)	CWE-284; the highest score in a group of internally identified findings; affected 10.4.0 to 10.4.2, 10.2.0 to 10.2.6, 10.0.0 to 10.0.9 and 9.4.0 to 9.4.14	Component; role or setting needed; whether authentication is needed; vector; mitigation; number of findings in the group
CVE-2026-76284, Improper Neutralization, 9.0 (SVD-2026-1002)	CWE-707; the highest score in a group of internally identified findings; the same four branches	What is neutralised or injected; whether code can run; component; role or setting needed; vector; mitigation

The CVE.org records for CVE-2026-76281 and CVE-2026-76284 repeat the class label and carry no score, and NVD lists both as Received with no score. The 9.8 and 9.0 exist on Splunk's advisory page only. The same is true of the other three CVEs in SVD-2026-1002 (8.8, 7.6 and 4.4).

What the five advisories of 7 October state and do not state about the release as a whole. Sources: the five advisories, Splunk's FAQ, the advance notice SVD-2026-0901, Splunk's support policy and research pages, read on 8 October 2026.

1. Topic

   Exploitation

   Stated

   Nothing, either way. No changelog and no detections section on any of the five pages. The FAQ says Splunk updates an advisory when there is new material information

   Not stated

   Whether Splunk is aware of exploitation, or of its absence

2. Topic

   Splunk Cloud Platform

   Stated

   The text of CVE-2026-76270 says Splunk Enterprise and Splunk Cloud Platform share the defect. The FAQ says Splunk notifies Cloud customers to schedule their updates

   Not stated

   Whether any Cloud tenant was exposed or is patched. For the June flaw Splunk said Cloud was not affected; for these it says nothing

3. Topic

   Who found it

   Stated

   SVD-2026-1002 says internally identified. In SVD-2026-1001, 10 of 17 CVEs are credited to Splunk staff and 7 to outside researchers; the MCP Server flaw to an outside researcher

   Not stated

   How the internal findings were made, or when

4. Topic

   Exposure

   Stated

   Nothing

   Not stated

   How many instances are reachable from outside; whether the Patroni interface is reachable beyond the cluster by default

5. Topic

   Forwarders

   Stated

   The Universal Forwarder was on the advance notice of 9 September and was removed from the planned list on 7 October. No advisory names it

   Not stated

   Why it was removed; which node roles the two group CVEs touch

6. Topic

   Newest branch

   Stated

   Four branches in every Enterprise product status table: 10.4, 10.2, 10.0 and 9.4

   Not stated

   Whether 10.6 is affected. Splunk's support page lists it with a 30 September release date and the trial download is 10.6.0.5

7. Topic

   Detections

   Stated

   The FAQ says Splunk makes detections available through its Enterprise Security content updates where it has them

   Not stated

   Any detection for these CVEs. The Splunk Vulnerabilities story read on research.splunk.com was last updated 24 June 2026

Topic	Stated	Not stated
Exploitation	Nothing, either way. No changelog and no detections section on any of the five pages. The FAQ says Splunk updates an advisory when there is new material information	Whether Splunk is aware of exploitation, or of its absence
Splunk Cloud Platform	The text of CVE-2026-76270 says Splunk Enterprise and Splunk Cloud Platform share the defect. The FAQ says Splunk notifies Cloud customers to schedule their updates	Whether any Cloud tenant was exposed or is patched. For the June flaw Splunk said Cloud was not affected; for these it says nothing
Who found it	SVD-2026-1002 says internally identified. In SVD-2026-1001, 10 of 17 CVEs are credited to Splunk staff and 7 to outside researchers; the MCP Server flaw to an outside researcher	How the internal findings were made, or when
Exposure	Nothing	How many instances are reachable from outside; whether the Patroni interface is reachable beyond the cluster by default
Forwarders	The Universal Forwarder was on the advance notice of 9 September and was removed from the planned list on 7 October. No advisory names it	Why it was removed; which node roles the two group CVEs touch
Newest branch	Four branches in every Enterprise product status table: 10.4, 10.2, 10.0 and 9.4	Whether 10.6 is affected. Splunk's support page lists it with a 30 September release date and the trial download is 10.6.0.5
Detections	The FAQ says Splunk makes detections available through its Enterprise Security content updates where it has them	Any detection for these CVEs. The Splunk Vulnerabilities story read on research.splunk.com was last updated 24 June 2026

"Hardening" and "package updates" are labels, not severities

SVD-2026-1002 is titled "Security Hardening in Splunk Enterprise". It holds five CVEs scored 9.8, 8.8, 7.6, 9.0 and 4.4: two in the Critical band and two in the High band (derived from the CVSS 3.1 bands). Hardening is a comforting word for the advisory that carries two of the release's three highest scores. The other Enterprise advisory with Splunk's own flaws, SVD-2026-1001, lists 17 CVEs: one Critical, one High and 15 Medium.

Splunk's index labels four of the five advisories Critical. Two of those four are the package advisories, SVD-2026-1003 and SVD-2026-1005. They list the packages Splunk upgraded and say Splunk adopts the vendor's severity rating first, or NVD's otherwise. SVD-2026-1003 has 15 package rows: 10 Critical, 3 High and 2 Medium. SVD-2026-1005 has five: 3 Critical and 2 High (derived). A rating for a package says what the package flaw could do in general, not whether Splunk's use of it can be reached, and the advisories do not say. Scorers also differ: NVD shows CVE-2026-46595, in golang.org/x/crypto, at 10.0 from CISA's coordinator and 7.1 from a second scorer, and Splunk does not say which it used. All 60 third-party CVEs were already public on CVE.org before 7 October, from 12 March 2025 to 3 August 2026 (derived).

Fixed builds per branch, read from the advisories

SecurityWeek names no versions. The advisories do, and the three Enterprise advisories carry the same product status table: four supported branches, each with an affected range and a first fixed build. CVE-2026-76268 is narrower: it applies to 10.4 and 10.2 only.

Affected and first fixed builds as stated in SVD-2026-1001 to 1005, each saying "or higher". Builds marked also listed come from Splunk Enterprise release notes pages, which carry no release dates. Read on 8 October 2026.

1. Product and branch

   Splunk Enterprise 10.4

   Affected builds

   10.4.0 to 10.4.2

   First fixed build

   10.4.3 (10.4.4 also listed)

2. Product and branch

   Splunk Enterprise 10.2

   Affected builds

   10.2.0 to 10.2.6

   First fixed build

   10.2.7 (10.2.8 also listed)

3. Product and branch

   Splunk Enterprise 10.0

   Affected builds

   10.0.0 to 10.0.9

   First fixed build

   10.0.10 (10.0.11 also listed)

4. Product and branch

   Splunk Enterprise 9.4

   Affected builds

   9.4.0 to 9.4.14

   First fixed build

   9.4.15 (9.4.16 also listed)

5. Product and branch

   Splunk MCP Server 1.2

   Affected builds

   Below 1.2.1

   First fixed build

   1.2.1

6. Product and branch

   Splunk Add-on for Amazon Web Services 8.2

   Affected builds

   Below 8.2.2

   First fixed build

   8.2.2

Product and branch	Affected builds	First fixed build
Splunk Enterprise 10.4	10.4.0 to 10.4.2	10.4.3 (10.4.4 also listed)
Splunk Enterprise 10.2	10.2.0 to 10.2.6	10.2.7 (10.2.8 also listed)
Splunk Enterprise 10.0	10.0.0 to 10.0.9	10.0.10 (10.0.11 also listed)
Splunk Enterprise 9.4	9.4.0 to 9.4.14	9.4.15 (9.4.16 also listed)
Splunk MCP Server 1.2	Below 1.2.1	1.2.1
Splunk Add-on for Amazon Web Services 8.2	Below 8.2.2	8.2.2

Splunk's advisory of 19 August (SVD-2026-0801, highest score 9.4) named 10.4.2, 10.2.6, 10.0.9 and 9.4.14 as the fix builds. The 7 October advisories' affected ranges end at exactly those builds on every branch, 49 days later (derived). An instance patched in August is affected again. On the 10.4 branch, the release notes page for 10.4.3 also says "Splunk recommends that customers do not upgrade to version 10.4.2", because of a defect that can stall forwarding when acknowledgements are enabled, so an upgrade from 10.4.0 or 10.4.1 should go to 10.4.3 or higher. SonicWall's SMA1000 advisory, covered in the same SecurityWeek article, has the same shape: its September fix build is the newest build its October advisory lists as affected.

Three differences between the press and the pages, and one inside the pages.

• Code injection. SecurityWeek's phrase is not Splunk's. Splunk says Improper Neutralization and nothing more.
• The MCP Server flaw. SecurityWeek says an authenticated user could modify API settings to send requests to an attacker-controlled URL. Splunk's advisory says that and then says what it costs: the token of the user who runs the tool goes to that URL. The MCP section below sets this out.
• Dozens of flaws. True of the identifiers, 83, but only 23 are Splunk's own code. The other 60 are package CVEs.
• Inside SVD-2026-1001. The description of CVE-2026-76264 says builds below 10.4.2 and 10.2.6, while the product status table lists 10.4.2 and 10.2.6 as affected. The other descriptions that name those branches use 10.4.3 and 10.2.7. We read it as a slip and follow the table. We have seen no correction.

Upgrading is not the whole fix. Splunk lists four CVEs in SVD-2026-1001 that need more after the upgrade. CVE-2026-76264 needs a setting in the limits.conf file. CVE-2026-76265, CVE-2026-76272 and CVE-2026-76280 need the Splunk Secure Gateway app itself upgraded to 3.10.11, 3.9.25 or 3.8.72 or higher, with turning off or removing the app as the stated mitigation. For CVE-2026-76266, a local privilege escalation during Linux package upgrades, Splunk's stated mitigation is to upgrade from a tar file instead. For CVE-2026-76281 and CVE-2026-76284 Splunk states no mitigation at all: upgrading is the only remedy it gives.

The explained Critical: what the advisory gives a defender

CVE-2026-76268 is the one Critical where Splunk states a precondition, and the precondition is thin: network access to the interface, no account and no user interaction (vector AV:N/AC:L/PR:N/UI:N). The stated mitigation is to turn off the PostgreSQL sidecar, only if you do not use Edge Processor, OpAmp or SPL2 data pipelines, and it needs a restart. Splunk's documentation says the storage sidecar is active by default on Splunk Enterprise and deactivated by default on Splunk Cloud Platform, and that a sidecar service gets a port from an internal broker, pseudo-random unless an administrator sets one. That makes a check for one fixed port a poor test of exposure (our inference). It is documentation, not the advisory: the advisory does not say whether Splunk Cloud Platform is affected, and we do not infer it.

The MCP Server item is a token leak, and it is not prompt injection

Splunk files CVE-2026-76286 (5.3, Medium) as server-side request forgery (CWE-918). Its description has two parts that SecurityWeek's summary joins into one. First, a user with a role holding the mcp_tool_admin capability could configure a custom API tool to send requests to an attacker-controlled URL, and only a user with mcp_tool_execute could run it. Second, in the CVE text: the server could send the Splunk platform authentication token of the user who runs the tool to the URL configured for it, and if another user controls that URL they could capture the token and use it to access data and perform actions as the user who ran the tool. Two people are involved: one who configures tools, one who runs a tool someone else configured. The vector reads network, high complexity, high privileges, user interaction required, which is why it scores 5.3. Whose token is sent is the part the score cannot see: a user with broad rights who runs a colleague's tool sends a broad token.

The fix is 1.2.1 or higher, and the same number appears in SVD-2026-0808 of 19 August, which named 1.2.1 as the fix for a different MCP Server flaw, CVE-2026-76404, a 9.1 that lets a user holding the admin role run operating-system commands. An instance updated in August for that is already on the October fix version (our inference from the shared version number; Splunk does not say it). Splunk's stated mitigation is to turn off or remove the app. The MCP Server has now been named in four advisories in 308 days: SVD-2025-1210 (3 December 2025), SVD-2026-0407, SVD-2026-0808 and SVD-2026-1004 (derived from Splunk's advisory index). An earlier briefing on the MCP Python SDK found a fix 21 days before its advisory; here the shared version number suggests at least 49.

Is it prompt injection? No model has to be fooled for this flaw. Splunk describes a tool whose configured destination receives a user's token. We checked the site's prompt-injection pattern library for its tool-server entries: tool result injection, connector and tool-description poisoning, multi-agent trust abuse and confused deputy escalation. Each depends on text reaching a model and steering it, and none describes this advisory, so we link none as an explanation. The flaw sits near that family only in what the server holds: user credentials, sent where configuration says.

The NCSC's 20 August 2026 post on agentic AI is written for people building autonomous agents, and this advisory describes no agent misbehaving, so it applies by analogy only. The analogy is credentials: the post says to restrict the credentials an agent can use and describes a proxy that injects them so an agent cannot use them "through an unexpected endpoint". The advisory describes the mirror image, a credential delivered to an unexpected endpoint. Splunk's configuration page says the app installs on a search head or search head cluster and lists Splunk Cloud Platform prerequisites, so Cloud installations exist, and the advisory does not say who updates them.

No exploitation statement yet, and the June precedent for how one arrives

None of the five advisories says whether Splunk is aware of exploitation. That is not a statement that there is no evidence. It is no statement. CISA's catalogue version 2026.10.04, released on 4 October at 18:52 UTC, lists none of the 83 CVEs, but it predates the advisories by three days, so its silence is not a finding. NVD lists all 23 Splunk CVEs as Received.

The CVE records are being enriched while this is written. At 13:36 UTC (14:36 BST) on 8 October CISA's coordinator added a reading to the record for CVE-2026-76268: exploitation none, automatable yes, technical impact total. It had added readings to three lesser CVEs between 13:25 and 13:35 UTC, and none to CVE-2026-76281 or CVE-2026-76284 as of 13:52 UTC. Exploitation none is the coordinator's view of the public record at that minute, not a statement by Splunk. Automatable and total control are two of the four questions in the NCSC's compressed timeline table, which starts from a catalogue listing: CVE-2026-76268 has none in the version read, so the table's rows do not apply as written, but if CISA lists it and your node is internet-accessible, the first row, under 24 hours plus an incident response investigation, is the one that would fit.

June shows how a statement arrives. SVD-2026-0603 covered CVE-2026-20253, a missing authentication flaw (CWE-306) in a PostgreSQL sidecar endpoint scored 9.8, with the same sidecar switch as its mitigation. Splunk published it on 10 June, and on 18 June added that its product security team "became aware of limited exploitation". CISA listed the CVE the same day with a due date three days later, which an earlier briefing found to be the usual deadline. The NHS England Digital alert says exploitation was reported following the release of a proof-of-concept exploit and assesses further exploitation as highly likely. So Splunk's statement came eight days after the advisory (derived), not with it.

CVE-2026-20253 and CVE-2026-76268 share a weakness class and a mitigation. Splunk's October advisory does not connect them, and sharing a class is a similarity of shape, not evidence of cause, reuse or exploitation.

A public exploit claim exists for CVE-2026-76268. A search of GitHub at about 14:35 BST on 8 October found a public repository whose commit messages claim proof-of-concept code for it, committed roughly 15 hours earlier. We did not open the repository, we do not link it, and we do not know whether the code works. We found no such claim for the other two Critical CVEs or for the MCP Server CVE. Splunk's FAQ says it does not distribute exploit code. The NCSC says that where proof-of-concept code exists and a successful attack would do high harm, you should remediate sooner than your business-as-usual timelines, which for internet-facing software is five days.

What this means for UK organisations that run Splunk as their SIEM

What a compromised Splunk would reach, as far as the advisories establish. For CVE-2026-76268 the advisory says operating-system commands on a search head cluster member, and does not say which account runs them. For the other two Critical scores it says nothing about what they give. We do not extend any of that to the rest of the estate. What Splunk's own advisories do show is what its instances hold. SVD-2026-1001 describes a configured Observability Cloud API token (CVE-2026-76274) and other users' search text and results (CVE-2026-76269 and CVE-2026-76275). SVD-2026-1004 describes Splunk platform authentication tokens. The August advisory describes encrypted stored credentials readable through the REST API by a role holding one capability. Those are lesser flaws that need an account, not the three Critical scores, but they say what is lying there. The NCSC's logging guidance puts the risk plainly: "An attacker may well target the logging service in a bid to remove evidence of their actions." It dates from 2018 and still describes the position.

We found no UK publication on these advisories by about 14:45 BST. The NCSC's site-wide feed (its 20 most recent items) names no Splunk item, and NHS England Digital's cyber alert list, whose latest entry was dated 5 October, has none for 7 October. NHS England did issue an alert for the June flaw on 17 June. Absence from those pages says nothing about what either body knows. We have no figure for how many UK organisations run Splunk Enterprise or how many instances are internet-facing.

Patching clocks that apply to Splunk fixes announced on 7 October 2026. Sources: Cyber Essentials Requirements for IT Infrastructure v3.3 (April 2026), Security Update Management; NCSC vulnerability management guidance version 2.1. Dates are derived.

1. Rule

   Cyber Essentials v3.3, Security Update Management

   What it requires

   Updates within 14 days of release where the vendor calls the fixed vulnerabilities critical or high risk, or the CVSS v3 base score is 7 or above; one critical or high fix in a bundle brings the whole update inside 14 days

   Date for a 7 October release

   21 October at the latest. Earlier if the builds shipped before 7 October

2. Rule

   NCSC, update by default

   What it requires

   Internet-facing services and software: install on a test environment or backup first, test and roll out, completed within 5 days

   Date for a 7 October release

   12 October, a Monday, at the latest

3. Rule

   NCSC, update by default

   What it requires

   Internal or air-gapped services and software: 14 days

   Date for a 7 October release

   21 October at the latest

4. Rule

   NCSC, responding to active exploitation

   What it requires

   Compressed timelines of under 24, 48 or 72 hours plus an incident response investigation, set out for flaws on the CISA catalogue

   Date for a 7 October release

   Does not apply as written: none of the 83 CVEs is on the version read. If CVE-2026-76268 is listed and the node is internet-accessible, the first row (under 24 hours) would fit CISA's automatable and total control reading

Rule	What it requires	Date for a 7 October release
Cyber Essentials v3.3, Security Update Management	Updates within 14 days of release where the vendor calls the fixed vulnerabilities critical or high risk, or the CVSS v3 base score is 7 or above; one critical or high fix in a bundle brings the whole update inside 14 days	21 October at the latest. Earlier if the builds shipped before 7 October
NCSC, update by default	Internet-facing services and software: install on a test environment or backup first, test and roll out, completed within 5 days	12 October, a Monday, at the latest
NCSC, update by default	Internal or air-gapped services and software: 14 days	21 October at the latest
NCSC, responding to active exploitation	Compressed timelines of under 24, 48 or 72 hours plus an incident response investigation, set out for flaws on the CISA catalogue	Does not apply as written: none of the 83 CVEs is on the version read. If CVE-2026-76268 is listed and the node is internet-accessible, the first row (under 24 hours) would fit CISA's automatable and total control reading

The clocks run from release of the update, not from the advisory. Splunk's FAQ says it targets publishing advisories several weeks after fixes ship, and the release notes for the four first fixed builds list issues resolved as late as 3 September. That would make the builds at most 34 days old on 7 October (derived), but the 9.4.15 page's own title reads last updated 2026-08-25, a week before that date, so the page's two dates do not agree and neither is a release date. If the builds shipped by early September the Cyber Essentials 14 days ran out on 17 September, and if they shipped by 25 August, earlier. Neither source gives a release date, so check the date on your own download. Whether a Splunk deployment is in scope of a Cyber Essentials assessment is for the organisation and its certification body; if it is, Splunk's Critical label puts the update inside the 14 day rule. The NCSC's update guidance says its timescales apply to all updates regardless of severity, and its active exploitation guidance says critical suppliers and managed service providers should be contractually liable to mitigate exploited flaws quickly. Nobody says exploitation here yet. Ask your supplier anyway.

Two version points matter for planning. Branch 9.4 reaches the end of Splunk Enterprise support on 16 December 2026, 70 days after these advisories, per Splunk's support policy page. Splunk's FAQ says it has not tested the effect of vulnerabilities on versions it does not support, so if you run 9.3 or earlier, which left support on 24 July 2026, the advisories say nothing about you: untested is not unaffected. And Splunk's advance notice, published on 9 September and revised on 10 September, told customers to apply the latest version of these products before the disclosure, which was planned for 16 September and came on 7 October, 21 days later (derived).

What to do, in order

What is not established, and what we could not read

• Whether any of the 23 Splunk CVEs is exploited. Splunk says nothing, CISA's catalogue read predates the advisories, and the public proof-of-concept claim for CVE-2026-76268 is unverified.
• What the two unexplained Critical scores require and give: component, authentication, role, setting, and how many findings each group holds.
• Whether Splunk Enterprise 10.6 is affected. It appears in no product status table.
• Whether any Splunk Cloud Platform tenant was exposed, and whether Splunk has patched them.
• How many instances are exposed to the internet. We read no source for it.
• The release dates of the fixed builds. The advisories and release notes give none.
• NVD's own analysis and score. NVD lists all 23 CVEs as Received. CISA's coordinator had posted readings for four of the 23 by 13:52 UTC, and none for CVE-2026-76281 or CVE-2026-76284.
• How the internal findings were made, and why the Universal Forwarder left the planned disclosure list.
• Whether a public exploit works. We did not open it.

The question

Splunk gave the explanation for one of its three Critical scores and a title, "hardening", for two. A label does not tell you which of your nodes carries a 9.8, and neither does an advisory: only the build string on each node does. The people who needed the fixed builds were told in September to take the latest version, and then waited for the page that says why.

So if one of your search head cluster members were compromised tonight, which record of it would exist on a system the attacker could not reach, and who would be reading that record?

Key facts