Splunk

Log injection in @logtape/syslog allows network-accessible attackers to forge arbitrary syslog records in downstream collectors such as rsyslog, Splunk, and Elastic Stack. The escapeStructuredDataValue() function omits C0 control character escaping, so a literal newline embedded in a log property value terminates the current RFC 6587 TCP syslog frame and begins a new one; if the attacker-supplied bytes constitute a valid RFC 5424 header, the downstream collector accepts them as a separate, authentic-looking record. A second injection path exists through unvalidated SD-NAME keys, which can prematurely close structured-data elements. Both paths require the non-default SyslogSinkOptions.includeStructuredData: true setting. Publicly available proof-of-concept code exists; no CISA KEV listing at time of analysis.

Partial API key exposure in Splunk On-Call (VictorOps) app versions below 1.0.43 allows any authenticated Splunk user - regardless of role - to read a partially masked VictorOps API key from the App Key Value Store (KV Store). The app fails to fully mask the API key prior to persisting it in a KV Store collection that is readable by low-privileged users who do not hold the 'admin' or 'power' Splunk roles, violating the principle of least-privilege for credential storage. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the CVSS score of 4.3 aligns with the limited, partial credential exposure.

Operating-system command execution in the Splunk MCP Server app (all versions below 1.2.1) lets a user already holding the Splunk 'admin' role run arbitrary commands on the underlying host by abusing unsafe deserialization in the credential-management component. Because the app trusts stored data and deserializes it without verifying the object type, a privileged Splunk user can escalate from application-level administration to full host compromise. No public exploit identified at time of analysis, and it is not listed in CISA KEV; a vendor patch is available.

Certificate validation bypass in Splunk Connect for Kafka below version 2.2.7 allows a network-positioned unauthenticated attacker to intercept and modify event data in transit to Splunk Enterprise's HTTP Event Collector when Kerberos authentication is configured. The Kerberos code path fails to apply the connector's configured TLS certificate validation options when constructing the HTTP client, effectively negating transport security despite HEC's TLS configuration. No active exploitation has been identified (not in CISA KEV), but the confidentiality and integrity impact on Splunk-ingested telemetry data is high.

Unauthenticated access to the Kafka Connect REST API in Splunk Connect for Kafka versions below 2.2.7 enables an SSRF-class attack that reconfigures the HTTP Event Collector destination to an attacker-controlled endpoint, resulting in theft of HEC authentication credentials and partial manipulation of event delivery to Splunk Enterprise. The connector's HEC endpoint validation does not enforce secure transport by default, meaning a non-TLS HTTP destination can be substituted without any authentication. No public exploit has been identified at time of analysis, but the attack requires no privileges and trivially low complexity, making any deployment with a network-exposed Kafka Connect REST API immediately actionable.

Unauthenticated ReDoS in Splunk Connect for Kafka below version 2.2.7 allows a network-accessible attacker to permanently block a Kafka Connect worker thread by submitting a pathological regular expression via the Kafka Connect REST API, which - when triggered by attacker-supplied or coincident matching event data during timestamp extraction - causes the regex engine to backtrack catastrophically without bound. The practical result is complete stoppage of event delivery for the targeted connector, constituting a targeted denial-of-service against Splunk data ingestion pipelines. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS AC:H rating reflects the two-condition prerequisite, moderating the net risk score to 5.9 Medium despite the unauthenticated network vector.

Splunk Connect for Kafka below version 2.2.7 contains an uncontrolled resource consumption flaw in its HTTP Event Collector retry mechanism, enabling an unauthenticated network attacker who can also manipulate HEC endpoint responses to trigger an infinite retry loop that permanently halts Kafka-to-Splunk event delivery. The vulnerability arises because the connector applies an unbounded default retry count for failed HEC batches rather than a finite limit, causing the connector to stall indefinitely when fed persistent failure responses. No active exploitation has been confirmed - the vulnerability is not in CISA KEV - and no public exploit code has been identified at time of analysis.

Splunk AI Toolkit before version 6.0.1 allows authenticated users holding the built-in 'power' role to modify app-provided scheduled searches, which execute SPL under the permissions of the search owner rather than the modifying user. By injecting arbitrary SPL into such searches, a 'power' role user can access all data visible to the search owner and alter system integrity - effectively escalating privileges beyond their authorization level. No public exploit code or active exploitation has been identified at time of analysis.

Missing authorization in Splunk AI Toolkit below version 6.0.1 allows any authenticated low-privilege user to delete the experiment history belonging to another user via the REST API. The root cause is a sequencing flaw: the Toolkit executes the deletion operation before verifying whether the requesting user holds permission to delete the target experiment, violating the principle of check-before-act. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog; however, a patch is available in version 6.0.1.

Unauthorized cross-user data access and deletion in Splunk AI Toolkit below 6.0.0 allows any authenticated user holding the 'power' Splunk role to read and destroy experiment history records belonging to other users. The root cause is CWE-639 (IDOR): the toolkit fails to preserve a trusted experiment scope boundary when processing caller-controlled query values, enabling horizontal privilege escalation across all experiment history without touching admin-level permissions. No active exploitation or public exploit code has been identified at time of analysis; a vendor-released patch (6.0.0) is available per Splunk advisory SVD-2026-0808.

Improper access control in Splunk AI Toolkit versions below 6.0.0 allows an authenticated user holding the schedule_search capability to deserialize arbitrary model files by invoking the apply search command via a scheduled search. Because the toolkit does not designate apply as a risky command, Splunk's built-in risky-command access controls are never triggered, enabling privilege escalation beyond what the role should permit. A vendor-released patch exists (version 6.0.0); no public exploit or CISA KEV listing has been identified at time of analysis.

