CVE Vulnerability Catalog

Cisco conducted a comprehensive internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76528 relate to protection mechanism failure and are grouped under CWE-693.

Cisco conducted a comprehensive internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76527 relate to improper check or handling of exceptional conditions and are grouped under CWE-703.

Cisco conducted an internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. CVE-2026-76526 relates to improper neutralization (CWE-707).

Cisco conducted an internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. CVE-2026-76408 relates to improper control of a resource through its lifetime (CWE-664).

Cisco conducted a comprehensive internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76407 relate to improper access control and are grouped under CWE-284.

In Splunk SOAR versions below 8.7.0, an unauthenticated user with access to encrypted credential data can submit Basic authentication data to the REST API to expose and decrypt that data. The vulnerability exists because Splunk SOAR decrypts encrypted Basic authentication values before completing authentication checks. The attack requires the user to possess encrypted credential data from an affected instance.

In Splunk SOAR versions below 8.7.0, an authenticated user could change the Enterprise Security edition through the REST API, causing Splunk SOAR to apply the license change. The vulnerability exists because Splunk SOAR authenticates requests to manage the Enterprise Security edition but does not authorize the caller before applying the license change.

In Splunk SOAR versions below 8.7.0, a user holding a role with the Users and Roles view permission could use the REST API to infer authentication token values for other users. If the inferred token grants administrative access, that user could gain administrative access to the Splunk SOAR instance. The vulnerability is possible because the REST API accepts caller-controlled query filters on sensitive user record fields.

In Splunk SOAR versions below 8.7.0, a user with the "Observer" role could use REST API query filters to infer password hashes and authorization tokens for other users. The disclosure occurs because query filters are applied to user records before sensitive fields are protected.

In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to view apps could download an archive of an installed app. This could expose all data in the app archive, including proprietary source code and sensitive information. The vulnerability is possible because Splunk SOAR does not verify permission to view apps before it returns the app archive.

In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to edit Automation Brokers could download the Splunk SOAR Automation Broker Docker Compose configuration file. The file contains the URL of the Splunk SOAR instance, the container image location, and the Splunk SOAR Automation Broker version. The vulnerability is possible because Splunk SOAR returns the configuration file without enforcing the Automation Broker edit permission.

In Splunk SOAR versions below 8.7.0, a user with a role holding the install_apps capability can install an app containing attacker-controlled content in its documentation, which Splunk SOAR does not sanitize before display. When another user with permission to view apps opens the app documentation, that content is executed in their browser, potentially allowing the attacker to access data and make changes with the victim's privileges.

Cisco's internal security review discovered multiple vulnerabilities related to improper neutralization (CWE-707). Fixes were released as part of a software hardening update.

Cisco conducted an internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. CVE-2026-76301 relates to protection mechanism failure (CWE-693).

Cisco conducted an internal security review resulting in a software hardening release that addresses multiple internally discovered vulnerabilities. CVE-2026-76300 relates to improper control of a resource through its lifetime (CWE-664).

Cisco conducted an internal security review resulting in a software hardening release. The vulnerabilities tracked by this CVE relate to improper access control and are classified under CWE-284.

In Splunk Enterprise versions below 10.4.4 and 10.2.8, a user without the admin or power Splunk roles could derive the PostgreSQL sidecar database superuser password and run arbitrary OS commands as the account running Splunk Enterprise on search head cluster members. The flaw exists because the PostgreSQL sidecar service derives a privileged database password from the search head cluster identifier that appears in search job logs.

In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, an unauthenticated user could trick a user holding the edit_federated_providers capability into turning off all federated search providers. This is possible because the federated provider REST API accepts GET requests for state-changing actions, and exploitation requires phishing the affected user.

In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could create, move, edit, or delete sourcetype renaming configurations that they own in apps that they do not have permission to access. The vulnerability is possible when Splunk Web is turned on because Splunk Web does not verify the required app permissions before it performs sourcetype renaming operations.

In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and Splunk Secure Gateway versions below 3.10.12, 3.9.26, and 3.8.73, a user without the "admin" or "power" roles could view dashboard and report listings beyond the requested filter scope while remaining within accessible objects. The vulnerability exists because Splunk Secure Gateway does not neutralize special characters in values before creating filters.