Execution with Unnecessary Privileges

A local privilege escalation vulnerability exists in snap-confine, a set-capabilities core component used internally by Canonical snapd to construct the secure execution environment for snap applications. This vulnerability uniquely affects versions of snap-confine configured with set-capabilities (rather than standard set-uid-root installations). Due to a flaw in how privilege boundaries or security sandboxes are initialized when the binary runs under limited ambient capabilities, a local, unprivileged attacker can exploit this behavior to bypass intended restrictions and execute arbitrary code. Successful exploitation allows the local user to elevate their privileges to full root authority.Show less

A sandbox confinement bypass vulnerability exists in Canonical snapd within its internal execution environment compiler (snap-confine). The default seccomp security templates generated by the engine to restrict system calls do not filter or reject process operations capable of creating or manipulating file execution flags with set-user-ID attributes. Consequently, an application running within a strictly confined snap environment can successfully compile or drop binaries and apply setuid properties to them. If a compromised or malicious process inside the snap sandbox executes these generated setuid binaries, it can potentially circumvent architectural sandboxing assumptions, drop intended restriction policies, or execute privileged actions inside the container namespace that should otherwise be strictly blocked. The vulnerability has been resolved by hardening the seccomp template engine to block the execution and creation of setuid executables by sandboxed snap processes.Show less

A privilege escalation vulnerability was found in the incluster-checks tool for OpenShift. The tool creates privileged debug pods with host filesystem access in the shared default namespace, where any user with the standard edit role can exec into them and obtain root access on cluster nodes.Show less

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.Show less

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.Show less

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.Show less

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.Show less

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.Show less

Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.186, a sandbox volume reference (volumeId, which may also be a volume name) was forwarded to the runner and used to build the host bind-mount source path without confinement. A reference containing path-traversal sequences could in principle resolve the mount source outside the intended per-volume base directory. This vulnerability is fixed in 0.186.Show less

A flaw was found in the cifs-utils package where the cifs.upcall helper fails to securely drop its root privileges before looking up user information inside a user-controlled environment. A local, low privileged attacker can exploit this by using a crafted request_key payload to trick the root-owned helper into entering a custom environment (namespace) containing a malicious NSS module. This forces the system to load the attacker's controlled NSS Module and configuration, allowing them to execute arbitrary commands as the root user, elevating their privileges and fully compromising the system.Show less

IPAM is the IP address Manager for Cluster API Provider Metal3. Prior to versions 1.11.7, 1.12.4, and 1.13.0, the IPAM controller's ClusterRole granted full CRUD permissions (create, delete, get, list, patch, update, watch) on core/v1 Secrets. The controller never accesses Secrets during normal operation. If the controller pod were compromised (e.g. via supply chain attack or container escape), an attacker could leverage these excessive permissions to read, modify, or delete Secrets in the namespace, potentially exposing credentials and other sensitive data. This issue has been patched in versions 1.11.7, 1.12.4, and 1.13.0.Show less

Inappropriate implementation in Headless in Google Chrome prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)Show less

CleanWipe Removal Tool (macOS), prior to 16.0.0.65, may be susceptible to an Local Privilege Escalation vulnerability, which is a type of issue whereby an attacker with limited privilege access on an affected system can escalate their privileges to gain administrative control.Show less

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, a tenant with environments.fission.io create/update RBAC can run privileged / allowPrivilegeEscalation / dangerous-capability containers in the Fission function or builder namespace, scheduled under the executor's high-privilege service account — enabling container-sandbox escape, host filesystem and network access, and potential node- and cluster-level compromise. This issue has been patched in version 1.24.0.Show less

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, Fission builder pods were created with ServiceAccountName: fission-builder and no AutomountServiceAccountToken: false, so the kubelet auto-mounted the service-account token into every container in the pod — including the user-supplied builder image. This issue has been patched in version 1.24.0.Show less

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, before the round-1 security sweep, pkg/builder/builder.go passed Environment.spec.builder.command directly into exec.Command(...) after a strings.Fields split, with no validation of the executable path or its arguments. A user who could create or update Environment CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. /bin/sh -c '...') and execute arbitrary code in the builder pod context. This issue has been patched in version 1.23.0.Show less

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.Show less

A vulnerability has been identified in SINEC INS (All versions < V1.0 SP2 Update 6). The affected system includes a binary that is configured with the cap_dac_override capability. This capability allows the process to bypass file system permission checks, resulting in unrestricted file system access. This could allow a local attacker to escalate privileges leading to arbitrary file modification and gaining root privileges on the system.Show less