Arbitrary code execution in Splunk AI Toolkit below 6.0.0 is achievable by any user holding the Splunk 'power' role, through loading a crafted model file that embeds malicious pickle payloads inside sparse matrix data. The toolkit's model codec deserializes this data without sanitizing or restricting the embedded pickle content, granting the attacker code execution as the Splunk server process. No public exploit or CISA KEV listing has been identified at time of analysis, but the RCE impact with a low-privilege network vector makes this a high-priority patch target for any Splunk deployment running the AI or Machine Learning Toolkit.

Missing authorization checks across multiple REST API handlers in Splunk AI Toolkit versions below 6.0.0 allow any low-privileged authenticated Splunk user - one who holds neither the 'admin' nor 'power' role - to start, stop, and reconfigure containers and to read or modify sensitive connection and configuration data. The vulnerability stems from CWE-862 (Missing Authorization), where the REST endpoints simply omit role-based access enforcement rather than incorrectly implementing it. No public exploit code and no CISA KEV listing have been identified at time of analysis, but the low attack complexity and the fact that it was reported by Cisco make it a credible near-term target.

Unauthenticated model content injection in Splunk AI Toolkit below 6.0.0 allows an authenticated attacker with model upload privileges to overwrite another user's in-progress model upload by racing concurrent requests to the same model name, causing the resulting model lookup entry to reference attacker-controlled content. The root cause is the toolkit's failure to bind uploaded file content to the specific request that creates the corresponding model lookup entry, enabling a TOCTOU-style substitution. No public exploit code or CISA KEV listing has been identified; the vendor (Splunk) has released a patch in version 6.0.0.

Hard-coded and predictable credentials in Splunk AI Toolkit versions below 6.0.0 expose connected container services to unauthorized access by any low-privileged Splunk user. The toolkit generates or stores credentials for its container integrations using predictable or fixed default values, which are retrievable through the AI Toolkit Connections tab without requiring elevated Splunk roles. No public exploit has been identified at time of analysis, and no CISA KEV listing exists, but a vendor patch (6.0.0) is available per advisory SVD-2026-0808, reported by Cisco.

Privilege escalation in Splunk AI Toolkit before 6.0.0 allows any authenticated low-privileged user to operate with system-level permissions by exploiting a session key substitution flaw in the Agent Run History handler. The handler unconditionally replaces the caller's session key with a system authentication token before executing searches, completely bypassing Splunk's role-based access controls that gate elevated operations behind 'admin' or 'power' roles. This grants unauthorized read access to all indexed data, cross-user search job enumeration and deletion, and write-level system integrity impact - no public exploit has been identified at time of analysis, but the low exploitation complexity and clear mechanism description make this a high-priority patching target for Splunk enterprise deployments.

Unauthenticated exposure of the OpenAPI specification in Cisco Talos Intelligence for Enterprise Security Cloud (versions below 1.0.3) allows any network-accessible user to retrieve the add-on's full REST API documentation via Splunk Web static file paths. The disclosed specification reveals API endpoint structure and the authentication model, enabling reconnaissance that could facilitate targeted follow-on attacks. No active exploitation or public exploit code has been identified at time of analysis.

Server-Side Request Forgery (SSRF) in Cisco Talos Intelligence for Enterprise Security Cloud (versions below 1.0.3) allows an authenticated Splunk user holding the get_talos_enrichment capability to redirect the instance's outbound authenticated management requests to an attacker-controlled server, exposing Splunk management tokens. Successful exploitation grants the attacker full control over the Splunk instance, compromising the confidentiality, integrity, and availability of all data and configurations within it. No public exploit code or CISA KEV listing has been identified at time of analysis, but the patch is available and the CVSS score of 8.8 reflects the severity of token theft as a post-exploitation path.

Privilege escalation in Splunk Enterprise Security below 8.6.1 enables authenticated users holding the ess_analyst role to modify UEBA search macros that are subsequently executed by scheduled searches running under administrator permissions. The flaw stems from misconfigured UEBA app metadata that incorrectly grants analyst-tier write access to macros intended to be restricted to administrators, resulting in unauthorized access to all Splunk-indexed data and potential system integrity violations. No public exploit or CISA KEV listing exists at time of analysis, though the low barrier - any ess_analyst account - makes insider threat and compromised analyst credential scenarios credible attack paths.

SPL injection in Splunk Enterprise Security versions below 8.6.1 allows low-privileged authenticated users holding the mc_investigation_read capability to inject Search Processing Language through Analyst Queue search filter field names, gaining access to data and system integrity controls available to scheduled search contexts beyond their authorized scope. The root cause is absent validation of filter field names before inclusion in SPL queries - analogous to SQL injection but within Splunk's proprietary query language. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the CVSS 8.1 High score reflects meaningful confidentiality and integrity exposure for any account holding the relevant capability.

Cleartext exposure of Zoom meeting passwords in the Splunk SOAR interface affects all deployments running the Zoom app for Splunk SOAR below version 3.2.2. Any authenticated SOAR user holding a role with permission to run actions can invoke the create meeting, update meeting, or update user settings actions and observe meeting passwords and personal meeting ID (PMI) passwords in plaintext within the SOAR UI. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Cleartext credential exposure in Venafi app for Splunk SOAR versions below 2.1.4 allows any authenticated user with action-run permissions to read keystore and private-key passwords directly from the Splunk SOAR user interface. The root cause is that the app's `keystore_password` and `password` parameters in the 'get certificate' action are not flagged as password-type fields, bypassing the SOAR platform's native masking mechanism. No public exploit code identified at time of analysis, and there is no CISA KEV listing; however, the exposed credentials could enable downstream PKI compromise if observed by a malicious insider.

