Skip to main content

Splunk SOAR EUVDEUVD-2026-107645

| CVE-2026-76306 HIGH
Information Exposure (CWE-200)
2026-10-21 cisco GHSA-cm97-8h22-4fq2
7.5
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate with Observer role
  2. Delivery
    Craft REST API query filters on user records
  3. Exploit
    Infer password hashes and auth tokens
  4. Execution
    Reuse token or crack hash
  5. Impact
    Escalate to higher-privileged account

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK

2 techniques across 2 tactics: Collection, Discovery

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires an authenticated account holding the Splunk SOAR 'Observer' role (low privilege, PR:L) on an on-premises instance running a version below 8.7.0; the attacker then submits REST API queries whose filter clauses are evaluated against user records before Splunk SOAR strips sensitive fields, exposing other users' password hashes and authorization tokens. Limiting factors: exploitation is NOT possible unauthenticated - a valid Observer (or higher) account is mandatory - and only affects SOAR On-premises builds earlier than the 8.7.0 fix; the AC:H rating reflects that extraction is performed indirectly through crafted filters rather than a single direct read.

Impact

The vendor CVSS of 7.5 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) is driven mainly by the network attack vector and the claim of High impact across Confidentiality, Integrity and Availability. The primary flaw, however, is a CWE-200 information disclosure: an authenticated low-privileged 'Observer' user (PR:L) can abuse REST API query filters to read password hashes and authorization tokens belonging to other users. The direct impact is confidentiality (C:H is well supported); the vendor's I:H and A:H ratings appear to reflect the DOWNSTREAM consequence that stolen authorization tokens and crackable hashes let an attacker impersonate higher-privileged accounts and escalate - not a direct integrity/availability defect - so treat those metrics as secondary-impact-driven rather than direct, and verify against SVD-2026-1010. AC:H signals the exploit requires more than a single trivial request (iterative/blind inference through filter behavior), which modestly lowers ease. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: this is a credible privilege-escalation-enabling disclosure but gated behind valid authenticated access to a specialized SOC product, making it a prioritized internal-threat/insider and lateral-movement concern rather than a mass-exploited internet-facing emergency.

Exploit ScenarioDerived

A low-privileged user holding the 'Observer' role (or an attacker who has compromised such an account) crafts REST API queries against user records with filters that are evaluated before Splunk SOAR masks sensitive fields, causing the API to leak or allow inference of other users' password hashes and authorization tokens. The attacker then reuses a stolen authorization token or cracks an administrator's hash to impersonate a higher-privileged account within the SOAR platform. No public exploit code was identified at time of analysis.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 21, 2026

Information disclosure in Splunk SOAR On-premises (all versions below 8.7.0) allows any authenticated user holding the low-privileged Observer role to recover other users' password hashes and authorization tokens by submitting crafted REST API query filters against user records. The flaw is an ordering problem: filter clauses are evaluated against user objects before Splunk SOAR strips sensitive fields, so an Observer can use boolean or comparison-style filters as an oracle to infer secret values they were never meant to see. Exploitation requires a valid account on an affected on-premises deployment and proceeds indirectly through query behavior rather than a single direct read; no public exploit code has been identified at time of analysis, and the vendor scores this 7.5 while our assessment scopes the realized impact to confidentiality (loss of credentials and API tokens) rather than to integrity or availability.

RemediationAI

Vendor-released patch: upgrade Splunk SOAR On-premises to 8.7.0 or later per advisory SVD-2026-1010 (https://advisory.splunk.com/advisories/SVD-2026-1010); because the defect is in the server-side query pipeline, no client-side or configuration change fully removes it and upgrading is the only complete fix. Where an immediate upgrade is not possible, reduce exposure by auditing and removing the Observer role from accounts that do not strictly need it (trade-off: legitimate read-only monitoring, SOC triage and audit workflows break until an equivalent least-privilege role is defined) and by restricting network access to the SOAR REST API to trusted management hosts or a VPN via firewall or reverse-proxy allowlists (trade-off: automation, SOAR app integrations and remote analyst tooling that call the API will fail unless their sources are explicitly permitted). Treat credentials as potentially compromised on instances that have run with broadly assigned Observer accounts: rotate authorization tokens and force password resets for all SOAR users, since the exposed material is directly reusable for account takeover, and review API access logs for repetitive or algorithmic filter patterns against user endpoints as a hunting signal. After upgrading, verify the sensitive-field protection ordering by re-testing filter queries against user records with a low-privilege account before restoring the Observer role to its prior population.

Affected VersionsENISA

Splunk SOAR 0 <8.7.0

Affected Packages

euvd splunk_soar fix: 8.7.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Splunk SOAR exposes a REST API whose endpoints support a query-filter language for selecting and shaping returned records; the vendor documentation for 'Query for Data' describes how callers pass filter expressions that the backend evaluates server-side. CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) manifests here as an operation-ordering defect: the user-record query pipeline applies caller-supplied filters first and performs sensitive-field protection (redaction of password hashes and authorization tokens) afterwards, meaning the filter engine sees the raw values even though the response body does not. Because the Observer role is Splunk SOAR's read-only / lowest-privilege role, it normally grants visibility into cases, artifacts and other operational data but not into credential material for other accounts - the ordering bug defeats that boundary. The practical extraction primitive is a side channel: an attacker submits many filter predicates whose truth value depends on the secret field, converting the accept/reject or result-count outcome into one bit of information per query. Consequently the disclosure is inference-based rather than a plaintext dump, which increases the number of requests required and explains why the vendor vector carries an elevated attack-complexity component; our own assessment records the network vector, low privileges and confidentiality-only impact (AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N), treating the vendor's High integrity and availability values as not demonstrated. Affected builds are captured by the CPE cpe:2.3:a:splunk:splunk_soar:*:*:*:*:*:*:*:*; the CPE does not encode a version ceiling, so the authoritative bound is the vendor advisory, which places the fix at 8.7.0.

