Splunk Cloud Platform

Credential hash exposure in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users - those without the 'admin' or 'power' roles - to retrieve stored credential hashes by issuing the `|rest` SPL command against the `/servicesNS/-/-/storage/passwords` endpoint, which incorrectly returns the `encr_password` field. Affected are Splunk Enterprise branches below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and multiple Splunk Cloud Platform versions. No public exploit has been identified at time of analysis and this CVE is not in CISA KEV, but the real-world impact is significant wherever Splunk stores credentials for external services such as databases, APIs, or cloud accounts.

Cross-Site Request Forgery combined with SPL injection in Splunk Enterprise (below 10.4.1, 10.2.5, 10.0.8, 9.4.13) and Splunk Cloud Platform lets an attacker trick a logged-in user holding the list_deployment_server capability into unknowingly executing attacker-controlled Search Processing Language searches as the privileged splunk-system-user, exposing stored credentials and indexed data. The flaw stems from Deployment Server endpoints in Splunk Web accepting unvalidated GET requests without CSRF token checks and failing to neutralize caller input before it reaches an SPL search. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.

Arbitrary file write in Splunk Enterprise (versions below 10.4.1, 10.2.5, 10.0.8, 9.4.13, 9.3.14) and Splunk Cloud Platform lets a privileged user with the edit_local_apps and install_apps capabilities abuse the app-installation workflow to write files outside the target app directory into $SPLUNK_HOME/etc/ and its subdirectories. The flaw is a path traversal (CWE-22) that can be leveraged to overwrite Splunk configuration and system files, yielding high confidentiality, integrity, and availability impact. No public exploit identified at time of analysis and it is not listed in CISA KEV.

Stored cross-site scripting in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform (below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, 9.3.2411.132) allows a low-privileged authenticated user - without 'admin' or 'power' roles - to embed malicious JavaScript inside a classic dashboard HTML panel that executes in another user's browser session. Exploitation requires phishing the victim into initiating a specific browser request, and no public exploit was identified at time of analysis.

Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.4.2604.3 and 10.2.2510.14) allows remote attackers to create or truncate files on the host via an unauthenticated PostgreSQL sidecar service endpoint. The CVSS 9.8 vector (AV:N/AC:L/PR:N/UI:N) reflects trivial network exploitation, and no public exploit identified at time of analysis, though the missing-auth root cause and Splunk's high-value position in enterprise SOCs makes prompt patching warranted.

Server-side request forgery in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform lets a low-privileged authenticated user coerce the Dashboard Studio PDF export feature into issuing HTTP requests to arbitrary internal destinations. The flaw stems from a flawed prefix-match on trusted domains plus uncritical redirect-following by the PDF export service. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Classic dashboard style attribute injection in Splunk Enterprise and Splunk Cloud Platform enables a low-privileged authenticated user to craft panels that bypass the Trusted Domains List and exfiltrate sensitive data from a higher-privileged user's browser session. Affected branches span Splunk Enterprise below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and multiple Splunk Cloud Platform release trains. No public exploit has been identified at time of analysis, and SSVC rates current exploitation as none with partial technical impact, though the high confidentiality impact potential warrants prompt patching in environments where low-privileged users can share dashboards with administrators.

Improper access control on the saved search ownership reassignment endpoint in Splunk Enterprise and Splunk Cloud Platform allows a highly privileged authenticated user - one whose role contains the `edit_saved_search_owner` capability - to reassign saved search ownership to users outside their authorized scope. Affected versions span Splunk Enterprise below 10.2.4 and 10.0.7, and multiple Splunk Cloud Platform branches below their respective fixed builds. No public exploit has been identified at time of analysis, and the PR:H CVSS requirement confines risk primarily to insider threats or scenarios involving compromised privileged Splunk accounts.

Classic dashboard URL validation bypass in Splunk Enterprise and Splunk Cloud Platform enables low-privileged authenticated users to craft dashboards that silently exfiltrate sensitive data to attacker-controlled external servers. The flaw (CWE-20) resides in the external content dialog, which fails to enforce complete domain restrictions, allowing outbound requests to untrusted hosts when a victim interacts with the malicious dashboard. No public exploit exists and this vulnerability is not listed in CISA KEV, but the High confidentiality impact (C:H) in the CVSS vector reflects meaningful data exposure risk in environments where Splunk indexes security events, credentials, or sensitive operational logs.

Remote code execution in Splunk Enterprise, Splunk Cloud Platform, and the Splunk Secure Gateway app allows a low-privileged authenticated user (without 'admin' or 'power' roles) to execute arbitrary Python on the server by abusing unsafe jsonpickle deserialization of App Key Value Store (KV Store) data. CVSS is 8.8 (network, low complexity, low privileges) and the issue is currently rated as no public exploit identified at time of analysis. The flaw is reported by Cisco and disclosed via Splunk advisory SVD-2026-0601.

