EUVD-2026-94624
GHSA-8rx4-3877-qpv7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Splunk user
-
DeliverySend signature request to Secure Gateway
-
ExploitBypass missing authorization check
-
ExecutionReceive signature over attacker payload
-
ImpactAbuse trusted signed payload
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation 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 Splunk session as a user who does NOT hold the 'admin' or 'power' roles (PR:L), and the Splunk Secure Gateway app must be present and reachable - it ships and is enabled by default in affected Splunk Enterprise builds, so the signing endpoint is typically available. The specific prerequisite is the ability to reach the Secure Gateway signature-request functionality; exploitation is limited by the need for valid (even if low-privilege) credentials and network reachability to the gateway. Impact is bounded to integrity (payload signing) - there is no confidentiality or availability effect - so the realistic risk is confined to environments where platform-signed payloads are subsequently trusted by downstream consumers. |
| Impact | This is a genuine but modest-severity issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3 MEDIUM) is internally consistent with the description: a network-reachable, low-complexity flaw requiring an authenticated but low-privileged account (PR:L - a user WITHOUT the 'admin' or 'power' roles), with no user interaction, and only a limited integrity impact (C:N/I:L/A:N). The CWE-862 (Missing Authorization) classification aligns cleanly with the described root cause - Splunk Secure Gateway does not verify the requester is authorized to obtain a signature. No EPSS score, SSVC decision, KEV listing, or POC indicator was provided in the input; accordingly there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is that an attacker who already has a foothold as any valid low-privilege Splunk user can abuse the gateway as a signing oracle for attacker-controlled payloads, potentially lending platform-trusted signatures to malicious content. Because privileges are required and impact is integrity-only, this is a privilege/authorization-boundary weakness rather than a widely-wormable remote code execution - prioritize patching but it does not warrant the same urgency as an unauthenticated critical. Note the limiting data gap: no EPSS/KEV data was supplied, so exploitation likelihood cannot be quantified from the input. |
| Exploit ScenarioDerived | An attacker who holds (or phishes/obtains) an ordinary low-privilege Splunk user account - one lacking the admin or power roles - sends a crafted request to the Splunk Secure Gateway signing endpoint supplying attacker-chosen payload content. Because the gateway never checks whether that user is authorized to request a signature, it returns a valid signature over the attacker's payload, which can then be presented to downstream components that trust platform-signed data. No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Splunk Secure Gateway (an app bundled with Splunk Enterprise) fails to verify that a requesting user is authorized to ask for a payload signature, so any authenticated Splunk user who does not hold the 'admin' or 'power' roles can coerce the gateway into signing attacker-controlled content. Affected builds are Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, together with Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, as catalogued under CPE cpe:2.3:a:splunk:splunk_secure_gateway and cpe:2.3:a:splunk:splunk_enterprise. The impact is integrity-only (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N): no confidentiality or availability effect, authenticated access and network reachability to the gateway are required, and there is no public exploit identified at time of analysis. Exploitation is confirmed as not appearing in CISA KEV, so the practical risk is confined to deployments where platform-signed payloads are subsequently trusted by downstream consumers.
RemediationAI
Apply the vendor-released patch: upgrade Splunk Enterprise to 10.4.3, 10.2.7, 10.0.10, or 9.4.15 (whichever matches your release train), and upgrade Splunk Secure Gateway to 3.10.11, 3.9.25, or 3.8.72 - on standalone app installs, updating the app alone may be sufficient, but coordinated platform upgrades are the safest path; the full guidance is in Splunk advisory SVD-2026-1001 at https://advisory.splunk.com/advisories/SVD-2026-1001. If immediate patching is not possible, the most direct compensating control is to remove or disable the Splunk Secure Gateway app on instances that do not need it, which eliminates the vulnerable signing endpoint entirely at the cost of losing Secure Gateway functionality (mobile app connectivity, cloud gateway features, and associated integrations) - verify no dependent workflows rely on it first. Where the feature must remain, restrict network reachability to the Secure Gateway service port to trusted management networks and revoke or tightly scope low-privilege accounts (audit roles that lack 'admin'/'power' but retain REST access), accepting that this is access reduction rather than a true fix and that an attacker with any usable credential on a reachable network path remains able to abuse the signing endpoint. Because the impact is integrity-only, also review downstream consumers and trust stores that accept Splunk-signed payloads so that any signatures produced before remediation can be invalidated or rotated.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-862 (Missing Authorization): Splunk Secure Gateway exposes a signature-request function that signs a caller-supplied payload without checking any capability or role constraint on the requesting session. Splunk Enterprise uses a capability-based role model in which 'admin' and 'power' roles carry elevated capabilities, but the gateway endpoint does not enforce that model, so a low-privileged authenticated session (PR:L) can reach the signing operation directly over the network (AV:N, AC:L, UI:N). The affected component is the Secure Gateway app, which ships and is enabled by default in affected Splunk Enterprise builds, meaning the vulnerable endpoint is typically present without any administrator action; the same flaw is tracked across the app's own release trains (3.8, 3.9, 3.10) and the platform versions that bundle them. Because the flaw is a missing authorization check rather than a memory-safety or cryptographic break, the exposure is bounded to the integrity of the signature: an attacker cannot read data or disrupt service (C:N/A:N), but can obtain Splunk-signed artifacts that downstream systems, mobile clients, or trust decisions may accept as legitimate.
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
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Network-reachable low-complexity endpoint needing any low-privilege authenticated account (PR:L), no UI; only limited integrity impact (signing attacker payloads), no confidentiality/availability loss.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
2DescriptionCVE.org
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is possible because Splunk Secure Gateway does not verify that the user is authorized to request a signature. Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72 are also affected. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when
curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple t
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
In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la
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,
In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through t
When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the
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
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Rated high seve
When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t
Exploit-DB