Cleartext exposure of archive passwords in Splunk Attack Analyzer Connector for Splunk SOAR (versions below 2.2.1) allows authenticated users with action-running permissions to view sensitive archive_password values unmasked in the SOAR user interface. The connector's detonate file and detonate url actions fail to mark the archive_password parameter as a password type, causing the SOAR framework to render it in plaintext during and after action execution. No active exploitation has been identified - the CVE carries no CISA KEV listing and no known public exploit code - but insider or compromised-account exposure is straightforward for any SOAR user with the relevant role.

Information disclosure in the RSA SecurID Authentication Manager app for Splunk SOAR (versions below 1.0.5) exposes RSA token serial numbers in cleartext to any authenticated user with action-run permissions. The app's 'enable token' and 'revoke token' actions fail to mark the token_serial parameter as a password field, causing it to render unmasked in the Splunk SOAR user interface. No public exploit has been identified at time of analysis, and exploitation is constrained by the requirement for an existing Splunk SOAR account with action-execution privileges.

Cleartext exposure of archive passwords in Splunk SOAR's Phantom app (versions below 3.8.5) allows authenticated users with action-running permissions to read sensitive credentials directly from the platform's user interface. The deflate item action fails to mark its password parameter as a sensitive field, causing the archive password to be rendered in plaintext in the SOAR UI to any user who invokes the action. Splunk has released a patch in version 3.8.5 per advisory SVD-2026-0806; no public exploit code or CISA KEV listing has been identified at time of analysis.

Cleartext exposure of temporary Active Directory passwords in the MS Graph for Active Directory app for Splunk SOAR (versions below 1.5.2) allows authenticated users with action-run permissions to capture credentials generated during password reset operations, as the temp_password parameter is rendered in plaintext in the SOAR interface rather than being masked. The flaw stems from the app failing to declare the affected parameter as a password type, causing the Splunk SOAR UI to treat it as generic text output. No active exploitation has been confirmed and no public POC is reported; risk is bounded by the requirement for an authenticated internal SOAR account with specific action-run role permissions.

Cleartext exposure of document passwords in the CrowdStrike OAuth API app for Splunk SOAR (versions below 5.1.3) allows any authenticated user with action-running permissions to read sensitive document_password values directly from the Splunk SOAR user interface. The root cause is the app's failure to mark the document_password parameter as a password type in both the detonate file and detonate url actions, meaning the platform's built-in masking mechanism is never invoked. Vendor patch version 5.1.3 has been released and confirmed via Splunk advisory SVD-2026-0806; no public exploit code or active exploitation has been identified at time of analysis.

Information disclosure in the Cisco Webex App for Splunk SOAR (versions below 2.2.1) exposes Webex meeting passwords in cleartext within the SOAR platform interface. Authenticated users holding roles with action-execution permissions who invoke the 'schedule meeting' action can read the plaintext meeting password directly from the UI, because the app's action manifest fails to designate the password parameter as a masked field. No active exploitation has been identified (not in CISA KEV) and no public exploit code is known; real-world impact is bounded by the requirement for existing SOAR action permissions.

Cleartext exposure of a sensitive sample password in the Cisco Secure Malware Analytics App for Splunk SOAR (versions below 2.4.5) allows authenticated users with action-run permissions to read the sample_password parameter value directly from the Splunk SOAR user interface. The root cause is the app's failure to mark the sample_password field as a password type in the detonate file action, meaning the platform never applies its standard masking behavior to that parameter. No public exploit code or active exploitation has been identified; vendor patch is available at version 2.4.5.

Cleartext exposure of temporary passwords in the Azure AD Graph app for Splunk SOAR (versions below 2.5.3) allows authenticated action-runners to read Azure AD reset credentials directly from the SOAR interface. The app's reset password action fails to classify the temp_password parameter as a sensitive field, so Splunk SOAR renders it unmasked in the UI rather than applying its standard password-masking behavior. Vendor patch 2.5.3 is available per Splunk advisory SVD-2026-0806; no public exploit code and no CISA KEV listing identified at time of analysis.

Credential exposure in the AWS IAM App for Splunk SOAR (all versions below 2.1.9) enables any authenticated user holding a role with action-execution permission to view AWS credentials in cleartext directly within the Splunk SOAR user interface. The root cause is the app's failure to designate the credentials action parameter as a password type field (CWE-312), causing the SOAR platform to render it unmasked rather than redacted. No active exploitation (CISA KEV) or public exploit code has been identified; however, because the exposed material consists of AWS access credentials rather than generic application data, the downstream business risk - potential cloud account compromise - substantially exceeds what the CVSS 4.3 Medium score conveys.

Credential exposure in the AD LDAP app for Splunk SOAR (versions below 2.3.8) allows any authenticated user holding an action-execution role to trigger a full connector process environment dump to a persistent plaintext debug log file, disclosing sensitive credentials such as LDAP bind secrets or service account tokens. The CVSS scope-changed vector (S:C) reflects that the exposed credentials extend impact beyond the SOAR platform itself to the underlying Active Directory environment. No public exploit code exists and this vulnerability is not listed in CISA KEV at time of analysis; however, patch version 2.3.8 is available and should be applied promptly given the potential for AD credential theft.