CSS injection in Splunk Enterprise and Splunk Cloud Platform classic dashboards enables credential and sensitive data exfiltration by low-privileged users targeting higher-privileged accounts. A low-privileged user (without 'admin' or 'power' roles) can craft a malicious classic dashboard containing injected CSS via inline style attributes; when a higher-privileged user views the dashboard, outbound HTTP requests are triggered to attacker-controlled external servers, bypassing the Trusted Domains restriction. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog, but the C:H confidentiality impact and cross-privilege exploitation path make this a meaningful insider or compromised-account threat in environments with mixed privilege levels.

Classic dashboard drill-down links in Splunk Enterprise and Splunk Cloud Platform can be weaponized by low-privileged authenticated users to silently redirect victims to attacker-controlled external sites, enabling data exfiltration. The flaw stems from an incomplete URL scheme validator that recognizes only 'http://' and 'https://' prefixes, allowing protocol-relative URLs like '//attacker.com' to bypass the external-navigation warning dialog entirely. No public exploit code exists and no active exploitation is confirmed (not in CISA KEV), but the attack requires only a low-privileged account and a single victim click, making it a realistic phishing vector in multi-tenant or large enterprise Splunk deployments.

Sensitive information disclosure in Splunk Enterprise (below 10.2.2 and 10.0.5) and Splunk Cloud Platform (multiple branches below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13) allows authenticated users with a role granting access to the `_internal` index to view session cookies and response bodies containing sensitive data logged by the platform. Cisco-reported and patched by Splunk in advisory SVD-2026-0503, the issue is a CWE-532 sensitive-data-in-logs flaw rather than a remote code execution bug, with no public exploit identified at time of analysis.

Denial of Service in Splunk Enterprise and Splunk Cloud Platform allows a low-privileged authenticated user to render the entire instance non-functional by exploiting missing input validation in the `coldToFrozen.sh` script bundled with the `splunk_archiver` app. The script accepts arbitrary file paths and renames them without restricting operations to safe directories, enabling renaming of critical Splunk system directories. No public exploit or CISA KEV listing has been identified at time of analysis, but the low privilege requirement (PR:L per CVSS) makes this actionable for any authenticated non-admin user in multi-tenant or enterprise deployments. A vendor patch is available via advisory SVD-2026-0504.

Improper access control in Splunk Enterprise

We need to parse the CVE data and synthesize into the required JSON fields. Let's go through each field. - product_name: 1-3 words. Affected products are Splunk Enterprise and Splunk Cloud Platform. The primary product could be "Splunk Enterprise" as the most common on-prem product, but description lists both. We can say "Splunk Enterprise" or "Splunk Cloud Platform". Since the vulnerability is in the apptemp directory handling and it's a low-privileged user with RCE, I'll pick "Splunk Enterprise" as the core product name. However, "Splunk" alone might be too generic, but allowed 1-3 words. So "Splunk Enterprise" is fine. - summary: 2-3 sentences plain-language, not copy of description. Must start with impact verb. Impact is RCE, so something like "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows...". Specific: low-privileged user (not admin/power) uploads malicious file to apptemp directory due to improper handling, leading to RCE. Affected versions: Enterprise below 10.2.1, 10.0.5, 9.4.10, 9.3.11; Cloud below various versions. Attacker can execute arbitrary code. EPSS low (0.13%), no KEV, no POC mentioned? Tags don't say POC. SSVC says exploitation none, automatable no, total impact. So not actively exploited. Summary: "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users without admin/power roles to execute arbitrary code by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory. Affects Enterprise versions before 9.3.11, 9.4.10, 10.0.5, 10.2.1 and Cloud Platform before respective fixed versions. No public exploit identified at time of analysis." - technical_context: underlying technology/protocol: Splunk apptemp directory is a temporary file storage used during app installation or updates. CWE-377 is Insecure Temporary File handling. The root cause is insufficient isolation: files in apptemp can be manipulated by low-privileged users to achieve RCE. CPEs indicate both Splunk Enterprise and Cloud Platform. Could explain that Splunk uses this directory for app staging, and improper handling of file permissions allows malicious upload to trigger code execution, possibly through app validation or loading mechanisms. Educational. - risk_assessment: CVSS 7.1, vector AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. So network attack, high complexity, low privileges required, user interaction required, scope unchanged, high impact on CIA. EPSS 0.13% (low probability of exploitation, 33rd percentile). Not in KEV. No POC evidence. SSVC: exploitation none, automatable no, technical impact total. So risk is moderate but not actively exploited. Complexity high and user interaction required reduce real-world risk. But total impact, so if exploited, serious. Compare: CVSS is high severity (7.1) but EPSS suggests low exploitation likelihood. Patches available. Real-world priority: apply patches as part of normal cadence, not emergency. Mention that despite low EPSS, the total impact makes it worth remediating. - affected_products: list products with version ranges. Splunk Enterprise: below 10.2.1, 10.0.5, 9.4.10, 9.3.11. Splunk Cloud Platform: below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, 9.3.2411.127. Reference to vendor advisory: https://advisory.splunk.com/advisories/SVD-2026-0403. No bullet points. - remediation: action: upgrade to fixed versions. Provide exact versions: Enterprise: 9.3.11, 9.4.10, 10.0.5, 10.2.1; Cloud: 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, 10.4.2603.0. Workaround maybe not mentioned. Possibly restrict file upload permissions or restrict access to apptemp directory. But no specific workaround in description. I'll say: "Upgrade Splunk Enterprise to version 9.3.11, 9.4.10, 10.0.5, or 10.2.1, and Splunk Cloud Platform to 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, or 10.4.2603.0. As a temporary mitigation if upgrading is not possible, restrict write access to the apptemp directory to trusted roles only, but this may impact app installation functionality. Consult advisory SVD-2026-0403." - exploit_scenario: realistic attack: low-privileged Splunk user (without admin/power) uploads a malicious file to the apptemp directory (which they can access) via a crafted request or through app upload functionality if allowed; the file is then processed by Splunk in a way that leads to code execution, potentially via loading a malicious app or configuration. Attack complexity high due to need to trigger processing. Example: "A low-privileged user authenticates to Splunk Web and uploads a specially crafted file to the apptemp directory via the app import feature. When Splunk processes the temporary file for app installation, the malicious payload executes, giving the attacker remote code execution on the Splunk server." - exploitation_conditions: specific prerequisites from description: "low-privileged user that does not hold the admin or power Splunk roles". So attacker must have any low-privileged role, not power/admin. Also, the user must be able to upload a file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory. That directory might be writable by all authenticated users? The vulnerability is due to improper handling and insufficient isolation of temporary files. So condition: the Splunk instance must allow file uploads to apptemp by low-privileged users. It may be default. User interaction required (UI:R) could refer to the attacker needing to trick a user into processing? Actually UI:R in CVSS means the attacker must trick a user into taking some action. This might be that the low-privileged user must upload the file, but it's the attacker that is that user. In that case, it's not UI. Wait, CVSS says UI:R, which typically requires that the exploitation requires a user other than the attacker to take action. Could be that the attacker needs to convince a victim (another user) to upload the malicious file? The description says "a low-privileged user could potentially perform a Remote Code Execution by uploading a malicious file". That suggests the attacker is the low-privileged user themselves. So UI:R might be misinterpreted? Alternatively, the upload might be via some UI action that the attacker performs. But CVSS defines UI:R as "the vulnerable component requires user interaction to function. ... the user interaction is required from a user other than the attacker." So if the attacker themselves is the user performing the upload, then it's not UI:R but rather PR:L and no UI. The CVSS vector provided shows UI:R, but given descriptions, maybe the attacker must convince a user with low privileges to upload? Could be both: maybe the attacker can be a low-privileged user, but to trigger the RCE they need to interact with the apptemp directory in a way that involves some UI? Possibly the vulnerability is in the handling of uploaded files during app installation, which might be triggered by the user through UI. I think the vector might be AV:N/AC:H/PR:L/UI:N/..., but they put UI:R. I'll respect the given CVSS vector. So exploitation conditions: attacker must be authenticated as a low-privileged user (non-admin, non-power) and must be able to upload a file to apptemp, but also requires user interaction from another user? Perhaps the attacker uploads a file that is then executed when an admin installs or processes an app. That would be UI:R from the admin. So condition: "Exploitation requires an authenticated low-privileged user (without admin or power roles) to upload a malicious file to the apptemp directory, and a subsequent user action (e.g., by an administrator or automated process) that triggers processing of that file." But let's keep to the description. I'll state: "Requires an authenticated Splunk account with any low-privileged role (not admin or power). The attacker must be able to write files to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory, which may be accessible by default. User interaction is required to trigger the RCE (CVSS UI:R), likely from another user such as an administrator performing an app management action." Also add that it's remote over network. So: "Exploitation requires authenticated access as a low-privileged user (non-admin, non-power) and the ability to upload files to the apptemp directory. No specific non-default configuration is required if the directory is writable; however, the high attack complexity and user interaction requirement imply that the attacker must either trick another user into processing the file or rely on specific workflow." - attack_chain: Based on kill chain: authenticated low-privileged user uploads malicious file to apptemp directory via Splunk Web or API → file is stored in apptemp with insufficient isolation → later, an administrator or cron job processes the file (e.g., during app installation or validation) → the malicious payload executes → attacker achieves remote code execution with Splunk service privileges. So chain: "Authenticate as low-privileged Splunk user → Upload malicious file to apptemp directory via app upload feature → Wait for file to be processed by Splunk (e.g., admin action or scheduled task) → Malicious code executes → Gain RCE on Splunk server." 5 steps. - confidence_notes: Vendor advisory exists (SVD-2026-0403) confirming affected versions and patches. EPSS score is low, no KEV. POC status unknown (not listed). The CVE description is from the advisory. SSVC indicates no exploitation, not automatable, total impact. So confidence: "Vendor-confirmed vulnerability with fixed versions published in Splunk advisory SVD-2026-0403. No evidence of public exploit or active exploitation. Affected version ranges and patch availability are confirmed. The exact mechanism of code execution and preconditions (UI:R) require further analysis." - prevalence: Splunk is a widely used enterprise SIEM and log management platform. It is common in large organizations. So prevalence likely "high". Many enterprise environments run Splunk. So "high". - prevalence_basis: "widely deployed enterprise SIEM and log management solution". - assessed_cvss_vector: I need to provide my own independent CVSS. Given the description, I might adjust. The provided CVSS is 7.1: AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. Is that reasonable? The attack requires network, low privileges, but also user interaction. However, if the attacker is the low-privileged user and they upload a file and that immediately triggers RCE, then UI:N would be more appropriate. But the description doesn't say what triggers the RCE. Could be that the file is uploaded and then automatically processed by some Splunk internal mechanism without user interaction? The CWE-377 is Insecure Temporary File, but the vulnerability could be that the file is placed and then later processed by a service (like a cron job) that doesn't require user interaction. In that case, UI:N. However, the given vector has UI:R, which I'll respect because it's from Splunk themselves. So my assessed vector might differ. I'll reason: The attack requires the attacker to upload a file, but if the processing is automatic, then UI:N. But high complexity maybe due to file format or timing. I'll lean towards UI:N if the description doesn't mention tricking a user. But let's read: "could potentially perform a Remote Code Execution by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory due to improper handling". So the act of uploading is the vector. The handling is improper, so the mere upload might cause RCE. That suggests no additional user interaction. So I'd set UI:N. Also, the attack complexity: maybe needs specific file content? High? Might be high if

We are asked to produce a comprehensive JSON analysis. Notice that the user provides a CVE description, CVSS vector, CWE, EPSS, patch status, tags, SSVC, affected versions, references, etc. We need to synthesize all of that into the required fields. Let's parse the data: - CVE: CVE-2026-20202 - Description: In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.20, 10.0.2503.13, and 9.3.2411.127, a user who holds a role that contains the high-privilege capability `edit_user` could create a specially crafted username that includes a null byte or a non-UTF-8 percent-encoded byte due to improper input validation. This could lead to inconsistent conversion of usernames into a proper format for storage and account management inconsistencies, such as being unable to edit or delete affected users. - CVSS Score: 6.6, Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H - CWE: CWE-176 (Improper Handling of Unicode Encoding? Actually CWE-176 is "Improper Handling of Unicode Encoding" but the description mentions null byte, percent-encoded bytes, and improper input validation; CWE-176 fits.) - EPSS: 0.04% (percentile 12%) - Patch: Available from vendor - Reported by: cisco (maybe Cisco security team? no matter) - CPE: cpe:2.3:a:splunk:splunk_enterprise:*:*:*:*:*:*:*:*, cpe:2.3:a:splunk:splunk_cloud_platform:*:*:*:*:*:*:*:* - Tags: Information Disclosure, Splunk Enterprise, Splunk Cloud Platform. Note: Tags include "Information Disclosure" but the CVSS has C:H/I:H/A:H, which implies full impact, not just info disclosure. Possibly the main tag is Information Disclosure? I'll reconcile later. - SSVC: Exploitation: none, Automatable: no, Technical Impact: total - ENISA EUVD ID: EUVD-2026-22930 - Affected versions from EUVD: listed as ranges. Now, we need to construct the analysis. Let's note: - Product name: Splunk Enterprise (or Splunk Cloud Platform) – primary: Splunk Enterprise. So "Splunk Enterprise" (or "Splunk Enterprise and Cloud Platform" but field says 1-3 words, so "Splunk Enterprise" covers both? The description covers both, but product_name should be specific product. I'll choose "Splunk Enterprise" as primary, because the vulnerability exists in the enterprise product, and cloud platform is a variant. Alternatively, "Splunk Cloud Platform" is also affected. But given the tags list both, I'll prioritize Splunk Enterprise. The analysis will mention both. - Summary: Synthesize original. Start with impact verb and product. Use all data: It's a vulnerability resulting from improper input validation in username creation by a privileged user (edit_user capability). It can lead to account management inconsistencies, inability to edit/delete users. CVSS 6.6, high-privilege, no user interaction, high attack complexity? Actually AC:H because it requires crafting a username with null byte/percent-encoded byte. C:H/I:H/A:H. EPSS low, SSVC says no known exploitation, not automatable, total tech impact. The summary should state what it is, who affected, what attacker can do. No KEV, no POC mentioned, but I'll note that based on available data no public exploit identified. Since SSVC says exploitation none, I'll say "no known active exploitation". Also mention if POC exists? Data doesn't say. I'll say "no public exploit code known". I'll say the EPSS score is low (0.04%), indicating low likelihood of exploitation. The summary: "Improper input validation in Splunk Enterprise and Cloud Platform allows a high-privilege user with the edit_user capability to craft usernames containing null bytes or non-UTF-8 encoded characters, leading to account management inconsistencies and potentially full system compromise." But careful: The impact of "inconsistent conversion of usernames" might not directly translate to "full system compromise". However, the CVSS says C/I/A all High, so it could allow complete control. I'll reflect that. So summary: "Unauthorized account manipulation in Splunk Enterprise and Splunk Cloud Platform allows a privileged user with the edit_user capability to create specially crafted usernames with null bytes or non-UTF-8 percent-encoded characters due to improper input validation. This can cause inconsistent storage and management of accounts, potentially leading to full compromise of the affected system as indicated by the CVSS score. At the time of analysis, no active exploitation or public exploit code has been observed, and the EPSS score is low (0.04%)." - Technical context: Underlying technology/library/protocol involved. The vulnerability involves improper handling of unicode encoding (CWE-176) and percent-encoded data in username creation. It's within the user management functionality of Splunk. The CPE strings identify affected products: Splunk Enterprise and Splunk Cloud Platform. I'll mention that the issue lies in input validation when processing usernames, particularly the failure to properly sanitize or normalize encoding, which could lead to database inconsistencies. - Risk assessment: CVSS vector: AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H. So network attack vector, high complexity, high privileges required, no user interaction, scope unchanged, all impact high. EPSS 0.04%, very low probability of exploitation. SSVC: none exploitation, not automatable, total tech impact. So overall risk is moderate, because exploitation requires high privileges and specific craft, and is not easily automatable. There's no KEV or POC. The risk is that a malicious insider with high privileges could cause denial of service or account lockout, but CVSS suggests full compromise. I'll note: CVSS indicates high privilege but low EPSS and no known exploits, suggesting targeted insider threat scenario rather than widespread external attacks. Also, the complexity is high because crafting the payload requires knowledge. I'll state: "While CVSS assigns a high base score, the risk is tempered by the high privilege requirement and attack complexity, as well as the absence of any public exploit or active exploitation reports. The EPSS score of 0.04% suggests an extremely low probability of exploitation in the wild." Also note that IT is only accessible via network, but the attacker must already be authenticated and hold the edit_user role. So this is more of a privilege abuse scenario than an remote unauthenticated one. - Affected products: "Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.20, 10.0.2503.13, and 9.3.2411.127. These are covered by CPE cpe:2.3:a:splunk:splunk_enterprise:* and cpe:2.3:a:splunk:splunk_cloud_platform:*. Vendor advisory available at https://advisory.splunk.com/advisories/SVD-2026-0401." No need for bullet points. - Remediation: "Upgrade to Splunk Enterprise versions 10.2.2, 10.0.5, 9.4.10, or 9.3.11, and Splunk Cloud Platform to version 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.20, 10.0.2503.13, or 9.3.2411.127 respectively. As a workaround, restrict the edit_user capability to trusted administrators only and monitor for usernames containing unusual characters. The vendor advisory (SVD-2026-0401) provides details." - Exploit scenario: "A malicious insider with the edit_user role creates a username containing a null byte or non-UTF-8 percent-encoded sequence. Due to improper input validation, the username is stored inconsistently, leading to account management failures that could grant unauthorized access or prevent legitimate edits/deletions." - Exploitation conditions: Must hold a role with the edit_user capability. The crafted username must include a null byte or non-UTF-8 percent-encoded byte. The affected systems are unpatched Splunk Enterprise or Cloud Platform versions. The attacker needs network access and to be authenticated with high privileges. No special network conditions. So "Exploitation requires an authenticated user with the edit_user capability and the ability to craft a username containing a null byte or a non-UTF-8 percent-encoded byte. This condition limits the attack surface to privileged insiders or attackers who have already compromised a high-privilege account." I'll phrase concretely: "Exploitation requires the attacker to already hold a role with the 'edit_user' capability and to craft a specially formed username containing a null byte or non-UTF-8 percent-encoded byte. No special configuration beyond default role assignments is needed, but the vulnerability cannot be exploited remotely without authentication or lower privileges." That's specific. - Attack chain: Format as short steps with arrows. Given the scenario: Access (network access to Splunk) → Authenticate with high-privilege account → Craft username with null byte/non-UTF-8 → Send username creation request → Trigger inconsistent storage → Gain account management control → Potential full system compromise. I'll simplify: "Authenticate to Splunk with edit_user role → Craft username with null byte or malformed encoding → Submit user creation request → Trigger inconsistent storage and account management issues → Potentially achieve code execution or full compromise." But the description says "inconsistent conversion of usernames" and "account management inconsistencies" but CVSS suggests full compromise; I'll reflect that. I'll do: "Authenticate as privileged user → Craft username with null byte or non-UTF-8 percent-encoded byte → Create new user account via API/UI → Username stored inconsistently across backends → Gain ability to manipulate accounts beyond normal privileges → Achieve full system compromise." - Confidence notes: I have vendor advisory, so confirmed affected versions and patch. No KEV, no POC reported, so exploit status is unknown but not seen in wild. CVSS provided, but I'm confident in the metrics. So "Vendor advisory confirms affected versions and patch availability. Active exploitation not reported in CISA KEV; no public exploit code identified. CVSS vector provided by Splunk via NVD is consistent with the described impact." I'll add that POC status unknown, but that's acceptable. - Prevalence: Splunk Enterprise is widely deployed in enterprises for security monitoring and data analytics. "high" fits. Splunk is a common SIEM and log management tool, but not as ubiquitous as Apache or Linux kernel. It's widely used, so prevalence: high. basis: "widely deployed SIEM and log management platform". Enough. - Assessed CVSS vector: I'll provide my own independent assessment. Based on description, the vulnerability is exploitable over network (AV:N), but requires high privileges (PR:H), user interaction none (UI:N). Complexity: an attacker needs to craft a malicious username, which might be somewhat complex but not extremely difficult; I'd say AC:H because it involves encoding issues, matching the original vector. Scope unchanged (S:U). Impact on confidentiality, integrity, availability all high, given the potential for full system compromise. So the vector will be identical: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H. I'll justify: "Attack complexity is high due to the need to craft specific malformed usernames; privileges are high because edit_user capability is required; impact is total as the flaw can lead to full system compromise." So the assessed vector is the same as provided. But I should not just copy; I'll present it and justify. For assessed_cvss40_vector: map to 4.0. AV:N stays N, AC:H maps to AC:H? In CVSS 4.0, Attack Complexity (AC) is H, Attack Requirements (AT) would be None (AT:N) since no specific additional requirements beyond complexity. PR:H, UI:N. For vulnerable system: VC:H, VI:H, VA:H (confidentiality, integrity, availability). Subsequent system: not affected, so SC:N, SI:N, SA:N.

Improper access control in the Discover Splunk Observability Cloud app allows low-privileged users without admin or power roles to retrieve Observability Cloud API access tokens in Splunk Enterprise versions below 10.2.1/10.0.4 and Splunk Cloud Platform versions below 10.2.2510.5/10.1.2507.16/10.0.2503.12. An attacker with low-level credentials could leverage this to obtain API tokens for unauthorized access to Observability Cloud resources. No patch is currently available.

Improper access control in Splunk Enterprise and Cloud Platform versions below specified thresholds allows low-privileged users without admin or power roles to extract sensitive information from job search logs through the MongoClient logging channel. Affected versions include Enterprise 10.2.1, 10.0.4, 9.4.9, and 9.3.10, as well as corresponding Cloud Platform releases. No patch is currently available for this medium-severity vulnerability.

Splunk Enterprise and Cloud Platform versions below specified thresholds fail to properly restrict access to the passwords configuration API endpoint, allowing low-privileged users without admin or power roles to retrieve hashed or plaintext credential values from passwords.conf. This information disclosure vulnerability could enable attackers to obtain sensitive authentication credentials for further system compromise. No patch is currently available.

Arbitrary shell command execution in Splunk Enterprise and Cloud Platform allows authenticated users with the edit_cmd capability to inject commands through the unarchive_cmd parameter in the preview upload endpoint. Affected versions include Splunk Enterprise below 10.2.0, 10.0.4, 9.4.9, and 9.3.10, as well as corresponding Cloud Platform versions. An attacker with high-privilege roles could achieve remote code execution on vulnerable systems, though no patch is currently available.

Stored XSS via path traversal in Splunk Enterprise and Cloud Platform allows low-privileged users to inject malicious JavaScript into Views, compromising any user who visits the affected page. An attacker must socially engineer a victim into initiating the malicious request, but no special privileges or user interaction beyond initial page load is required. Affected versions include Splunk Enterprise below 10.2.0, 10.0.3, 9.4.9, and 9.3.9, with no patch currently available.

Splunk Enterprise and Splunk Cloud Platform deployments expose SAML authentication configurations in plaintext logs accessible to users with Search Head Cluster administrative roles and _internal index access, allowing credential and authentication extension disclosure. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, as well as Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120. No patch is currently available for this medium-severity vulnerability.

Client-side denial-of-service in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users to inject malicious payloads through user profile parameters in the authentication REST API endpoint, causing significant page load delays or temporary unresponsiveness of the Splunk Web interface. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.8, 9.3.9, and 9.2.12, and Splunk Cloud Platform below 10.2.2510.3, 10.1.2507.8, 10.0.2503.9, and 9.3.2411.121. No patch is currently available for this vulnerability.

In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.5, 9.3.7, and 9.2.9, and Splunk Cloud Platform versions below 10.1.2507.0, 10.0.2503.9, 9.3.2411.112, and 9.3.2408.122, a low-privileged user who does not hold the "admin" or "power" Splunk roles could bypass the SPL safeguards for risky commands when they create a Data Model that contains an injected SPL query within an object. [CVSS 3.5 LOW]

