Splunk CVE-2026-76299 and CVE-2026-76302: Patch the 9.9 Flaws

Splunk advisory SVD-2026-1008 fixes four internally found flaws in Splunk Enterprise, two of them scored CVSS 9.9: CVE-2026-76299 and CVE-2026-76302. An attacker needs network access and a valid low privileged Splunk account. Versions 9.4 through 10.4 are affected. Splunk lists no workaround, so upgrade to 10.4.4, 10.2.8, 10.0.11 or 9.4.16.

Splunk published the advisory on Wednesday 21 October 2026 alongside a second Enterprise advisory, SVD-2026-1007, and separate fixes for Splunk SOAR. As of 23 October, nothing we read reports exploitation, CISA's own enrichment of both CVE records says exploitation is "none", and neither CVE is in CISA's Known Exploited Vulnerabilities (KEV) catalog. We checked the catalog ourselves. That is a quiet window, and it is the best time to patch.

The reason to move quickly is where Splunk sits. A Splunk deployment usually holds the most complete record of what happens inside a company: authentication logs, firewall and proxy logs, cloud audit trails, endpoint telemetry and often credentials for the systems it pulls data from. Many people hold an ordinary Splunk login. A flaw that lets one of those ordinary accounts break out of its role, with a changed scope, is a flaw in the system defenders rely on to see everything else.

Below: what Splunk published, the access an attacker needs, affected and fixed versions, how to find every Splunk instance (forwarders, containers and apps included), upgrade commands from Splunk's documentation, what to watch in Splunk's logs, and what would have helped. No exploit details.

What Splunk published