Sensitive Active Directory response data exposure in the AD LDAP App for Splunk SOAR (versions below 2.3.8) allows authenticated users holding action-execution permissions to cause AD directory data to be written to a persistent debug log file. The flaw is rooted in CWE-532 (insertion of sensitive information into log files) and is reachable over the network by any low-privileged SOAR user with the appropriate role. No public exploit code or active exploitation has been identified; Splunk has released a patch at version 2.3.8.

LDAP injection in the AD LDAP app for Splunk SOAR (versions below 2.3.8) allows authenticated low-privileged users to manipulate Active Directory queries, exposing account enumeration, sensitive attribute disclosure, and unintended modification of AD objects. Exploitation requires only a role with 'run actions' permission within Splunk SOAR - no elevated SOAR admin rights needed. Splunk has released a patch (version 2.3.8); no public exploit code or CISA KEV listing has been identified at time of analysis.

The Nmap Scanner connector for Splunk SOAR (versions prior to 3.0.15) permits privileged users to bypass Safe Mode playbook restrictions by exploiting a manifest miscategorization that marks the scan network action as read-only despite its accepting NSE script parameters capable of write operations and command execution on target systems. Users holding roles that allow editing, creating, or running playbooks can leverage this gap to run arbitrary Nmap Scripting Engine scripts against networked targets through SOAR automation - a meaningful privilege escalation given SOAR platforms typically have broad network reach. No public exploit has been identified at time of analysis, and a vendor patch is available via Splunk advisory SVD-2026-0806.

FireAMP connector versions below 2.1.15 for Splunk SOAR allow authenticated playbook editors to bypass Safe Mode restrictions by invoking the add listitem action, which the connector manifest incorrectly classifies as read-only despite it performing write operations on file lists. Exploitation requires a high-privilege role (playbook edit/create/run), limiting the attack surface to trusted internal SOAR users. No public exploit code exists and this vulnerability has not been identified in CISA KEV, consistent with its low CVSS score of 2.7.

Splunk SOAR versions below 8.6.0 expose tenant names and identifiers to authenticated users whose roles restrict them to a subset of tenants, due to a REST API authorization enforcement gap. In multi-tenant deployments, a low-privileged user can enumerate out-of-scope tenant metadata - names and identifiers - without triggering any access control check. No active exploitation or public exploit code has been identified; the CVSS score of 4.3 (Medium) reflects limited confidentiality impact with no integrity or availability consequence.

Path traversal in Splunk SOAR below 8.6.0 enables users holding the OnPrem Broker role to write files to arbitrary locations outside the designated Automation Broker log directory. The flaw stems from the log upload endpoint accepting crafted filenames without adequate sanitization, allowing directory traversal sequences to escape the intended write boundary. No public exploit has been identified and no active exploitation is confirmed; the CVSS score of 2.7 (Low) accurately reflects the high privilege prerequisite and the limited, integrity-only impact.

Splunk SOAR versions below 8.6.0 expose a missing authorization flaw in the Playbook History feature that allows authenticated users holding the `playbooks:view` permission to read metadata about playbook repositories they are not explicitly authorized to access. The Playbook History endpoint omits repository-level permission checks before returning revision metadata, enabling unauthorized information disclosure within role-segregated SOAR deployments. No active exploitation has been confirmed - there is no CISA KEV listing and no public exploit code has been identified - and the CVSS base score of 2.7 reflects the high-privilege prerequisite and narrow confidentiality-only impact scope.

Stored XSS in Splunk SOAR below 8.6.0 enables an authenticated 'Incident Commander' role user to inject JavaScript into a note, which executes in the browser of any user who subsequently opens it. The flaw stems from unsanitized HTML rendering triggered by a note format change, meaning content stored safely in one format becomes executable in another. No public exploit code exists and the vulnerability is absent from CISA KEV; however, successful exploitation could compromise victim session integrity within the SOAR platform.

Session token disclosure in Splunk SOAR versions below 8.6.0 enables any authenticated account holder to recover session tokens belonging to other users by manipulating REST API filters on the playbook run endpoint. Because Splunk SOAR fails to block filter predicates from matching against values that are otherwise suppressed in API responses, an attacker with a low-privilege account can systematically extract credentials granting full access to any targeted user's data within the platform. Splunk has released version 8.6.0 as a fix; no public exploit has been identified at time of analysis, but the low attack complexity elevates urgency for organizations where multiple users share a SOAR instance.

SQL injection in Splunk SOAR below version 8.6.0 enables users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR database by embedding injection payloads in custom list names referenced within playbooks, granting full create, read, update, and delete access to all data the database contains. The root cause is unsanitized string concatenation: Splunk SOAR builds the custom list lookup query by inserting the user-supplied list name directly rather than using parameterized (bound) values, a textbook CWE-74 injection pattern. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV; vendor-released patch version 8.6.0 is available.

SQL injection in Splunk SOAR below version 8.6.0 enables authenticated users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR backend database by supplying crafted values through custom function results. The root cause (CWE-89) is Splunk SOAR concatenating the user-supplied name directly into the database lookup query rather than using parameterized, bound SQL values. Successful exploitation allows full read access to all data stored in the SOAR database - including playbook configurations, incident records, and integration credentials - and can affect database integrity; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.

SQL injection in Splunk SOAR's playbook automation data APIs grants any user holding the 'Automation Engineer' role unrestricted read, write, and delete access to the entire SOAR database in versions below 8.6.0. The vulnerability stems from user-supplied input being incorporated into database queries without proper sanitization (CWE-943), enabling arbitrary SQL execution against the SOAR backend. No public exploit code or active exploitation via CISA KEV has been identified at time of analysis; Splunk has released a patch in version 8.6.0.

