An authenticated Redis session could be used to obtain full root access to all servers in the CVX cluster. Note that this would require an attacker to have both network access to the Redis service on a CVX server and the Redis password. Please note that all Redis communication, including authentication, occurs over plaintext in the present day. TLS support is tracked under RFE1294850.

On affected modular platforms running Arista EOS equipped with both redundant supervisor modules and having the redundancy protocol configured with RPR or SSO, an existing unprivileged user can login to the standby supervisor as a root user, leading to a privilege escalation. Valid user credentials are required in order to exploit this vulnerability.

On Arista CloudVision systems (virtual or physical on-premise deployments), Zero Touch Provisioning can be used to gain admin privileges on the CloudVision system, with more permissions than necessary, which can be used to query or manipulate system state for devices under management. Note that CloudVision as-a-Service is not affected.

Local Path Provisioner provides a way for the Kubernetes users to utilize the local storage in each node. Prior to 0.0.36, a malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner. The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template. When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted. This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node. This vulnerability is fixed in 0.0.36.

A vulnerability in the SOAP API of Cisco IoT Field Network Director (FND) could allow an authenticated, remote attacker to access and modify information on devices that belong to a different domain. The vulnerability is due to insufficient authorization in the SOAP API. An attacker could exploit this vulnerability by sending SOAP API requests to affected devices for devices that are outside their authorized domain. A successful exploit could allow the attacker to access and modify information on devices that belong to a different domain.

A vulnerability in Cisco Webex Teams, formerly Cisco Spark, could allow an authenticated, remote attacker to view and modify data for an organization other than their own organization. The vulnerability exists because the affected software performs insufficient checks for associations between user accounts and organization accounts. An attacker who has administrator or compliance officer privileges for one organization account could exploit this vulnerability by using those privileges to view and modify data for another organization account. No customer data was impacted by this vulnerability.

In BIG-IP Versions 16.1.x before 16.1.3, 15.1.x before 15.1.5.1, 14.1.x before 14.1.5, and all versions of 13.1.x, when running in Appliance mode, an authenticated user assigned the Administrator role may be able to bypass Appliance mode restrictions, using an undisclosed iControl REST endpoint. A successful exploit can allow the attacker to cross a security boundary. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

OpenObserve is a cloud-native observability platform. A vulnerability in the user management endpoint `/api/{org_id}/users/{email_id}` allows an "Admin" role user to remove a "Root" user from the organization. This violates the intended privilege hierarchy, enabling a non-root user to remove the highest-privileged account. Due to insufficient role checks, the `remove_user_from_org` function does not prevent an "Admin" user from removing a "Root" user. As a result, an attacker with an "Admin" role can remove critical "Root" users, potentially gaining effective full control by eliminating the highest-privileged accounts. The `DELETE /api/{org_id}/users/{email_id}` endpoint is affected. This issue has been addressed in release version `0.14.1` and all users are advised to upgrade. There are no known workarounds for this vulnerability.