EUVD-2026-107647
GHSA-v2f8-fvmq-5mrh
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with low-privilege SOAR account
-
ExploitRequest Automation Broker Compose config endpoint
-
ExecutionServer omits edit-permission check
-
ImpactReceive instance URL, image location and version
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 SOAR account (PR:L) on an instance running a version below 8.7.0; the attacker's account must specifically LACK the Automation Broker edit permission for the missing-authorization check to be relevant (a user who already holds that permission is authorized to retrieve the file). No user interaction is needed and the request is network-reachable. Exploitation is limited by the need for valid credentials and by the low value of the disclosed data (SOAR URL, container image location, and Broker version) - no secrets, credentials, or write access are exposed. Deployments on 8.7.0 or later are not affected. |
| Impact | This is a genuinely low-severity information-disclosure issue, and all signals agree on that rather than conflicting. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N = 4.3 Medium) describes a network-reachable but authenticated (PR:L) flaw with only low confidentiality impact and no integrity or availability impact, consistent with CWE-862 (Missing Authorization). No EPSS score, KEV listing, or POC was provided in the input; there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded: an attacker must already hold a valid low-privilege Splunk SOAR account, and the reward is metadata (the SOAR instance URL, container image location, and Automation Broker version) rather than credentials, code execution, or data modification. This is a real but minor hardening/defense-in-depth fix, not an urgent priority - the leaked version string could marginally aid reconnaissance for a follow-on attack, but the issue itself grants no new access. No key signals conflict; the main gaps are the absence of EPSS/KEV/POC data, whose absence is expected for a low-impact authorization flaw and should not be read as either reassuring or alarming. |
| Exploit ScenarioDerived | A legitimate but limited Splunk SOAR user (for example, an analyst without Automation Broker edit rights) requests the Automation Broker Docker Compose configuration endpoint, which the server returns without checking the edit permission. The user obtains the SOAR instance URL, container image location, and Broker version, which they can use for internal reconnaissance or to profile the deployment for later targeting. No public exploit code is identified at time of analysis, and exploitation requires an existing authenticated session. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Missing authorization in Splunk SOAR (on-premises) below 8.7.0 allows any authenticated user who lacks the Automation Broker edit permission to retrieve the Automation Broker Docker Compose configuration file, which discloses the SOAR instance URL, the container image location, and the Broker version. The endpoint returns the file without enforcing the permission check that is supposed to gate it, so a legitimate low-privileged account can obtain deployment metadata it should not see. Impact is confined to confidentiality (CVSS 4.3, PR:L, C:L) with no secrets, credentials, or write access exposed; there is no public exploit identified at time of analysis and the issue is not in CISA KEV. Instances on 8.7.0 or later are not affected.
RemediationAI
Vendor-released patch: upgrade Splunk SOAR to 8.7.0 or later, which enforces the Automation Broker edit permission before returning the Docker Compose configuration file; see advisory SVD-2026-1010 at https://advisory.splunk.com/advisories/SVD-2026-1010. Until upgrading, reduce exposure by auditing which accounts hold any authenticated SOAR role, since every such account can reach the endpoint regardless of its Broker permissions - disable or remove unused accounts and tighten identity-provider group mappings, accepting that this only narrows the population of abusers and does not fix the check. Treat the disclosed values (SOAR instance URL, container image location, Broker version) as already enumerable metadata and compensate on the perimeter: restrict network access to the SOAR web interface to trusted management networks or VPN, and block egress from SOAR hosts to untrusted registries, with the trade-off of reduced operator convenience and possible disruption to legitimate Broker deployments pulling images. Review web server and proxy logs for unauthenticated or low-privileged requests to Automation Broker configuration endpoints to detect prior probing, and rotate nothing on the basis of this issue alone - the file carries no secrets. Note that no public exploit code has been identified, so prioritization should follow standard patch cadence for a low-severity information-disclosure issue rather than emergency response.
Affected VersionsENISA
Affected Packages
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
The root cause is CWE-862 (Missing Authorization): Splunk SOAR exposes an endpoint that serves the Splunk Automation Broker Docker Compose configuration file, and that handler does not verify that the requesting account holds a role granting Automation Broker edit rights. Splunk SOAR's role-based access control model is expected to gate Broker management functions, but this read path bypasses the check entirely, effectively treating any authenticated session as privileged for this one resource. The exposed artifact is a Docker Compose manifest used when installing the Splunk Automation Broker on a Docker host; it contains the SOAR instance URL, the container image reference, and the Broker version. Those values are deployment metadata rather than credentials - they make environment fingerprinting and version-targeting easier but do not by themselves grant access to the SOAR instance or the Broker. No injection, memory-safety, or deserialization primitive is involved; the weakness is purely an access-control omission on an information-returning request. Note that intelligence tagging describes this as an 'Authentication Bypass', which is imprecise: authentication is still required, and the defect is an authorization failure on a specific object.
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:L/I:N/A:N
Authenticated low-privilege user over the network (PR:L, AV:N, AC:L, no UI); only low-sensitivity metadata is disclosed so C:L with I:N/A:N and unchanged scope.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
1DescriptionCVE.org
In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to edit Automation Brokers could download the Splunk SOAR Automation Broker Docker Compose configuration file. The file contains the Uniform Resource Locator (URL) of the Splunk SOAR instance, the container image location, and the Splunk SOAR Automation Broker version. The vulnerability is possible because Splunk SOAR returns the configuration file without enforcing the Automation Broker edit permission. For more information see Install Splunk Automation Broker on a Docker host (https://help.splunk.com/en/splunk-soar/splunk-automation-broker/install-and-create-classic-splunk-soar-automation-brokers/install-splunk-automation-broker-on-a-docker-host) 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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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