SVD-2026-1008 is titled "Security Hardening in Splunk Enterprise, October 2026" (Splunk's title uses a hyphen where we use a comma). It is unusual in shape. Instead of describing one bug per CVE, Splunk says it "addressed multiple internally identified vulnerabilities" and grouped them by weakness type, assigning one CVE to each group. Each CVE carries the highest CVSS score among the findings in its group.

That has a practical consequence. CVE-2026-76299 is not one bug. It is a bucket of access control findings, and the 9.9 is the score of the worst one in the bucket. Splunk has not described the individual findings, and the advisory does not name the endpoints, roles or capabilities involved.

Source: Splunk SVD-2026-1008, published and last updated 21 October 2026.

Splunk's solution line is short: upgrade Splunk Enterprise to 10.4.4, 10.2.8, 10.0.11 or 9.4.16, or higher. The advisory lists no mitigation and no workaround for any of the four CVEs. It lists no detections and no indicators of compromise.

Technical details

This section collects every concrete value we could read in a primary source. Where a value comes from a secondary source, we say so.

The CVE records

The CVE records were published through the CVE program with Cisco as the CNA. Splunk is a Cisco company, and the records list Splunk as the vendor and Splunk Enterprise as the product. Both record descriptions open with Cisco's statement that it "has conducted a comprehensive internal security review", and both point back to SVD-2026-1008 as the only reference.

The CVE-2026-76302 record attributes its vector to CISA's Authorized Data Publisher (ADP) enrichment, with an SSVC timestamp of 2026-10-22T13:11:36Z. Rescana's write up also says the vector strings were added by CISA ADP. Splunk's advisory page shows the 9.9 score but not a vector string. Neither Splunk nor the CVE records we read give a vector for CVE-2026-76300 or CVE-2026-76301.

What the vector says about attacker access

Read literally, the vector describes this attacker:

So the honest summary of required access is: network reach to the Splunk instance, plus any valid low privileged Splunk account. These are not unauthenticated flaws. An anonymous person on the internet with no credentials does not meet the precondition the score describes.

Splunk does not say which role counts as "low". It does not say whether the default user role is enough, whether a custom role with few capabilities is enough, or whether the path runs through Splunk Web, the REST management port or something else. We are not going to guess. Treat any account that can log in to Splunk Enterprise as meeting the bar until Splunk says otherwise.

The scope change matters too. S:C means the vulnerable component and the impacted component differ. In a Splunk context, that could mean an action that starts in one user's context ends up affecting the server or other users' data. Splunk has not said which, so we will not speculate beyond what the metric defines.

CWE-284 and CWE-707 in plain language

CWE-284, Improper Access Control, is the broad parent class for "the product does not restrict access to a resource correctly". It covers missing authorization checks, checks applied in the wrong place, and roles that can do more than their definition says.

CWE-707, Improper Neutralization, is the broad parent class for failing to make sure that data is well formed and safe before it is read from or sent to another component. The CVE record quotes the CWE definition. Injection flaws sit under this class. Again, Splunk has not said which specific child weakness applies.

Both are pillar level CWEs. That fits the advisory's grouping approach: Splunk chose the broad class and put several findings under it, rather than naming each child weakness.

Affected and fixed versions, straight from Splunk

Source: Splunk SVD-2026-1008. HKCERT's bulletin of 22 October lists the same four ranges.

The advisory names no version older than 9.4. If you run 9.3 or earlier, the advisory does not tell you whether those builds share the flaws; it simply offers no fixed build on those lines. Plan a move to a supported line.

The companion advisory, SVD-2026-1007

The same release ships fixes for a second Enterprise advisory, SVD-2026-1007, "Security Vulnerabilities in Splunk Enterprise, October 2026". It has the same fixed versions and a highest score of 8.8. Unlike the hardening advisory, it describes each bug. You get all of these fixes from the same upgrade, so they belong in your change ticket.

Source: Splunk SVD-2026-1007.

SVD-2026-1007 does list interim mitigations for some of its own CVEs, which SVD-2026-1008 does not. According to Splunk:

• CVE-2026-76287: set spl2_preview_enabled to false in server.conf if you do not use SPL2 previews, then restart.
• CVE-2026-76288: turn off Splunk Web.
• CVE-2026-76290: remove or disable the Pipeline Builders app; after upgrading, enable authentication for Edge Processor package downloads.
• CVE-2026-76292 and CVE-2026-76295: turn off or remove the Splunk Secure Gateway app, which affects Splunk Mobile, Spacebridge and Mission Control. The app fixes are Splunk Secure Gateway 3.10.12, 3.9.26 or 3.8.73.
• CVE-2026-76298: disable the PostgreSQL sidecar in server.conf, then restart, unless you use Edge Processor, OpAmp or SPL2 pipelines.

Two details in SVD-2026-1007 are worth reading carefully on Splunk's page. CVE-2026-76298 lists fixed builds only on the 10.4 and 10.2 lines. And the description of CVE-2026-76293 says "below 10.4.3" while its product table names 10.4.4 as the fix. Upgrading to 10.4.4 covers both readings.

None of those mitigations apply to CVE-2026-76299 or CVE-2026-76302. For the two 9.9 flaws, the only remedy Splunk lists is the upgrade.

What else shipped the same day

Splunk SOAR received its own advisories on 21 October. SecurityWeek reports that SOAR 8.7.0 fixes 15 vulnerabilities in SOAR's code plus more than a dozen in third party libraries, with CVE-2026-76531 and CVE-2026-76407 the most severe. SecurityOnline lists the SOAR advisories as SVD-2026-1010 and SVD-2026-1011 and gives CVE-2026-76531 a 9.9. If you run SOAR, it needs its own upgrade to 8.7.0; it is a separate product from Splunk Enterprise.

Timeline

Times are UTC unless marked. Where a source gives only a date, we give only a date.

Exploitation status, stated plainly

• Not reported exploited. Splunk's advisory does not mention exploitation. SecurityOnline reports no in the wild exploitation and no confirmed public proof of concept. Rescana reports the same. CISA's SSVC enrichment in both CVE records says exploitation is "none".
• Not in CISA KEV. On 23 October we read CISA's KEV JSON feed. Its catalog version is 2026.10.21, released at 14:04:39 UTC on 21 October, which is before the CVE records were published that night. The newest entries are dated 20 October (SiteGuard Server Edition and Plex Media Server, among others). Neither CVE ID appears in the portion we read, and the catalog search page shows no Splunk entry among recent additions. Rescana independently reports the same.
• Not automatable, per CISA. The SSVC "automatable: no" judgment means CISA does not consider these flaws reliably exploitable at scale without human effort. Combined with the need for a login, that lowers the odds of a mass scanning wave. It does not lower the stakes for a targeted attacker who already has a Splunk account.

Status can change in an afternoon. If either CVE lands in KEV, US federal civilian agencies get a deadline and everyone else gets a strong signal. Check the KEV catalog and Splunk's advisory page before you close the ticket.

Splunk Cloud Platform versus Splunk Enterprise

SVD-2026-1008 lists only Splunk Enterprise. It does not list Splunk Cloud Platform as affected, and it does not say Splunk Cloud Platform is patched. SVD-2026-1007 is the same: Splunk Enterprise only, plus the Splunk Secure Gateway app. Rescana reports that it found no Splunk statement on Cloud status either.

Some earlier Splunk advisories carried a separate Splunk Cloud Platform row in the versions table. This one does not. We are not going to fill the gap with an assumption in either direction.

What that means for you:

The heavy forwarder row is the one most teams miss. Organisations that moved search and indexing to Splunk Cloud often keep heavy forwarders on premises to parse, filter or route data before it leaves. Those machines run Splunk Enterprise, they often hold credentials for the data sources they pull from, and they are usually owned by whoever set them up years ago.

Who is affected

Any Splunk Enterprise installation on an affected version, whatever its role. In a distributed deployment that includes:

• search heads and search head cluster members
• indexers and indexer cluster peers
• cluster managers and search head cluster deployers
• license managers
• deployment servers
• monitoring console hosts
• heavy forwarders
• single instance deployments used for a team, a lab or a proof of concept
• Splunk Enterprise containers, including those managed by the Splunk Operator for Kubernetes

Splunk's advisory does not break exposure down by component, and Rescana notes that its own component guidance is its own rather than Splunk's. The safe reading is that every Splunk Enterprise binary on an affected version needs the upgrade. The components with the most exposure are the ones where many users log in, which in practice means search heads.

How to find every Splunk instance you own

You cannot patch what you have not found. Splunk tends to spread: the production cluster everyone knows about, a heavy forwarder in each data centre, a security team's lab instance, a developer's container, a monitoring console nobody remembers installing. Work through these sources and merge the results into one list with host, role, version and owner.

1. Ask Splunk itself, from a search head

On a search head that can reach your peers, this search returns the version and roles of every Splunk server the search head knows about:

| rest /services/server/info splunk_server=*
| table splunk_server version server_roles os_name
| sort version

Anything on a version inside the affected ranges goes on the list. The server_roles column tells you whether it is a search head, indexer, cluster manager, license manager, deployment server and so on. This only sees instances connected to this search head, so treat it as a starting point.

2. Find forwarders from the indexers' connection metrics

Indexers log every forwarder connection in their internal metrics. This widely used community search lists each forwarder with its reported version and type:

index=_internal source=*metrics.log* group=tcpin_connections
| stats latest(version) AS version latest(fwdType) AS fwdType latest(os) AS os max(_time) AS last_seen BY hostname sourceIp
| eval last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort fwdType version

Community answers map fwdType values to universal, light and full (heavy) forwarders. Every row with a full forwarder type is a Splunk Enterprise install and needs checking against the affected ranges. Universal forwarders are not named in these advisories. Field names can vary by version, so confirm them on your own data before relying on the output.

3. List deployment server clients

If you use a deployment server, it knows every client that phones home. On the deployment server:

$SPLUNK_HOME/bin/splunk list deploy-clients

Or from a search head that can reach it:

| rest /services/deployment/server/clients splunk_server=<deployment-server-name>
| table hostname ip utsname lastPhoneHomeTime

Clients that are heavy forwarders or full instances go on the list. Run the REST search only if your deployment server is a search peer; otherwise use the CLI.

4. Check each host directly

On Linux or macOS hosts:

# Version of an installed instance
$SPLUNK_HOME/bin/splunk version
cat $SPLUNK_HOME/etc/splunk.version

# Find installs that are not where you expect
ls -d /opt/splunk* /opt/*/splunk* 2>/dev/null
rpm -qa | grep -i splunk
dpkg -l | grep -i splunk
systemctl list-units --all | grep -i splunk

# Find listening Splunk services (default ports: 8000 Web, 8089 management, 9997 receiving)
ss -ltnp | grep -E ':(8000|8089|9997)\b'

On Windows hosts, from an elevated prompt:

"C:\Program Files\Splunk\bin\splunk.exe" version
type "C:\Program Files\Splunk\etc\splunk.version"
sc query state= all | findstr /i splunk

A splunk.version file shows VERSION= and BUILD= lines. The universal forwarder installs under SplunkUniversalForwarder by default, which helps you tell the two products apart on a host.

5. Find Splunk in containers and Kubernetes

# Running containers from Splunk images
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i splunk
docker exec <container> /opt/splunk/bin/splunk version

# Kubernetes pods using Splunk images
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep -i splunk

# If you use the Splunk Operator for Kubernetes
kubectl get standalones,searchheadclusters,indexerclusters,clustermanagers,licensemanagers,monitoringconsoles -A

Image tags tell you what you intended to run. The splunk version output inside the container tells you what is actually running. Check both, and fix the tag in the manifest or Helm values, not just the running pod.

6. Sweep the network for listeners you do not know about

From an authorised scanning host, on networks you own:

nmap -p 8000,8089,9997 --open -sV 10.0.0.0/16 -oG splunk-sweep.txt

Default ports can be changed, so this finds the careless installs, not every install. Compare the result with your list. Every unknown listener is either a Splunk instance you need to patch or something else you need to understand.

7. Inventory the apps on each instance

Apps do not carry these two CVEs, but they matter for two reasons. The companion advisory has app specific fixes (Splunk Secure Gateway) and app specific mitigations (Pipeline Builders). And apps are code that runs inside the most trusted log store you have.

| rest /services/apps/local splunk_server=*
| table splunk_server title label version disabled
| sort splunk_server title

To check Splunk Secure Gateway specifically:

| rest /services/apps/local splunk_server=*
| search title="splunk_secure_gateway"
| table splunk_server title version disabled

Compare against Splunk Secure Gateway 3.10.12, 3.9.26 and 3.8.73. While you have the list open, note any app nobody can explain. That is a separate finding, and a useful one.

8. Write it down

How to upgrade, using Splunk's documented steps

Within a line, the move is a maintenance update: 10.2.7 to 10.2.8, 9.4.15 to 9.4.16 and so on. You do not have to change feature versions to get the fix. That is the fastest route and the one we recommend for this advisory. Feature upgrades (for example 10.0 to 10.4) follow Splunk's upgrade path rules: per Splunk's 10.4 upgrade guide, 10.2.x can go straight to 10.4.x, while 9.4.x needs an intermediate hop through 10.0.x or 10.2.x and 9.3.x first goes to 9.4.x or 10.0.x. Check the path table for your exact starting version.

Before you start

Splunk's upgrade guide asks for these steps, and they are worth doing even for a maintenance update:

1. Back up configurations, indexed data and the KV store, and confirm the backups restore. Splunk Enterprise does not support downgrading; to go back you uninstall and reinstall the older version.
2. Capture deployment health in the Monitoring Console, so you have a baseline to compare against afterwards.
3. Confirm forwarders are compatible with the target indexer version using Splunk's compatibility matrix.
4. Confirm indexers have enough disk space and run basic searches successfully.
5. Confirm your apps and dashboards work on the target version. Splunk recommends testing apps on a reference machine first.
6. Have security keys and credentials to hand.

Single instance on Linux

Splunk's "Upgrade on UNIX" page gives these commands. Stop the service:

systemctl stop Splunkd.service
# or
$SPLUNK_HOME/bin/splunk stop

Install the new package over the existing one, in the same directory and with the same ownership as the existing install. For a tarball (substitute the 10.4.4, 10.2.8, 10.0.11 or 9.4.16 package you downloaded from Splunk):

tar xzf splunk-<version>-<build>-linux-amd64.tgz -C /opt

For an RPM:

rpm -U <splunk_package_name>

Start Splunk. Splunk does not change your configuration until it restarts. On first start you can preview the migration changes, which are written to $SPLUNK_HOME/var/log/splunk/migration.log.<timestamp>; if you preview, the script does not start services and you start Splunk again afterwards. For an unattended upgrade that accepts the license and skips the preview:

$SPLUNK_HOME/bin/splunk start --accept-license --answer-yes

Then confirm:

$SPLUNK_HOME/bin/splunk version

On Windows, Splunk's documentation covers upgrading with the MSI installer over the existing install. Follow Splunk's "Upgrade on Windows" page for your version and confirm with splunk.exe version afterwards.

Distributed deployment without clusters

Splunk's distributed upgrade page gives this order:

1. Test your apps on a reference machine first.
2. Optionally disable the deployment server temporarily so it does not push invalid configurations, and optionally upgrade it without restarting it yet.
3. Upgrade search heads one at a time: stop the search head, upgrade it without letting it restart, put your confirmed working apps in $SPLUNK_HOME/etc/apps, then restart and test. If it works, repeat for each remaining search head.
4. Upgrade indexers one at a time. Each can restart right after its upgrade. Confirm search heads find data across all indexers.
5. Restart the deployment server.
6. Review forwarder versions for compatibility. Heavy forwarders on affected versions need the same upgrade.

Search heads go first so the environment stays available. Splunk also says to confirm that upgraded components stay compatible with the ones you have not upgraded yet.

Indexer clusters

Splunk's rolling upgrade page for indexer clusters gives this sequence:

# 1. On the cluster manager: check health
splunk show cluster-status --verbose

# 2. Upgrade the cluster manager (standard upgrade), then the search head tier

# 3. On the cluster manager: start the rolling upgrade (enters maintenance mode)
splunk upgrade-init cluster-peers

# 4. On each peer, one at a time
splunk offline
#    upgrade the peer using the standard procedure, then
splunk start

# 5. Confirm the peer's version through the manager's REST API: GET cluster/manager/peers/<peer-GUID>

# 6. After the last peer, on the cluster manager
splunk upgrade-finalize cluster-peers

Splunk's warnings for this procedure: do not run clustering maintenance operations during the upgrade (no rolling restarts, bundle pushes or new nodes); taking several peers offline at once can affect searches; keep search_retry in limits.conf at its default of false; searches running longer than the 180 second default decommission_search_jobs_wait_secs may return incomplete results. With the default search factor of 2, upgrade one peer at a time. With a search factor of 3 or more, Splunk allows search factor minus one peers at once.

Search head clusters

Splunk documents a separate rolling upgrade for search head clusters in its Distributed Search manual ("Upgrade a search head cluster"). Follow the page for your target version.

Containers and Kubernetes

For containers, change the image tag to the fixed release in your Compose file, manifest, Helm values or Splunk Operator custom resource, and let your normal rollout replace the pods. Then run splunk version inside a replaced container to confirm. Do not patch inside a running container; the next restart will undo it.

After the upgrade

Splunk's post upgrade checks include: apps and add ons behave as before; resource use matches your Monitoring Console baseline; the license manager works and all indexers connect to it; the cluster manager is healthy and peers reconnect; search and indexing tiers talk without errors; search head cluster members are in a good state. Then re-run the version search from step 1 of the inventory and confirm nothing is left on an affected build.

What to watch in Splunk's own logs

Splunk has published no indicators of compromise, no detections and no description of what exploitation would look like. So there is nothing specific to hunt for. What you can do is watch the places where misuse of a Splunk account would show up, and make sure that record lives somewhere a compromised Splunk admin cannot edit.

Review recent changes to users and roles in the audit index. Adjust the action values to what your version logs:

index=_audit sourcetype=audittrail (action=edit_user OR action=edit_roles OR action=*_user OR action=*_role*)
| table _time user action info object
| sort - _time

Review who logged in to Splunk Web and from where:

index=_internal sourcetype=splunk_web_access
| stats count min(_time) AS first max(_time) AS last BY user clientip
| convert ctime(first) ctime(last)
| sort - last

Review REST management API activity by user, looking for accounts that do not normally call the API:

index=_internal sourcetype=splunkd_access
| stats count dc(uri_path) AS distinct_paths BY user clientip
| sort - count

Look for apps installed or changed recently by comparing the app inventory above with last week's, and look for new or modified scripted inputs and alert actions, which are the parts of an app that run code.

These are hunting starting points, not detections for these CVEs. Their value is that you will notice when an ordinary account starts acting like an administrator. Forward _audit and _internal from your search heads to a destination with separate administration, so the record survives if a Splunk admin account is ever abused.

What changed since first reports

• Counts settled, then diverged. SecurityWeek counted 16 Splunk Enterprise CVEs, which matches HKCERT's range of CVE-2026-76287 through CVE-2026-76302 across SVD-2026-1007 and SVD-2026-1008. Cybersecurity News counts 24 vulnerabilities across three advisories. SecurityOnline counts 31 CVEs across four advisories, including both SOAR advisories. The differences come from which SOAR advisories each outlet included.
• Critical counts differ. SecurityOnline lists three critical CVEs at 9.9 (CVE-2026-76299, CVE-2026-76302 and SOAR's CVE-2026-76531). Cybersecurity News lists four, adding SOAR's CVE-2026-76407 at 9.3. Both agree on the two Enterprise 9.9s.
• Vectors arrived after the advisory. Splunk's page shows scores only. The vector strings appear in the CVE records, added by CISA ADP on 22 October according to the record and Rescana.
• HKCERT rated the bulletin Medium. That is HKCERT's own rating across all the CVEs in the two advisories; it does not change Splunk's 9.9 scores.
• NVD has not scored them yet. Rescana reports all four SVD-2026-1008 CVEs as "Awaiting Analysis" at NVD as of 23 October. An NVD score may differ from Splunk's when it lands.
• Use Splunk's version ranges. Third party vulnerability mirrors sometimes copy ranges incorrectly. We used Splunk's own table throughout, and so should you.

Open questions

• Which role or capability is the "low privilege" in PR:L? Is the default user role enough?
• Which interface is involved: Splunk Web, the management port, or both?
• Is Splunk Cloud Platform affected, and if so, has Splunk already patched it?
• Are versions older than 9.4 affected? The advisory is silent.
• How many separate findings sit inside each grouped CVE, and do any of them chain together?
• Will Splunk publish per finding detail later, as it does for its regular advisories?

We will update this post when Splunk answers any of these.

What would have helped

None of this is a comment on any particular organisation. These are practices any team that runs Splunk can adopt, and they echo the lessons in our roundup of October 2026 incidents.

Treat the SIEM as a tier zero system. Tier zero means the systems that, if compromised, give an attacker control of or visibility into everything else: identity providers, domain controllers, CI systems, secrets stores. A SIEM belongs on that list. Give it the same patch SLA, the same change control and the same monitoring as your identity provider.

Keep a live inventory of Splunk components and versions. With a current list, "are we affected" is a one hour question.

Stay on a supported line and stay current within it. This advisory has fixes for four lines. A team on the latest maintenance release of a supported line applies one small update. A team on an unsupported line faces a multi step upgrade with app testing while the clock runs.

Minimise who has a Splunk login, and what each login can do. PR:L flaws turn every account into a potential starting point. Review SAML or LDAP group mappings and remove broad mappings to default roles. Disable accounts for people who have left. Give service accounts the narrowest role that works, and rotate their credentials on a schedule.

Control who can install and change apps. Apps run code inside Splunk. Limit app installation and editing to a small admin group, require a review before an app reaches production, and keep a baseline of installed apps per instance.

Keep management interfaces off the internet. Splunk Web and the management port do not need to be reachable from the internet in most deployments. Put them behind your VPN or zero trust access layer. That does not remove a PR:L risk, but it means an attacker needs both a credential and a network path.

Ship Splunk's own audit trail somewhere else. If the only copy of Splunk's audit log lives in Splunk, a Splunk administrator can change it. Forward _audit to a second destination with separate administration.

Know which forwarders are heavy. Heavy forwarders are full Splunk Enterprise installs, often with credentials for the data sources they collect from, and they are easy to forget. List them, give them owners, and include them in every Splunk patch.

Where Safeguard fits

Safeguard does not patch Splunk Enterprise, does not detect exploitation of these CVEs, and does not change Splunk roles. The upgrade has to come from Splunk, using the steps above. Here is where Safeguard does help.

• Inventory what you build and run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> scans an SBOM file, with JSON results under ./output. If you run Splunk Enterprise or heavy forwarders from container images, you can scan those images to see their components. Whether a Splunk application advisory is matched depends on the vulnerability data, so still confirm the Splunk version with splunk version against the table in this post.
• Find where a component lives. The platform shows which projects contain a given component and version. For the repos that hold your Splunk Helm values, Compose files or custom app code, that tells you where a version needs changing. Our post on using SBOMs in incident response walks through that kind of query.
• Prioritise. Vulnerability matching against vulnerability databases, with reachability analysis, helps separate what is exploitable from the long tail in the code and images you build, including custom Splunk apps that bundle their own libraries.
• Gate rebuilds. Policies and gates evaluated in the platform, and safeguard exec in CI, can stop a rebuilt image from shipping if it still pulls a known vulnerable component.
• Do the change work with approval. The Safeguard CLI's assistant can run commands and edit files with your approval. You can ask it to run the version checks in this post on an admin host, change a Splunk image tag in a manifest to the fixed release, or draft the change ticket from the inventory table. Set /permissions to Ask or Strict for server work, so every command waits for you. The desktop and phone apps can send that work to a computer running the CLI and let you approve each command.

Zero-Day Discovery and Gold

Two Safeguard capabilities are about finding and fixing flaws in components earlier.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Splunk Enterprise is commercial software shipped as OS packages and container images, which is outside that scope.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit they support applies to the open source components in the code and images you build around Splunk, such as custom apps, integration scripts and base images, not to the Splunk Enterprise binary itself: pull patched, signed components from a curated source, and be able to rebuild and redeploy quickly when an advisory lands.

Common mistakes

Patching the search heads and forgetting the heavy forwarders. They run the same software. They are usually in a different team's estate. Find them with the forwarder search and the deployment server list.

Assuming Splunk Cloud means no work. Your search tier may be Splunk operated, but heavy forwarders and any on premises Splunk Enterprise you keep are yours. And for the Cloud stack itself, ask Splunk rather than assume.

Upgrading the universal forwarder fleet instead. The universal forwarder is not named in these advisories. Rolling thousands of endpoints buys nothing here and burns your change window.

Treating "low privilege required" as "low risk". In a SIEM, analysts, service accounts and SSO mapped groups all hold ordinary logins, and a phished session counts too. A credential plus network reach is the whole precondition.

Applying SVD-2026-1007 mitigations and calling it done. Turning off Splunk Web or the Secure Gateway app addresses specific bugs in the companion advisory. They do nothing for CVE-2026-76299 or CVE-2026-76302.

Skipping the backup because it is "only a maintenance release". Splunk does not support downgrading. The backup is your rollback.

Closing the ticket without re-running the inventory. The version search takes seconds. Run it after the last change and attach the result.

FAQ

What access does an attacker need for CVE-2026-76299 and CVE-2026-76302?

Network access to the Splunk Enterprise instance and a valid Splunk account with low privileges, with no user interaction, per the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H in the CVE records. Splunk has not said which role or capability is enough, so treat any account that can log in as sufficient.

Are these flaws being exploited?

Not as far as anyone has reported. Splunk's advisory does not mention exploitation, CISA's SSVC enrichment in both CVE records says exploitation is "none", and SecurityOnline and Rescana report no in the wild exploitation and no public proof of concept as of 23 October 2026.

Are they in CISA's KEV catalog?

No. We checked CISA's KEV feed on 23 October 2026. The current catalog version, 2026.10.21, has no entry for either CVE and no recent Splunk entry. Check again before you close your ticket, because KEV is updated as evidence of exploitation arrives.

Is Splunk Cloud Platform affected?

Splunk's advisory lists only Splunk Enterprise and says nothing either way about Splunk Cloud Platform. Ask Splunk support about your stack. Any heavy forwarders or Splunk Enterprise instances you run alongside Splunk Cloud are yours to upgrade.

Is there a workaround if I cannot upgrade today?

Splunk lists none for SVD-2026-1008. Until you upgrade, reduce exposure: review and prune Splunk accounts and SSO group mappings, keep Splunk Web and the management port off the internet, and watch the audit queries in this post. Those steps lower risk; they do not fix the flaws.

Do I need to upgrade universal forwarders?

These advisories do not name the universal forwarder. Heavy forwarders are different: they are full Splunk Enterprise installs and need the upgrade if they run an affected version.

I run Splunk Enterprise 9.3 or older. What now?

The advisory does not list versions older than 9.4 and offers no fix for them. You need to move to a supported line. Splunk's upgrade path rules for 10.4 say 9.3.x upgrades first to 9.4.x or 10.0.x; moving to 9.4.16 is the shortest path to a fixed build.

Can I go straight from 9.4 to 10.4.4?

Not per Splunk's 10.4 upgrade guide, which says 9.4.x upgrades first to 10.0.x or 10.2.x before moving on. For this advisory you do not need a feature upgrade at all: the maintenance update within your line, 9.4.16, carries the fix. Do the feature upgrade later, on its own schedule.

Why are the fixes grouped by CWE instead of listed one by one?

Splunk's hardening advisory groups multiple internally identified findings by weakness type and assigns one CVE per group, with the group's highest score. Splunk has not explained the choice beyond that description. The practical effect is that each CVE may cover several bugs, and the upgrade fixes all of them.

Does Splunk SOAR need patching too?

Yes, separately. SOAR has its own advisories from the same day, fixed in SOAR 8.7.0 according to SecurityWeek, SecurityOnline and Cybersecurity News.

Fix it without waiting for upstream

In this incident the vulnerable code is a commercial product, so the Splunk Enterprise fix itself comes from Splunk. The open source libraries inside your custom Splunk apps, integration scripts and the base images you build around Splunk are a different story, and that is where the approach below applies.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none shows this Splunk advisory.

The CLI demo shows the assistant fixing a lodash CVE in a repository: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For SVD-2026-1008, the same approval flow applies on an admin host: ask the assistant to run splunk version on each instance from your inventory, or to change the Splunk image tag in your Kubernetes manifest to the fixed release, and approve each command yourself.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and an Approve or Deny decision on each command and file edit, ending with an upgrade done and tests passing. For this advisory, you would point it at the repo that holds your Splunk Helm values, Compose file or Splunk Operator resources and ask it to move every Splunk Enterprise image to 10.4.4, 10.2.8, 10.0.11 or 9.4.16, approving each edit.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session that sends work to a computer running the CLI and approves a command on the phone with Allow once, Allow for turn or Deny. Splunk upgrades usually happen in a night maintenance window; this is how the on call engineer can approve each peer's splunk offline and version check from a phone without handing the assistant open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For more on other urgent October fixes, see our post on edge device zero days of October 2026 and our guide to the Safeguard CLI as a security aware coding assistant.

Quick check

Sources

• Splunk SVD-2026-1008: Security Hardening in Splunk Enterprise, October 2026
• Splunk SVD-2026-1007: Security Vulnerabilities in Splunk Enterprise, October 2026
• CVE record CVE-2026-76299 (CVE Services API)
• CVE record CVE-2026-76302 (CVE Services API)
• CISA Known Exploited Vulnerabilities catalog, JSON feed
• CISA Known Exploited Vulnerabilities catalog
• HKCERT: Splunk Products Multiple Vulnerabilities, 22 October 2026
• Splunk Docs: How to upgrade Splunk Enterprise (10.4)
• Splunk Docs: How to upgrade a distributed Splunk Enterprise environment (10.4)
• Splunk Docs: Upgrade on UNIX (10.4)
• Splunk Docs: Perform a rolling upgrade of an indexer cluster (10.4)
• SecurityWeek: Splunk, SolarWinds release fresh security updates
• SecurityOnline: Splunk vulnerabilities in Enterprise and SOAR, October 2026
• Cybersecurity News: Splunk fixes 24 security flaws
• Rescana: Splunk Enterprise security hardening, CVE-2026-76299

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.