CVE Vulnerability Catalog
Translated CVE descriptions from NVD NIST - in English
Browse vulnerabilities by packageCISA KEV catalog updated: (v2026.11.06)
Weekly CVE digest
One email a week with newly published vulnerabilities worth knowing about. No account needed.
This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.
An unauthenticated attacker can trick a user with the "admin" or "sc_admin" role into opening a crafted Splunk Web URL. The resulting dashboard searches could run arbitrary SPL commands with the victim's permissions, potentially exposing data and affecting search results or lookup data. The vulnerability is due to improper neutralization of caller-supplied values in Splunk Secure Gateway dashboards.
A user without the "admin" or "power" roles can store a dashboard view that runs JavaScript in another user's browser when they open it and hover over a sparkline table cell, potentially allowing access to all relevant data and system integrity. The vulnerability is due to insufficient restriction of tooltip options and lack of escaping tooltip content before display.
A user with the "power" role can create a malicious Splunk Web tour and cause arbitrary JavaScript to run in another user's browser when they open a crafted tour link. The JavaScript runs in the victim's browser, allowing access to all relevant data. The XSS vulnerability is due to insufficient output encoding of tour content and navigation links and accepting a tour selector value that can be treated as markup.
A user without the "admin" or "power" roles can bypass SPL safeguards for risky commands through the Job Details dashboard. The injected SPL could run with 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. The vulnerability is due to improper neutralization of a caller-supplied search identifier before placing it into SPL searches.
A user with the "user" role could craft a Dashboard Studio dashboard that runs attacker-controlled SPL for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is due to inconsistent enforcement of the expected app-visibility authorization boundary before dashboard search query options reach search dispatch.
An unauthenticated attacker could cause an authenticated user to run arbitrary SPL searches on their behalf through the Event Type Builder. This could expose all relevant data and stored credentials. The vulnerability occurs when the Event Type Builder accepts cross-site request input and retains SPL-affecting values while building sample event searches.
A user with a role that has 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 that user's browser and could access all data available to that user. The vulnerability is due to using the alert threshold value in generated alert trigger condition markup without escaping special characters.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user without 'admin' or 'power' roles can inject SQL through the REST API. This is possible because the REST API does not properly neutralize user-supplied filter values, allowing attacker-controlled text to be evaluated as part of a database query.
In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user without 'admin' or 'power' roles can delete SPL2 modules belonging to other users through the data management orchestrator interface. The vulnerability is due to missing ownership verification before deletion (broken object level authorization).
In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70, a user without 'admin' or 'power' roles can read Spacebridge private keys via the Key Value Store REST API. The vulnerability occurs on instances upgraded from older versions when private-key migration is incomplete, leaving keys in a collection with an insecure default ACL.
In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the rest_properties_get capability can read encrypted stored credentials via the REST API. The vulnerability is due to incorrect permission assignment: the properties REST endpoint requires rest_properties_get instead of list_storage_passwords to read stored credentials.
In 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, a user without 'admin' or 'power' roles can register an arbitrary companion app and cause Splunk Secure Gateway to forward mobile user requests, including tokens, to an attacker-controlled URL. The vulnerability is due to a hard-coded cryptographic key in the companion app registration handler allowing unrestricted callback URL registration.
In 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, a user with permissions to list storage passwords but without Splunk Secure Gateway admin privileges can access MDM signing secrets, compromising mobile-device enrollment trust. The vulnerability is due to REST API endpoints for deployment bundle, SAML setup, and companion app workflows not requiring Splunk Secure Gateway admin privileges.
In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70, a user without 'admin' or 'power' roles can read sensitive SAML setup and instance settings information via Splunk Secure Gateway REST API endpoints. The vulnerability is due to these endpoints not enforcing authorization requirements before returning configuration information.
In Splunk Enterprise below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user without 'admin' or 'power' roles can trick another user into running arbitrary SPL commands through the Data Model Editor using the victim's permissions. The vulnerability is due to missing SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The attack requires phishing the victim.
In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.13, an unauthenticated user who tricks another user into visiting a malicious web page could run unauthorized JavaScript in that user's browser. The XSS is possible because Splunk Web does not validate the origin and source of messages received by a page message handler. The attack requires phishing the victim.
Out-of-bounds read in Remote Desktop Client allows an unauthorized attacker to disclose information over a network.
TinaCMS before version 2.5.2 has a vulnerability in the Vite dev server where the server does not reject requests from disallowed origins and still routes POST /media/upload/* to the media handler. A remote attacker can cause a developer's browser to submit a state-changing request, allowing attacker-controlled content to be written inside the media root.
TinaCMS production media adapters (next-tinacms-s3, next-tinacms-dos, next-tinacms-azure, next-tinacms-cloudinary) before specified versions do not enforce the configured mediaRoot on upload/delete operations. An authenticated CMS editor can create or delete objects anywhere the storage credential can reach, including other tenants' or non-media objects.
IBM System Storage DS8A00 and DS8900F in specific versions allow an authenticated user to read or modify another user's command history due to an externally controlled filename.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

