Complete feed
Security advisories & CVEs
4602 advisories across 34 monitored vendors.
Android app · Google Play
Take your CVE monitoring with you.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Medium [CVE-2026-12664] GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with a read_api-scoped token to retrieve a project's incoming email address and create work items, bypassing the token's restrictions, due to insufficient scope enforcement on a GraphQL field
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with a read_api-scoped token to retrieve a project's incoming email address and create work items, bypassing the token's restrictions, due to insufficient scope enforcement on a GraphQL field.
Medium [CVE-2026-13319] GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, could have allowed an authenticated to read milestone metadata, including titles, descriptions, and full project paths, from arbitrary private projects across the instance without any project membership, due to missing authorization checks on a user-supplied project filter parameter in the group milestones API
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, could have allowed an authenticated to read milestone metadata, including titles, descriptions, and full project paths, from arbitrary private projects across the instance without any project membership, due to missing authorization checks on a user-supplied project filter parameter in the group milestones API.
Medium [CVE-2026-16255] GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when the instance-wide SAML or LDAP membership lock was enabled, an authenticated user could have granted or accepted project and group membership outside the identity provider's control, due to incomplete enforcement of the membership lock on requests created before the lock was enabled
GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when the instance-wide SAML or LDAP membership lock was enabled, an authenticated user could have granted or accepted project and group membership outside the identity provider's control, due to incomplete enforcement of the membership lock on requests created before the lock was enabled.
Medium [CVE-2026-105777] GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6.5 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have retrieved sensitive internal server credentials due to improper filtering of internal response headers
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6.5 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have retrieved sensitive internal server credentials due to improper filtering of internal response headers.
Medium [CVE-2026-112378] GitLab has remediated an issue in GitLab EE affecting all versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that under certain conditions could have allowed an authenticated user to access paid AI features without a valid subscription due to insufficient server-side validation in billing eligibility checks
GitLab has remediated an issue in GitLab EE affecting all versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that under certain conditions could have allowed an authenticated user to access paid AI features without a valid subscription due to insufficient server-side validation in billing eligibility checks.
Medium [CVE-2026-76406] Information Disclosure through REST API Authentication in Splunk SOAR
In Splunk SOAR versions below 8.7.0, an unauthenticated user with access to encrypted credential data from an affected Splunk SOAR instance could submit Basic authentication data to the Representational State Transfer (REST) API to expose and decrypt that encrypted credential data. The vulnerability is possible because Splunk SOAR decrypts encrypted Basic authentication values before completing authentication checks. The unauthenticated user should not be able to exploit the vulnerability at will. For more information see Using the REST API reference for Splunk SOAR (On-premises) ( ) in the Splunk documentation.
Medium [CVE-2026-76308] Missing Authorization through the REST API in Splunk SOAR
In Splunk SOAR versions below 8.7.0, an authenticated user could change the Enterprise Security edition through the Representational State Transfer (REST) API and cause Splunk SOAR to apply the license change. The vulnerability is possible because Splunk SOAR authenticates requests to manage the Enterprise Security edition but does not authorize the caller before it applies the license change. For more information see Using the REST API reference for Splunk SOAR (On-premises) ( ), Obtain and configure a Splunk SOAR (On-premises) license ( ), and Integration of Splunk SOAR with Splunk Enterprise Security ( ) in the Splunk documentation.
Medium [CVE-2026-76305] Improper Access Control during App Downloads in Splunk SOAR
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. For more information see Export or import an app ( ) and Manage roles and permissions in Splunk SOAR (On-premises) ( ) in the Splunk documentation.
Medium [CVE-2026-76304] Sensitive Information Disclosure through Automation Broker Configuration in Splunk SOAR
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 Uniform Resource Locator (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. For more information see Install Splunk Automation Broker on a Docker host ( ) and Manage roles and permissions in Splunk SOAR (On-premises) ( ) in the Splunk documentation.
Medium [CVE-2026-76303] Stored Cross-Site Scripting (XSS) through App Documentation in Splunk SOAR
In Splunk SOAR versions below 8.7.0, a user that holds a role with the install_apps capability could store attacker-controlled content that Splunk SOAR displays in app documentation by installing an app. If another user who holds a role with permission to view apps opens the app documentation, Splunk SOAR could run that content in the browser of the user who opened the app documentation. With this access, the first user could access data and make changes that the user who opened the app documentation could make. The vulnerability is possible because Splunk SOAR does not sanitize app documentation content before it displays that content. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user that holds a role with the install_apps capability should not be able to exploit the vulnerability at will. For more information see Manage roles and permissions in Splunk SOAR (On-premises) ( ) and Add and configure apps and assets to provide actions in Splunk SOAR (On-premises) ( ) in the Splunk documentation.
Medium [CVE-2026-76297] Federated Search Provider State Change through Cross-Site Request Forgery (CSRF) in Splunk Web for Splunk Enterprise
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 that holds a role with the edit_federated_providers capability into turning off all federated search providers. Successful exploitation could temporarily prevent federated searches from retrieving data from remote datasets. The vulnerability is possible because the federated provider Representational State Transfer (REST) API accepts GET requests for actions that change provider state. 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 Run federated searches over remote Splunk platform deployments ( ) and Define roles on the Splunk platform with capabilities ( ) in the Splunk documentation.
Medium [CVE-2026-76296] Missing Authorization through Sourcetype Renaming in Splunk Web for Splunk Enterprise
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. For more information see Rename source types at search time ( ) in the Splunk documentation.
Medium [CVE-2026-76295] SPL Injection through the REST API in Splunk Secure Gateway
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 who does not hold the "admin" or "power" Splunk roles could view dashboard and report listings beyond the requested filter scope while remaining within objects that the user can access. The vulnerability is possible because Splunk Secure Gateway does not neutralize special characters in values before it creates filters for dashboard and report requests. For more information see About configuring role-based user access ( ) in the Splunk documentation.
Medium [CVE-2026-76294] Improper Access Control in Field Extraction Management in Splunk Enterprise
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 move field extractions or field transformations to apps for which the user does not have read access. The vulnerability is possible because the Representational State Transfer (REST) API does not validate destination app access before it processes field extraction and field transformation move operations. For more information see Use the Field extractions page ( ) and Manage knowledge object permissions ( ) in the Splunk documentation.
Medium [CVE-2026-76292] Missing Authorization through REST API Endpoints in Splunk Secure Gateway
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 low-privileged user that does not hold the "admin" Splunk role or the "sc_admin" Splunk Secure Gateway role could read mobile alert notification data for other users through Splunk Secure Gateway App Key Value Store (KV Store) Representational State Transfer (REST) API endpoints. The vulnerability is possible because the affected Splunk Secure Gateway App Key Value Store collections do not enforce user-level authorization for read requests. For more information see About the app key value store ( ) and About configuring role-based user access ( ) in the Splunk documentation.
Medium [CVE-2026-76289] Denial of Service (DoS) through the REST API in Splunk Enterprise
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 make the Splunk Enterprise instance unavailable to other users by sending a request to the Representational State Transfer (REST) API endpoint for lookup table files. The affected instance requires a restart to restore service. The vulnerability is possible because the endpoint does not limit resource use when it processes response field selections. For more information see Endpoints reference list ( ) and About configuring role-based user access ( ) in the Splunk documentation.
Medium [CVE-2026-76287] Authorization Bypass in the Data Management REST API in Splunk Enterprise
In Splunk Enterprise versions below 10.4.4, a user that holds a role with the preview_data_management_pipeline capability or edit_data_management_pipeline_job capability could read or delete Data Management SPL2 preview jobs and results outside their ownership scope. The vulnerability is possible because the Data Management Representational State Transfer (REST) API verifies the required capability but does not verify that the requested preview job belongs to the requester. The affected Data Management REST API is available only when the Edge Processor feature is turned on. The Edge Processor feature is turned off by default. For more information see Set up a data management control plane ( ) and Getting sample data for previewing data transformations ( ) in the Splunk documentation.
Medium [CVE-2026-114406] Ca-certificates: distrust emudhra intermediate ca certificates due to security concerns
The system certificate authority (CA) store in Red Hat products, distributed via ca-certificates RPM packages, included multiple root CA certificates of authorities, which signed intermediate CA certificates with weak private keys issued by the eMudhra certificate authority. A man-in-the-middle attacker could use this flaw to issue certificates for arbitrary host names signed by the weak intermediate CA certificates, which would be considered trusted by a TLS/SSL client using system CA store and cause such clients to connect to malicious sites. Due to inability to only distrust specific intermediate certificates in all clients using the system CA store, root CA certificates of authorities that signed weak intermediate CA certificates are being removed. Red Hat severity: Critical — CVSS 6.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N). Weakness: CWE-295. Affected products named by the advisory: Assisted Installer for Red Hat OpenShift Container Platform 2; cert-manager Operator for Red Hat OpenShift; Confidential Compute Attestation; Kernel Module Management Operator for Red Hat Openshift; and 26 more. Affected products named by the advisory: Kube Descheduler Operator; Logging Subsystem for Red Hat OpenShift; Logical Volume Manager Storage; Migration Toolkit for Applications 8; and 22 more.
Medium [CVE-2026-85518] Openscap: openscap: arbitrary file write via path traversal in source datastream decomposition
A flaw was found in OpenSCAP. When decomposing a Source DataStream (SDS) file, the application does not properly validate relative file path attributes, leading to a path traversal vulnerability. An attacker can exploit this flaw by tricking a user or automated system into decomposing a crafted datastream containing directory traversal sequences. Successful exploitation allows unauthorized file creation or modification outside the intended target directory with the permissions of the executing process. This vulnerability is rated as Moderate impact because exploitation requires an administrator or automated workflow to explicitly decompose a crafted, untrusted Source DataStream file. Typical OpenSCAP usage in Red Hat Enterprise Linux focuses on evaluating installed systems against verified security profiles, rather than unpacking arbitrary third-party datastreams. Furthermore, any directory creation or file overwrite resulting from path traversal is strictly bounded by the filesystem permissions of the executing process. Red Hat severity: Moderate — CVSS 6.1 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L). Weakness: CWE-22. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Hardened Images. Will not fix / out of support: Red Hat Enterprise Linux 6.
Medium [CVE-2026-114438] Keycloak-services: keycloak-services: required otp enrollment bypassed via update user locale required action ordering
A flaw was found in the Update User Locale required action of the Keycloak identity and access management solution. When this action is ordered before the Configure OTP action in a realm, the system may fail to enforce mandatory multi-factor authentication enrollment during the login process. This issue allows an attacker with a valid password to access an account without setting up the required one-time password (OTP) credential. The Red Hat Product Security team has assessed the severity of this vulnerability as Moderate, given that exploitation requires a specific and non-default configuration of required action ordering within the realm. Successful exploitation allows an attacker to bypass mandatory OTP enrollment and gain access to a user account using only a password. The vulnerability's root cause is an early exit in the required-action processing loop due to missing status returns in the Update User Locale action handlers. Weakness: CWE-287. Affected Red Hat products: Red Hat Build of Keycloak; Red Hat Single Sign-On 7. Red Hat does not currently list a fixing RHSA for this CVE.