Improper TLS certificate validation in Splunk SOAR's CyberArk REST client exposes all credential vault traffic to interception and tampering by a network-positioned attacker. Versions below 8.6.0 are affected when a CyberArk REST credential manager integration is configured; the client accepts any server certificate without verification, making TLS sessions transparent to a man-in-the-middle. No public exploit code has been identified at time of analysis, and the vulnerability is absent from the CISA KEV catalog, but the high confidentiality and integrity impact on privileged credential data warrants priority remediation in environments relying on CyberArk for SOAR playbook secrets.

Splunk SOAR versions below 8.6.0 contain a Server-Side Request Forgery flaw in the connectivity check REST API endpoint (/rest/support/connectivity/.../check_connectivity) that allows an authenticated Administrator-role user to direct the SOAR platform to initiate outbound network connections to arbitrary destinations. This enables internal network enumeration - discovering reachable hosts and open ports using the SOAR instance's network position, which is typically privileged within enterprise SOC environments. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS score of 2.7 (Low) accurately reflects the high privilege prerequisite, though the risk is elevated in environments where the SOAR platform has broad internal network access.

Unauthorized information disclosure in Splunk SOAR (On-premises) below version 8.6.0 exposes system health and cluster telemetry to any authenticated user, including those with no assigned role, via the /rest/health REST endpoint. The root cause is a missing authorization check (CWE-862) that validates session authentication but omits role-membership verification before returning restricted operational data. No active exploitation has been confirmed in CISA KEV, and no public exploit code has been identified; vendor patch is available in version 8.6.0 per advisory SVD-2026-0804.

Path traversal in Splunk SOAR's Universal Forwarder credentials-package extraction allows an authenticated Administrator to write files to arbitrary locations on the underlying host filesystem. Affecting all On-premises versions below 8.6.0, the flaw stems from the archive extraction workflow accepting member paths containing directory traversal sequences without first verifying each member's resolved destination. No public exploit or CISA KEV listing exists at time of analysis; however, the Integrity:High and Availability:High CVSS impact ratings indicate that a malicious archive could overwrite system-level files, enabling persistence or privilege escalation beyond SOAR's own permission boundary.

Path traversal during app installation in Splunk SOAR On-premises below version 8.6.0 allows an authenticated user holding app-install privileges to write files outside the intended temporary extraction directory. The archive extraction routine fails to validate that file paths within an uploaded archive remain within the designated staging directory, enabling a classic Zip Slip attack that can overwrite arbitrary files on the host. No public exploit has been identified at time of analysis, and exploitation is constrained by the high-privilege prerequisite (PR:H); a vendor-released patch is available in version 8.6.0.

Arbitrary code execution in Splunk SOAR (On-premises) versions below 8.6.0 is reachable by any authenticated user regardless of role assignment, via a crafted file path submitted to the REST API. The REST API endpoint neither enforces role-based access control nor restricts the user-supplied path to the intended temporary directory, enabling path traversal (CWE-22) that culminates in code execution on the SOAR server. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; however, the low privilege barrier - any valid account, zero roles required - meaningfully elevates real-world risk in environments where SOAR accounts are broadly provisioned.

Remote code execution in Splunk SOAR versions below 8.6.0 allows unauthenticated remote attackers to execute arbitrary code on the SOAR host by exploiting the Automation Broker's blind trust of client-supplied IP address headers. The Automation Broker accepts a forged source-IP header as proof that a notification endpoint request originates from the local system (CWE-290), bypassing all authentication. Successful exploitation grants full confidentiality, integrity, and availability impact on the SOAR host; no public exploit is identified at time of analysis, but the vendor has released a patch in version 8.6.0.

Unauthenticated remote disclosure of Edge Processor pipeline configurations in Splunk Enterprise 10.4.x exposes potentially sensitive data-processing logic to any network-accessible attacker. The REST API endpoint serving Edge Processor configuration lacks authentication controls (CWE-306), meaning any unauthenticated actor can retrieve pipeline details when the Edge Processor feature is enabled. No public exploit code has been identified at time of analysis, and the flaw is restricted to the 10.4.x branch - prior versions are unaffected.

Search Head Clustering bundle replication in Splunk Enterprise fails to validate bundle filenames or neutralize NUL bytes before constructing file system paths on non-captain cluster members, allowing any authenticated low-privileged user to delete or temporarily overwrite files accessible to the Splunk service account via a crafted REST API request. Affected are Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 running in SHC deployments - standalone instances are not in scope. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV; however, vendor patch is available via advisory SVD-2026-0801 and the low privilege barrier makes this a credible insider or stolen-credential threat in SOC environments.

Arbitrary file deletion on Splunk cluster managers is possible for any authenticated, low-privileged user - no admin or power role required - by submitting a crafted knowledge bundle delta containing path traversal sequences. Affected versions span four active release branches: 9.4.x before 9.4.14, 10.0.x before 10.0.9, 10.2.x before 10.2.6, and 10.4.x before 10.4.2. An attacker exploiting this flaw can delete files accessible to the Splunk process outside the intended staging directory, degrading system integrity or triggering service disruption on the cluster manager node. No public exploit code or CISA KEV listing has been identified at time of analysis.

Privilege escalation in Splunk Enterprise allows any authenticated low-privileged user to create or modify scripted lookups through improperly guarded generic transforms configuration endpoints, gaining code execution under the Splunk service account's operating system permissions. Affected versions span four release branches: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. An attacker holding any valid Splunk account - without requiring the 'admin' or 'power' roles - can abuse this to access all Splunk-indexed data and compromise system integrity and availability. No public exploit or CISA KEV listing has been identified at time of analysis.