Know when Splunk gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (cisco) PRIMARY HIGH
NVD 7.5 HIGH
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 6.5 MEDIUM

Network REST API (AV:N) usable by any authenticated Observer (PR:L); filter crafting is within attacker control (AC:L); impact is pure disclosure of secrets (C:H, I:N, A:N) despite vendor's I:H/A:H.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (cisco).

CVSS VectorNVD

Attack Vector
Network
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Patch available
Oct 22, 2026 - 02:16 EUVD
CVE Published
Oct 21, 2026 - 22:52 nvd
HIGH 7.5

DescriptionNVD

In Splunk SOAR versions below 8.7.0, a user that has the "Observer" role could use query filters in the Representational State Transfer (REST) API to infer password hashes and authorization tokens for other users. The information disclosure is possible because Splunk SOAR applies REST API query filters to user records before it protects sensitive fields from query processing. For more information see Using the REST API reference for Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/8.5.0/using-the-splunk-soar-rest-api/using-the-rest-api-reference-for-splunk-soar-on-premises), Query for Data (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/7.1.0/using-the-splunk-soar-rest-api/query-for-data), and Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation.

Executive ViewAI

Why It Matters

Splunk SOAR on-premises deployments running any version below 8.7.0 can leak stored password hashes and API authorization tokens to a user holding only the low-privileged Observer role, so a single over-provisioned or compromised read-only account can expose credentials for the wider user base. Because SOAR orchestrates connected security tooling and often stores credentials for downstream platforms, leaked tokens may extend beyond Splunk into automation, ticketing, and incident-response systems. Leadership should care because the disclosure happens indirectly through query behavior rather than an obvious data read, and no vendor-released patch has been identified at time of analysis, leaving access governance and credential rotation as the primary risk levers.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: minimize and routinely audit Observer role membership on all on-premises SOAR deployments, removing unused or stale accounts; rotate password hashes/credentials and revoke authorization tokens for users on affected instances; restrict REST API access to trusted network segments and necessary service accounts only; alert on REST queries against user records that use boolean or comparison-style filters; and confirm with Splunk whether 8.7.0 resolves the flaw, upgrading as soon as that is validated.

Threat Intelligence Overview

EPSS Score
0.2%
Top 88% exploitable
Prevalence
Medium
specialized SOC/SOAR platform common in enterprises but not universally deployed
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

More in Splunk

View all
CVE-2014-0160 HIGH POC
7.5 Apr 07

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe

CVE-2026-20253 CRITICAL POC
9.8 Jun 10

Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.

CVE-2021-22901 HIGH POC
8.1 Jun 11

curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when

CVE-2022-32206 MEDIUM POC
6.5 Jul 07

curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple t

CVE-2024-36985 HIGH POC
8.8 Jul 01

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10, a low-privileged user that does not hold the admin or powe

CVE-2023-46214 HIGH POC
8.8 Nov 16

In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la

CVE-2023-32707 HIGH POC
8.8 Jun 01

In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100,

CVE-2022-43571 HIGH POC
8.8 Nov 03

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through t

CVE-2022-32207 CRITICAL POC
9.8 Jul 07

When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the

CVE-2022-35737 HIGH POC
7.5 Aug 03

SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a

CVE-2022-43551 HIGH POC
7.5 Dec 23

A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Rated high seve

CVE-2022-32221 CRITICAL POC
9.8 Dec 05

When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy