Splunk Enterprise
Monthly
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'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.
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.
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.
SQL injection in Splunk Enterprise's REST API allows low-privileged authenticated users to embed attacker-controlled SQL fragments into backend database queries, potentially exposing data beyond their authorized scope. Four actively maintained version branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with patched releases available across all branches per the vendor advisory SVD-2026-0801. The CVSS score of 4.3 reflects a read-only confidentiality impact (C:L/I:N/A:N) with no public exploit identified at time of analysis, though the attack pattern is well-understood and the REST API is network-accessible by default.
Broken object level authorization (BOLA) in Splunk Enterprise's data management orchestrator allows authenticated low-privileged users to delete SPL2 modules owned by other users. Affected versions are Splunk Enterprise 10.2.x before 10.2.6 and 10.4.x before 10.4.2; the feature is absent in versions prior to 10.2, so those are unaffected. No public exploit code or active exploitation has been identified at time of analysis, and a vendor-released patch is available.
Insufficient access controls on the Splunk Secure Gateway App Key Value Store REST API expose Spacebridge asymmetric private keys to any authenticated low-privilege user lacking the 'admin' or 'power' role. The exposure is conditional on instances that were upgraded from older Splunk Secure Gateway deployments where a private-key migration remained incomplete, leaving sensitive cryptographic material in a KVStore collection governed by an insecure default ACL. No public exploit code exists at time of analysis, but successful exploitation fully compromises the affected Spacebridge private-key material, enabling cryptographic impersonation or decryption of Spacebridge-protected communications.
Splunk Enterprise incorrectly gates the properties REST endpoint on the rest_properties_get capability rather than the purpose-built list_storage_passwords capability, allowing any authenticated user with that role permission to read encrypted stored credentials via the REST API. Affected branches span four active release lines: 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 per EUVD-2026-63112. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the flaw is mechanically straightforward for any user whose role carries the misassigned capability.
Splunk Secure Gateway's companion app registration handler contains a hard-coded cryptographic key, enabling any low-privileged authenticated Splunk user - explicitly excluding admin or power roles - to register an arbitrary attacker-controlled callback URL and cause Secure Gateway to forward mobile user requests and authentication tokens to that URL. Affected are Splunk Enterprise 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), alongside Splunk Secure Gateway branches 3.8 (below 3.8.71), 3.9 (below 3.9.24), and 3.10 (below 3.10.10). No public exploit code or active exploitation has been confirmed at time of analysis; however, the low attack complexity and minimal privilege requirement make this a credible insider-threat or post-compromise lateral movement vector in any environment running Splunk Mobile.
Unauthorized access to Mobile Device Management signing secrets in Splunk Secure Gateway allows a low-privileged Splunk user to compromise all mobile-device enrollment trust. Affected are Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.10, 3.9.24, and 3.8.71. An attacker holding only the 'list storage passwords' role permission - without Secure Gateway administration privileges - can invoke unprotected REST API endpoints (deployment bundle, SAML setup, companion app workflows) to retrieve MDM signing secrets, enabling enrollment of unauthorized or attacker-controlled mobile devices. No public exploit code or CISA KEV listing has been identified at time of analysis.
Information disclosure in Splunk Enterprise and Splunk Secure Gateway exposes sensitive SAML configuration and instance settings to any authenticated low-privilege user lacking the 'admin' or 'power' role. The Splunk Secure Gateway REST API endpoints responsible for returning SAML setup data fail to enforce authorization checks, allowing role-restricted users to retrieve IdP metadata, certificates, and SSO configuration they should not access. No public exploit code or active exploitation has been identified; a vendor patch is available and remediation is straightforward.
Cross-site scripting in Splunk Enterprise (below versions 10.4.2, 10.2.6, 10.0.9, and 9.4.13) enables an unauthenticated attacker to execute arbitrary JavaScript in an authenticated user's browser by tricking that user into visiting a malicious web page. Splunk Web's page message handler processes incoming postMessage events without validating their origin or source, allowing cross-origin script injection into the victim's active Splunk session. Successful exploitation can expose all data accessible to the victim user and permit unauthorized actions affecting system integrity; no public exploit code or CISA KEV listing has been identified at time of analysis.
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.
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.
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.
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
Account management inconsistencies in Splunk Enterprise and Splunk Cloud Platform allow users with the high-privilege 'edit_user' capability to create specially crafted usernames containing null bytes or non-UTF-8 percent-encoded bytes. This can lead to improper storage of usernames, resulting in inability to edit or delete affected users. No active exploitation has been identified and the EPSS score is very low (0.04%), indicating minimal real-world risk.
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'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.
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.
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.
SQL injection in Splunk Enterprise's REST API allows low-privileged authenticated users to embed attacker-controlled SQL fragments into backend database queries, potentially exposing data beyond their authorized scope. Four actively maintained version branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with patched releases available across all branches per the vendor advisory SVD-2026-0801. The CVSS score of 4.3 reflects a read-only confidentiality impact (C:L/I:N/A:N) with no public exploit identified at time of analysis, though the attack pattern is well-understood and the REST API is network-accessible by default.
Broken object level authorization (BOLA) in Splunk Enterprise's data management orchestrator allows authenticated low-privileged users to delete SPL2 modules owned by other users. Affected versions are Splunk Enterprise 10.2.x before 10.2.6 and 10.4.x before 10.4.2; the feature is absent in versions prior to 10.2, so those are unaffected. No public exploit code or active exploitation has been identified at time of analysis, and a vendor-released patch is available.
Insufficient access controls on the Splunk Secure Gateway App Key Value Store REST API expose Spacebridge asymmetric private keys to any authenticated low-privilege user lacking the 'admin' or 'power' role. The exposure is conditional on instances that were upgraded from older Splunk Secure Gateway deployments where a private-key migration remained incomplete, leaving sensitive cryptographic material in a KVStore collection governed by an insecure default ACL. No public exploit code exists at time of analysis, but successful exploitation fully compromises the affected Spacebridge private-key material, enabling cryptographic impersonation or decryption of Spacebridge-protected communications.
Splunk Enterprise incorrectly gates the properties REST endpoint on the rest_properties_get capability rather than the purpose-built list_storage_passwords capability, allowing any authenticated user with that role permission to read encrypted stored credentials via the REST API. Affected branches span four active release lines: 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 per EUVD-2026-63112. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the flaw is mechanically straightforward for any user whose role carries the misassigned capability.
Splunk Secure Gateway's companion app registration handler contains a hard-coded cryptographic key, enabling any low-privileged authenticated Splunk user - explicitly excluding admin or power roles - to register an arbitrary attacker-controlled callback URL and cause Secure Gateway to forward mobile user requests and authentication tokens to that URL. Affected are Splunk Enterprise 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), alongside Splunk Secure Gateway branches 3.8 (below 3.8.71), 3.9 (below 3.9.24), and 3.10 (below 3.10.10). No public exploit code or active exploitation has been confirmed at time of analysis; however, the low attack complexity and minimal privilege requirement make this a credible insider-threat or post-compromise lateral movement vector in any environment running Splunk Mobile.
Unauthorized access to Mobile Device Management signing secrets in Splunk Secure Gateway allows a low-privileged Splunk user to compromise all mobile-device enrollment trust. Affected are Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.10, 3.9.24, and 3.8.71. An attacker holding only the 'list storage passwords' role permission - without Secure Gateway administration privileges - can invoke unprotected REST API endpoints (deployment bundle, SAML setup, companion app workflows) to retrieve MDM signing secrets, enabling enrollment of unauthorized or attacker-controlled mobile devices. No public exploit code or CISA KEV listing has been identified at time of analysis.
Information disclosure in Splunk Enterprise and Splunk Secure Gateway exposes sensitive SAML configuration and instance settings to any authenticated low-privilege user lacking the 'admin' or 'power' role. The Splunk Secure Gateway REST API endpoints responsible for returning SAML setup data fail to enforce authorization checks, allowing role-restricted users to retrieve IdP metadata, certificates, and SSO configuration they should not access. No public exploit code or active exploitation has been identified; a vendor patch is available and remediation is straightforward.
Cross-site scripting in Splunk Enterprise (below versions 10.4.2, 10.2.6, 10.0.9, and 9.4.13) enables an unauthenticated attacker to execute arbitrary JavaScript in an authenticated user's browser by tricking that user into visiting a malicious web page. Splunk Web's page message handler processes incoming postMessage events without validating their origin or source, allowing cross-origin script injection into the victim's active Splunk session. Successful exploitation can expose all data accessible to the victim user and permit unauthorized actions affecting system integrity; no public exploit code or CISA KEV listing has been identified at time of analysis.
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.
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.
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.
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
Account management inconsistencies in Splunk Enterprise and Splunk Cloud Platform allow users with the high-privilege 'edit_user' capability to create specially crafted usernames containing null bytes or non-UTF-8 percent-encoded bytes. This can lead to improper storage of usernames, resulting in inability to edit or delete affected users. No active exploitation has been identified and the EPSS score is very low (0.04%), indicating minimal real-world risk.