Splunk Secure Gateway's failure to validate decoded report notification identifiers enables any authenticated low-privileged user to hijack system-level REST API sessions in Splunk Enterprise, achieving full configuration control and credential theft without requiring admin or power role. Affected versions span multiple Splunk Enterprise branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) and Splunk Secure Gateway branches (3.8.x, 3.9.x, 3.10.x). No public exploit code or CISA KEV listing has been identified at time of analysis, but the low-complexity, low-privilege attack path and high-impact outcome (C:H/I:H/A:H) make this a realistic internal threat in any multi-tenant or shared Splunk deployment.

Privilege escalation in Splunk Enterprise allows any user holding the schedule_search capability to execute arbitrary SPL commands with system-level privileges on the search head by configuring PDF attachments in the email alert action workflow. The flaw exists because the search scheduler substitutes a system-level authentication context for the alert owner's context during PDF rendering, effectively granting the authenticated user full system access. Affected are all Splunk Enterprise installations across the 9.4, 10.0, 10.2, and 10.4 release branches below the patched versions; no public exploit or CISA KEV listing is identified at time of analysis.

SPL injection in Splunk Enterprise below versions 10.2.6, 10.0.9, and 9.4.14 enables an unauthenticated attacker to execute arbitrary Search Processing Language commands under the privileges of any authenticated Splunk user by luring that user into clicking a specially crafted Splunk Web URL. The root cause is unsanitized substitution of URL-supplied form token values directly into SPL searches, effectively turning the victim's browser session into a proxy for the attacker's queries. No public exploit code or CISA KEV listing has been identified at time of analysis, but the high confidentiality impact (C:H) makes this a meaningful data-exfiltration vector in targeted phishing scenarios against Splunk-heavy SOC or analytics environments.

Search Head Cluster member control endpoints in Splunk Enterprise fail to enforce HTTP method-based authorization, allowing a user holding the high-privilege `list_search_head_clustering` capability to send read-typed HTTP requests that alter cluster state and cause a denial of service. Four release branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with fixed versions available from Splunk (SVD-2026-0801). No public exploit code or CISA KEV active-exploitation listing has been identified at time of analysis; exploitation is constrained to authenticated insiders or post-compromise attackers holding a high-privilege Splunk role.

Server-Side Request Forgery in Splunk Enterprise and Splunk Secure Gateway allows low-privileged authenticated users to manipulate internal Splunk services via crafted report notification paths. Affected versions span Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70. An attacker holding any valid Splunk account - excluding admin and power roles - can leverage the unvalidated path handling in Secure Gateway to issue system-authenticated internal requests, potentially disrupting Search Head Cluster state or causing denial of service. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog at time of analysis.

Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to embed malicious JavaScript within dashboard sparkline format options, which then executes in the browser of any user who views that dashboard. If the victim holds the 'admin' Splunk role, the attacker effectively gains access to all data accessible through Splunk Web and can perform actions at admin-level permissions. Exploitation requires social engineering - the victim must be tricked into navigating to the malicious dashboard - and no public exploit code has been identified at time of analysis. Affected versions span four active release branches below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.

Remote code execution in Splunk Enterprise 10.4.x allows a high-privilege user with search head cluster (SHC) management rights to write files to arbitrary locations accessible by the Splunk service account via the SHC member bundle REST API. The API fails to enforce authorization boundaries and does not validate bundle paths before accepting content, enabling path-traversal-style writes that can deliver and trigger malicious payloads. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the RCE primitive makes this a meaningful risk in environments running Splunk 10.4 or 10.4.1 where high-privilege insider or compromised-account scenarios are plausible.

Path traversal in Splunk Enterprise allows low-privileged authenticated users to write dispatch metadata to arbitrary locations on the host filesystem by supplying a crafted search identifier to a REST API endpoint. Affected branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering all currently maintained Splunk Enterprise release lines. No public exploit has been identified at time of analysis and the vulnerability is absent from CISA KEV, but the low complexity, network accessibility, and high integrity impact create meaningful risk on unpatched instances, particularly given the potential for filesystem write primitives to be chained into privilege escalation.

SQL injection in Splunk Enterprise's Data Orchestration jobs endpoint allows any authenticated low-privilege user - explicitly excluding the need for 'admin' or 'power' roles - to execute arbitrary SQL against the underlying Data Orchestration database, exposing all job records across all users and stored connection credentials. Affected version branches are 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Reported by Cisco; no KEV listing or public exploit code identified at time of analysis, though the credential exposure component significantly elevates real-world impact beyond the moderate 6.5 CVSS score suggests.

Splunk Enterprise contains a stored SPL injection flaw in the Table Editor that allows a lower-privileged 'power' role user to plant risky Search Processing Language commands inside a shared dataset, which then execute silently under an 'admin' user's elevated permissions when that admin opens the dataset's Initial Data step. Affected versions span four release lines: below 10.4.2, 10.2.6, 10.0.9, and 9.4.14. A successful attack exposes all data accessible to the admin and allows modification of Splunk lookup files. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability as actively exploited.