In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and versions below 3.9.10, 3.8.58 and 3.7.28 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `label` column field after adding a new device in the Splunk Secure Gateway app. This could potentially lead to a client-side denial of service (DoS).

A security vulnerability in Splunk Enterprise (CVSS 5.3) that allows them. Remediation should follow standard vulnerability management procedures.

In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and below 3.9.10, 3.8.58, and 3.7.28 of Splunk Secure Gateway app in Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles and subscribes to mobile push notifications could receive notifications that disclose the title and description of the report or alert even if they do not have access to view the report or alert.

In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, and 9.2.9 and Splunk Cloud Platform versions below 9.3.2411.116, 9.3.2408.124, 10.0.2503.5 and 10.1.2507.1, a low-privileged user that does. Rated low severity (CVSS 3.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, 9.2.9, and Splunk Cloud Platform versions below 10.0.2503.5, 9.3.2411.111, and 9.3.2408.121, an unauthenticated attacker could craft a. Rated low severity (CVSS 3.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.

In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, an unauthenticated attacker could trigger a blind server-side request forgery (SSRF) potentially letting an attacker perform REST API calls on behalf of an authenticated high-privileged user.

In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a user who holds a role that contains the high-privilege capability `change_authentication`, could send multiple LDAP bind requests to a specific internal endpoint, resulting in high server CPU usage, which could potentially lead to a denial of service (DoS) until the Splunk Enterprise instance is restarted. See https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities and https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/use-ldap-as-an-authentication-scheme/configure-ldap-with-splunk-web#cfe47e31_007f_460d_8b3d_8505ffc3f0dd__Configure_LDAP_with_Splunk_Web for more information.

In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privilege user that does not hold the "admin" or "power" Splunk roles could perform an extensible markup language (XML) external entity (XXE) injection through the dashboard tab label field. The XXE injection has the potential to cause denial of service (DoS) attacks.

In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through the error messages and job inspection details of a saved search. This could result in execution of unauthorized JavaScript code in the browser of a user.

In Splunk Enterprise versions below 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious payload through the `dataset.command` parameter of the `/app/search/table` endpoint, which could result in execution of unauthorized JavaScript code in the browser of a user.

In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.111, 9.3.2408.119, and 9.2.2406.122, a low-privileged user that does not hold the admin or power Splunk roles could access sensitive search results if Splunk Enterprise runs an administrative search job in the background. If the low privileged user guesses the search job’s unique Search ID (SID), the user could retrieve the results of that job, potentially exposing sensitive search results. For more information see https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/about-jobs-and-job-management and https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/manage-search-jobs.

In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.7, and 9.1.10 and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create or overwrite [system source type](https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/9.2/configure-source-types/create-source-types) configurations by sending a specially-crafted payload to the `/servicesNS/nobody/search/admin/sourcetypes/` REST endpoint on the Splunk management port.

In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, an unauthenticated attacker could send a specially-crafted SPL search command that could trigger a rolling restart in the Search Head Cluster through a Cross-Site Request Forgery (CSRF), potentially leading to a denial of service (DoS).<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.<br><br>See [How rolling restart works](https://docs.splunk.com/Documentation/Splunk/9.4.2/DistSearch/RestartSHC) for more information.

In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.114, and 9.2.2406.119, an unauthenticated attacker can send a specially-crafted SPL search that could change the membership state in a Splunk Search Head Cluster (SHC) through a Cross-Site Request Forgery (CSRF), potentially leading to the removal of the captain or a member of the SHC.<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.

In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.107, 9.3.2408.117, and 9.2.2406.121, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `User Interface - Views` configuration page that could potentially lead to a denial of service (DoS).The user could cause the DoS by exploiting a path traversal vulnerability that allows for deletion of arbitrary files within a Splunk directory. The vulnerability requires the low-privileged user to phish the administrator-level victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.

In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See [Define alert suppression groups to throttle sets of similar alerts](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/manage-alert-trigger-conditions-and-throttling/define-alert-suppression-groups-to-throttle-sets-of-similar-alerts).

In Splunk Enterprise versions below 9.4.2, 9.3.4 and 9.2.6, and Splunk Cloud Platform versions below 9.3.2411.102, 9.3.2408.111 and 9.2.2406.118, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the pdfgen/render REST endpoint that could result in execution of unauthorized JavaScript code in the browser of a user.

In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.103, 9.2.2406.108, 9.2.2403.113, 9.1.2312.208 and 9.1.2308.212, a low-privileged user. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8, and Splunk Cloud Platform versions below 9.3.2408.104, 9.2.2406.108, 9.2.2403.114, and 9.1.2312.208, a low-privileged user that does not. Rated high severity (CVSS 8.0), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.2.2403.108, and 9.1.2312.204, a low-privileged user that does not hold the "admin" or "power". Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and Splunk Cloud Platform versions below 9.3.2408.107, 9.2.2406.112, 9.2.2403.115, 9.1.2312.208 and 9.1.2308.214, a low-privileged. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.107, 9.2.2406.111, and 9.1.2308.214, a low-privileged user that does not hold the. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.3.2408.101, 9.2.2406.106, 9.2.2403.111, and 9.1.2312.206, an SPL command can potentially. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.0, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.1.2312.206, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles, that. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.2.2406.107, 9.2.2403.109, and 9.1.2312.206, a low-privileged user that does not hold the “admin“. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.3 and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.108 and 9.1.2312.205, a low-privileged user that does not hold the "admin" or "power" Splunk. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.3 and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.108, and 9.1.2312.204, a low-privileged user that does not hold the "admin" or "power". Rated low severity (CVSS 3.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.107, 9.1.2312.204, and 9.1.2312.111, a low-privileged user that does not hold the "admin". Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.3 and 9.1.6, and Splunk Secure Gateway versions on Splunk Cloud Platform versions below 3.4.259, 3.6.17, and 3.7.0, a low-privileged user that does not hold. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.3.1, and 9.2.0 versions below 9.2.3, and Splunk Cloud Platform versions below 9.2.2403.103, 9.1.2312.200, 9.1.2312.110 and 9.1.2308.208, a low-privileged user. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312, an admin user could store and execute arbitrary JavaScript code in the browser context. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109, an attacker could determine whether or not another user exists on the instance by. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk. Rated low severity (CVSS 3.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.2.2403.100, an authenticated, low-privileged user that does not hold the admin or power Splunk. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109 and 9.1.2308.207, an authenticated user could create an external lookup that calls a. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.2.12, 9.0.6, and 9.1.1, an attacker can create an external lookup that calls a legacy internal function. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can exploit an absolute path traversal to execute arbitrary code that is located on a separate disk. Rated high severity (CVSS 8.8), this vulnerability is low attack complexity. No vendor patch available.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can use the `printf` SPL function to perform a denial of service (DoS) against the Splunk Enterprise instance. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions lower than 9.0.6 and 8.2.12, a malicious actor can send a malformed security assertion markup language (SAML) request to the `/saml/acs` REST endpoint which can cause a. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting (XSS) on the “/app/search/table” web. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

On Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, an unauthorized user can access the {{/services/indexing/preview}} REST. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, an attacker can exploit a vulnerability in the {{dump}} SPL command to cause a. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can perform an unauthorized transfer of data from a. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable. No vendor patch available.

In Splunk Enterprise versions below 9.0.5, 8.2.11. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can trigger an HTTP response splitting vulnerability with. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

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, a low-privileged user who holds a role that has the ‘edit_user’ capability. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

On Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, an unauthenticated attacker can send specially-crafted messages to the XML parser within SAML authentication to cause a denial of. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, an improperly-formatted ‘INGEST_EVAL’ parameter in a Field Transformation crashes the Splunk daemon (splunkd). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, aliases of the ‘collect’ search processing language (SPL) command, including ‘summaryindex’, ‘sumindex’, ‘stash’,’ mcollect’, and. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘map’ search processing language (SPL) command lets a search bypass SPL safeguards for risky commands. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘sendemail’ REST API endpoint lets any authenticated user send an email as the Splunk instance. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table upload feature let a user upload lookup tables with unnecessary filename extensions. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘search_listener’ parameter in a search allows for a blind server-side request forgery (SSRF) by an authenticated user. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘display.page.search.patterns.sensitivity’ search parameter lets a search bypass SPL safeguards for risky commands. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘pivot’ search processing language (SPL) command lets a search bypass SPL safeguards for risky commands using a saved search job. Rated high severity (CVSS 8.0), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting (XSS) in an extensible mark-up language (XML) View through the ‘layoutPanel’ attribute in the. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.

In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting (XSS) through the error message in a Base64-encoded image. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.13 and 8.2.10, the ‘createrss’ external search command overwrites existing Resource Description Format Site Summary (RSS) feeds without verifying permissions. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, sending a malformed file through the Splunk-to-Splunk (S2S) or HTTP Event Collector (HEC) protocols to an indexer results in a blockage. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, an authenticated user can perform an extensible markup language (XML) external entity (XXE) injection via a custom View. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.