Splunk Security Advisories & CVEs
220 advisories tracked · Splunk (prodsec@splunk.com CNA) via NVD · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
Monitor Splunk CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Check if your Splunk device is affected
Pick your product and enter the exact software release it runs. We match it against the affected/fixed versions in Splunk's recent advisories.
Official source
Splunk (prodsec@splunk.com CNA) via NVD
Splunk is its own CVE Numbering Authority. VulniPulse ingests Splunk's CVEs from the NVD CNA feed (prodsec@splunk.com), each linking to its SVD-YYYY-NNNN advisory on advisory.splunk.com. Covers Splunk Enterprise, Splunk Cloud Platform, the Universal Forwarder, IT Service Intelligence (ITSI), SOAR, Enterprise Security and Splunk apps/add-ons — the SIEM at the centre of most SOCs, so a security-team audience that patches on advisory day.
Latest Splunk advisories
Medium [CVE-2026-76342] Risky Commands Safeguards Bypass through Splunk Web in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands ( ) and Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76341] Risky Commands Safeguards Bypass through Table Editor Dataset Initial Data in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset ( ), SPL safeguards for risky commands ( ), and Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76340] Missing Authorization for Reloading Token-Signing Keys through the REST API in Splunk Enterprise
In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could cause Splunk Enterprise to reload token-signing keys through the Representational State Transfer (REST) API. The vulnerability does not affect Splunk Enterprise versions below 10.4. The vulnerability is possible because the REST API does not require authentication or the change_authentication capability for the token-key reload action. For more information see Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76339] SPL Injection through the geostats Command in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could inject arbitrary Search Processing Language (SPL) commands through the geostats command. The injected SPL runs with the permissions of another authenticated user after that user initiates the attacker-controlled geostats search in Splunk Web. The injected SPL could expose all relevant data available to the second user, including stored credentials, and modify lookup files that the second user has permission to change. The vulnerability is possible because the geostats command does not sufficiently validate input before Splunk Enterprise processes it. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see geostats ( ) in the Splunk documentation.
Medium [CVE-2026-76337] Path Traversal through Splunk Web Static File Serving in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could read JavaScript files outside the Splunk Web static directory. The vulnerability is possible because Splunk Web does not restrict static file requests to the configured static directory.
Medium [CVE-2026-76334] SPL Injection through Dashboard Studio Workflow Actions in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store a Dashboard Studio workflow action containing attacker-controlled Search Processing Language (SPL). When another authenticated user selects the action from Event Actions and selects Continue, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Dashboard Studio does not sufficiently validate workflow-action URLs before submitting requests. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will.
Medium [CVE-2026-76329] SPL Injection through Monitoring Console Dashboard Inputs in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick a user who holds the "admin" Splunk role into opening a crafted link to Monitoring Console. When that user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could expose data available to that user or modify lookup data. The vulnerability is possible because Monitoring Console does not sufficiently validate data used to build dashboard searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will.
Medium [CVE-2026-76328] SPL Injection through Splunk Web in Splunk Enterprise
In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a dashboard. When another authenticated user exports the dashboard as a Portable Document Format (PDF) file, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Splunk Web does not sufficiently validate dashboard content before processing PDF exports. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Generate PDFs of your reports and dashboards ( ) in the Splunk documentation.
Medium [CVE-2026-76327] SPL Injection through Splunk Web in Splunk Secure Gateway
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, an unauthenticated user could trick a user who holds the "admin" or "sc_admin" Splunk roles into opening a crafted Splunk Web Uniform Resource Locator (URL). The resulting dashboard searches could run arbitrary Search Processing Language (SPL) commands with the permissions available to the affected user. The commands could expose all relevant data available to that user and affect search results or lookup data. The vulnerability is possible because Splunk Secure Gateway dashboards do not correctly neutralize caller-supplied values before using them in dashboard searches. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will.
Medium [CVE-2026-76326] Stored Cross-Site Scripting through Dashboard Sparkline Tooltip Options in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could store a dashboard view that runs JavaScript in the browser of another user who opens it and hovers over a sparkline table cell, allowing for access to all relevant data and system integrity available to that user. The vulnerability is possible because the dashboard table renderer does not sufficiently restrict tooltip options or escape tooltip content before display.
Medium [CVE-2026-76324] Stored Cross-Site Scripting (XSS) in Splunk Web Tours in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could create a malicious Splunk Web tour and cause arbitrary JavaScript to run in the browser of another user when that user opens a crafted tour link. The JavaScript runs in the browser of the affected user, allowing for access to all relevant data available to that user. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web renders tour content and tour navigation links without sufficient output encoding and accepts a tour selector value that can be treated as markup. The vulnerability requires another user to open a crafted tour link. The user who holds the "power" Splunk role should not be able to trigger JavaScript execution in another user's browser without that user interaction.
Medium [CVE-2026-76323] SPL Risky Command Safeguards Bypass through the Job Details Dashboard in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could bypass Search Processing Language (SPL) safeguards for risky commands through the Job Details dashboard. The injected SPL could run using the permissions of an authenticated user who opens a crafted Job Details dashboard link. This could allow access to all relevant data and affect system integrity within those permissions. The vulnerability is possible because the Job Details dashboard does not correctly neutralize a caller-supplied search identifier before placing it into SPL searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see About jobs and job management ( ) in the Splunk documentation.
Medium [CVE-2026-76322] SPL Injection through Dashboard Studio Search Query Options in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "user" Splunk role could craft a Dashboard Studio dashboard that runs attacker-controlled Search Processing Language (SPL) for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is possible because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "user" Splunk role should not be able to exploit the vulnerability at will. For more information see Create search-based visualizations with ds.search ( ) in the Splunk documentation.
Medium [CVE-2026-76320] SPL Injection through Cross-Site Request Forgery (CSRF) in the Event Type Builder in Splunk Web for Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could cause an authenticated user to run arbitrary Search Processing Language (SPL) searches on their behalf through the Event Type Builder. This could expose all relevant data and stored credentials. The vulnerability is possible when the Event Type Builder accepts cross-site request input and retains SPL-affecting values while building sample event searches. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will. For more information see Automatically find and build event types ( ) in the Splunk documentation.
Medium [CVE-2026-76318] Stored Cross-Site Scripting (XSS) through Splunk Web in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could store a malicious script in an alert trigger condition field. When another user opens the crafted link, the script runs in the browser of that user and could access all data available to that user. The vulnerability is possible because Splunk Web uses the alert threshold value in generated alert trigger condition markup without escaping special characters. Successful exploitation requires another user to open the crafted link. For more information see Configure alert trigger conditions ( ) and Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76309] Structured Query Language (SQL) Injection through the REST API in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the "admin" or "power" Splunk roles could inject Structured Query Language (SQL) through the Representational State Transfer (REST) API, causing Splunk Enterprise to evaluate attacker-controlled text as part of a database query. The SQL injection is possible because the REST API incorporates user-supplied filter values into database queries without proper neutralization.
Medium [CVE-2026-76263] Improper Access Control through the REST API in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete Splunk Processing Language version 2 (SPL2) modules belonging to other users through the data management orchestrator interface. The broken object level authorization is possible because the data management orchestrator does not verify that the requesting user owns the target resources before it deletes the modules. For more information see Manage SPL2-based apps ( ) in the Splunk documentation.
Medium [CVE-2026-76261] Insecure Default Access Control List through the REST API in Splunk Secure Gateway
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could read Spacebridge asymmetric private keys, which are secrets that compromise affected Spacebridge private-key material stored in the app collection, through the Splunk Secure Gateway App Key Value Store Representational State Transfer (REST) API. The vulnerability is possible on instances upgraded from older Splunk Secure Gateway deployments when the private-key migration remains incomplete, leaving key material in a collection with an insecure default access control list.
Medium [CVE-2026-76260] Incorrect Permission Assignment for Critical Resource through the REST API in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the rest_properties_get capability could read encrypted stored credentials through the Representational State Transfer (REST) API. Successful exploitation can expose relevant data protected by the stored credentials. The incorrect permission assignment is possible because the properties REST endpoint requires the rest_properties_get capability instead of the list_storage_passwords capability to read stored credentials. For more information see Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76258] Use of Hard-coded Cryptographic Key through Companion App Registration in Splunk Secure Gateway
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.10, 3.9.24, and 3.8.71, a user who does not hold the "admin" or "power" Splunk roles could register an arbitrary companion app and cause Splunk Secure Gateway to forward mobile user requests, including tokens that compromise all relevant data available to the affected mobile user, to an attacker-controlled Uniform Resource Locator (URL). The vulnerability is possible because a hard-coded cryptographic key in the Splunk Secure Gateway companion app registration handler allows for arbitrary callback URL registration without restriction. For more information see Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.