Splunk Enterprise's Table Editor dataset feature permits a 'power' role user to inject attacker-controlled Search Processing Language (SPL) into a shared dataset, which silently executes with admin-level permissions when an administrator opens the dataset. Affected deployments span four version branches: 9.4 prior to 9.4.14, 10.0 prior to 10.0.9, 10.2 prior to 10.2.6, and 10.4 prior to 10.4.2. Because the Table Editor omits SPL safeguards for risky commands during the initial data preparation phase (CWE-863), a successfully phished admin can unwittingly expose all search-head-accessible data and allow limited data modification. No public exploit is identified at time of analysis, and the vulnerability does not appear in CISA's KEV catalog.

Unauthenticated token-signing key reload in Splunk Enterprise 10.4.x (below 10.4.2) exposes a REST API endpoint that lacks the required `change_authentication` capability check, permitting any network-reachable caller to force a key reload cycle without credentials. The flaw is classified under CWE-862 (Missing Authorization) and was reported by Cisco; a vendor patch is available at 10.4.2. No active exploitation has been confirmed and no public exploit code has been identified at time of analysis, though the low-complexity, unauthenticated network vector makes opportunistic probing straightforward once the endpoint is known.

SPL command injection through the geostats command in Splunk Enterprise allows an authenticated low-privileged attacker to execute arbitrary Search Processing Language commands under the security context of a second, higher-privileged victim user. Affected release branches include 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Exploitation requires phishing an authenticated target into initiating the attacker-controlled search in Splunk Web; no public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.

Authentication bypass in Splunk Enterprise across multiple supported version branches allows an attacker who has obtained a trusted distributed search private key to forge administrative session tokens entirely over the network. Affected versions span 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. Once a forged token is accepted, the attacker gains full confidentiality, integrity, and availability impact equivalent to an administrator - including access to all indexed data and the ability to disrupt search services. No public exploit or CISA KEV listing exists at time of analysis; this was reported by Cisco, suggesting coordinated disclosure from security research.

Path traversal in Splunk Enterprise exposes JavaScript files outside the Splunk Web static directory to unauthenticated remote attackers across four active release branches. Splunk Web fails to enforce boundaries on static file requests, allowing directory traversal reads without any credentials. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog, but the trivially low attack complexity (AC:L, PR:N, UI:N) means exploitation requires no special tooling.

Insufficient authorization in Splunk Enterprise's SPL2 module management REST API allows any authenticated low-privileged user - one without the 'admin' or 'power' role - to delete all SPL2 modules across every app and user on the instance. Affected versions are 10.2.x through 10.2.5 and 10.4.x through 10.4.1; versions below 10.2 are unaffected as SPL2 module management did not exist there. The resulting impact is high integrity loss (permanent deletion of exported datasets and functions) and partial service disruption, with no patch-confirmed active exploitation at time of analysis.

Authenticated low-privilege code injection in Splunk Enterprise allows OS command execution on the host system as the Splunk process account. Affected versions span four active release lines (9.4.x, 10.0.x, 10.2.x, 10.4.x), and the root cause is a missing capability check: Splunk Web accepts Splunk Web Manager XML configuration writes without enforcing the edit_manager_xml permission, meaning any authenticated user can plant attacker-controlled content that executes when the Manager page is rendered. No active exploitation is confirmed in CISA KEV, and no public exploit code has been identified at time of analysis, but the CVSS score of 8.8 (High) and straightforward exploitation path make this a high-priority patching target for Splunk deployments.

Dashboard Studio workflow actions in Splunk Enterprise can be weaponized by a 'power'-role user to store attacker-controlled SPL that executes under a victim's permission context when triggered via Event Actions. Affected versions span all major branches: 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2. No public exploit code or CISA KEV listing exists at time of analysis, but successful exploitation enables unauthorized read and write access to data within the victim's Splunk permission scope.

Stored cross-site scripting in Splunk Enterprise's Dashboard Studio allows a user holding the 'power' role to persist a crafted workflow action URL that, when triggered by a separate authenticated victim, executes attacker-controlled JavaScript in the victim's browser session. All four actively maintained branches are affected: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. No public exploit has been identified at time of analysis, and exploitation is constrained by a required internal 'power' role and mandatory victim social engineering, meaningfully limiting the realistic attacker population despite the high impact ratings.

SPL injection via Analytics Workspace in Splunk Enterprise allows an unauthenticated attacker to execute arbitrary Search Processing Language queries under the permissions of a phished authenticated user. Affected across four release trains - 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2 - the flaw stems from insufficient input validation when Analytics Workspace constructs searches from URL-embedded data. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, though exploitation impact scales directly with the victim user's Splunk role and data access.

SPL injection in Splunk Enterprise exposes all indexed data and compromises search integrity for any low-privileged authenticated user. Specifically, users without the 'admin' or 'power' role can inject Search Processing Language commands into saved-search dispatch requests by supplying malicious time values that Splunk Enterprise fails to validate. Patch versions have been released across all supported branches; no public exploit code or CISA KEV listing has been identified at time of analysis.

Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language commands under the permissions of a phished authenticated victim. Affected versions span four active release trains: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. No public exploit or CISA KEV listing exists at time of analysis, though successful exploitation grants full read and write access to all data and actions permitted by the victim's Splunk role.

Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language queries under the permissions of a targeted Splunk administrator. The attacker must phish an admin-role user into opening a specially crafted link (CVSS UI:R/AC:H), making opportunistic mass exploitation unlikely, but a successful attack can expose all data indexed and accessible to that admin or corrupt lookup tables. Vendor-released patches are available for all affected branches; no public exploit code and no CISA KEV listing have been identified at time of analysis.

SPL injection via the dashboard PDF export feature in Splunk Enterprise allows a 'power'-role attacker to store malicious Search Processing Language that executes under the permissions of a separate, higher-privileged authenticated user when that user exports the dashboard as a PDF. Affected versions span four maintained release branches: 10.4 below 10.4.1, 10.2 below 10.2.6, 10.0 below 10.0.9, and 9.4 below 9.4.14. No public exploit code has been identified and the vulnerability does not appear in the CISA KEV catalog; successful exploitation requires chaining a held 'power' role with a successful phishing step against the victim user.

SPL injection via Splunk Secure Gateway's unsanitized dashboard URL parameters allows an unauthenticated attacker to execute arbitrary Search Processing Language commands under the full permissions of a phished Splunk administrator. The Splunk Secure Gateway component fails to neutralize caller-supplied values before embedding them in dashboard searches, meaning a crafted URL opened by an 'admin' or 'sc_admin' user causes injected SPL to run with that user's data access - potentially exposing all indexed data visible to the administrator and corrupting search results or lookup tables. No public exploit code has been identified at time of analysis and this CVE does not appear in the CISA KEV catalog, though the phishing vector and high data-access impact make this a meaningful risk for organizations with sensitive Splunk deployments.

Stored cross-site scripting in Splunk Enterprise's dashboard table renderer allows a low-privileged user - without admin or power role - to inject JavaScript payloads into sparkline table cell tooltips, which execute in the browser of any user who opens the malicious dashboard and hovers over an affected cell. The vulnerability spans four active Splunk Enterprise release lines (9.4, 10.0, 10.2, and 10.4), confirmed by EUVD-2026-63133 and Splunk advisory SVD-2026-0801. No public exploit code or active exploitation has been identified at time of analysis, but the broad version coverage and low attacker privilege bar make patching a clear operational priority.

Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to persist a malicious ui-tour knowledge object that executes arbitrary JavaScript in the browser of any authenticated user who visits an affected Splunk Web page. Affected are all Splunk Enterprise deployments running versions below 10.4.2, 10.2.6, 10.0.9, or 9.4.14, a broad multi-branch footprint reported via Cisco and confirmed by Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 7.3 rating and high confidentiality and integrity impact scores reflect meaningful lateral risk within an enterprise's Splunk deployment.

Stored cross-site scripting in Splunk Enterprise's guided tour feature enables a 'power'-role user to inject and execute arbitrary JavaScript in any other authenticated user's browser when that user opens a crafted tour link. Affected across four active release branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) with fixed versions now available per Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS score of 5.7 reflects the dual prerequisite of attacker role access and required victim interaction.

SPL injection in Splunk Enterprise's Job Details dashboard enables a low-privileged authenticated attacker to bypass Search Processing Language risky-command safeguards by embedding a malicious search identifier in a crafted dashboard URL and phishing an authenticated victim into opening it. The injected SPL executes under the victim's permissions, potentially exposing all data accessible to that user and compromising search integrity within those bounds. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available across all four affected release trains per advisory SVD-2026-0801.

Dashboard Studio in Splunk Enterprise (below versions 9.4.14, 10.0.9, 10.2.6, and 10.4.2) allows a low-privileged 'user'-role account to inject attacker-controlled SPL queries that execute within the authenticated session of a different, potentially higher-privileged victim user. The root cause is Dashboard Studio's failure to consistently enforce app-visibility authorization boundaries before search query options reach the search dispatch layer - a CWE-862 Missing Authorization defect. No public exploit code or active exploitation has been confirmed; a vendor patch is available across all affected branches.

Unauthenticated SPL injection in Splunk Enterprise's nearby-event search feature allows remote attackers to execute arbitrary Search Processing Language queries without authorization across versions 9.4.x, 10.0.x, 10.2.x, and 10.4.x. The root cause is a two-pronged failure: Splunk Web does not consistently escape caller-supplied values when constructing SPL for nearby-event searches, and the embedded report access endpoint accepts those crafted requests without performing the expected authorization check. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the unauthenticated network vector and wide enterprise deployment of Splunk make this a priority patch.

Cross-site request forgery combined with SPL injection in Splunk Enterprise's Event Type Builder allows an unauthenticated attacker to cause an authenticated user to execute arbitrary Search Processing Language queries under the victim's session context. Affected release branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering multiple concurrent support tracks. Successful exploitation can expose all data accessible to the victim's Splunk session including stored credentials, though the attacker must first phish an authenticated user into initiating the malicious browser request. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Remote code execution in Splunk Enterprise allows any low-privileged authenticated user to execute arbitrary code by exploiting a missing authorization check in the Federated Search dispatch flow. The vulnerability stems from the platform accepting caller-controlled bundle selection without verifying the fsh_manage capability, meaning any user with basic login access can escalate to full RCE. All four active version branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) are affected below their respective patch thresholds; no public exploit or CISA KEV listing has been identified at time of analysis.

Stored cross-site scripting in Splunk Enterprise exposes victim user data when a user holding the schedule_search capability injects a malicious script into an alert trigger condition field and induces another user to open the crafted link. The script executes in the victim's browser context and can access all Splunk data available to that user, making this particularly dangerous in environments where analysts or admins have broad search access over sensitive logs and security telemetry. Patch is available from Splunk across four version branches; no public exploit or CISA KEV listing has been identified at time of analysis.

Path traversal in Splunk Enterprise's lookup configuration endpoint allows any authenticated low-privileged user - without admin or power roles - to move arbitrary files readable by the Splunk service account into a user-controlled lookup table on the search head. Affected versions span four active release trains: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. With a CVSS score of 8.8 and no special configuration required beyond a standard Splunk account, successful exploitation yields full confidentiality, integrity, and availability impact; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.