| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A potential vulnerability was reported in Lenovo App Store, distributed exclusively in the Chinese market, that could allow a local authenticated user to execute arbitrary code with elevated privileges. |
| When applying replicated changes for a row that is missing one or more columns, pglogical evaluates the affected table's default expressions on the subscriber. Because the apply worker runs at a privilege level equivalent to a PostgreSQL superuser in default installations, any function invoked by such a default expression also runs at that privilege. A party acting as the publisher can use this path to cause functions to be executed on the subscriber as superuser, escalating from a role permitted to use pglogical to full superuser.
This is a second, independent path to the same superuser escalation tracked under CVE-2026-50736 (the pglogical queue issue). To exploit the issue an attacker must be able to direct a subscription at an endpoint they control. In default installations this requires privileges normally reserved for a superuser, so the issue is most relevant to managed deployments where the ability to create subscriptions has been delegated to non-superuser roles. |
| The Analog Way Picturall Quad Compact Mark II version 3.5.8, contains a local privilege escalation vulnerability in the core firmware. This is due to improper privilege delegation and insufficient input validation in a maintenance script. |
| 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. |
| A memory corruption issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8. An app may be able to disclose kernel memory. |
| In versions before 7.0.0.64, IDrive’s id_service.exe process runs with elevated privileges and regularly reads from several files under the C:\ProgramData\IDrive\ directory. The UTF16-LE encoded contents of these files are used as arguments for starting a process, but they can be edited by any standard user logged into the system. An attacker can overwrite or edit the files to specify a path to an arbitrary executable, which will then be executed by the id_service.exe process with SYSTEM privileges. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for ADS I/O
Alternate data streams are stored as xattrs. Unlike regular file I/O,
their read and write paths therefore call VFS xattr helpers which recheck
inode permissions and LSM policy using the current task credentials.
Run ADS I/O with the credentials captured when the SMB handle was opened. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE
The FSCTL_DUPLICATE_EXTENTS_TO_FILE arm of smb2_ioctl() overwrites the
destination file's data via vfs_clone_file_range() with neither the
share-level KSMBD_TREE_CONN_FLAG_WRITABLE check nor a per-handle
fp->daccess check that the other write-bearing arms carry. A client can
overwrite destination data on a read-only share, or from a handle opened
with only FILE_WRITE_ATTRIBUTES (which still yields an FMODE_WRITE filp).
FILE_WRITE_ATTRIBUTES-only destination handle overwrote the file's data via
the clone. Add both checks, matching the FSCTL_SET_SPARSE permission fix;
require FILE_WRITE_DATA since this writes data. |
| Rapid7 InsightVM, Nexpose, and the Insight Agent execute discovered executables during authenticated assessment without validating file ownership, allowing a local low-privileged user to run code as the scan credential (Scan Engine) or as root/SYSTEM (Insight Agent). Fixed in Scan Engine content 1.1.3935 and Insight Agent content component 0.0.245.0. |
| 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. |
| 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. |
| 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. |
| [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. |
| [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. |
| [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. |
| [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. |
| [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. |
| A Local Privilege Escalation (LPE) vulnerability was found in libblockdev. Generally, the "allow_active" setting in Polkit permits a physically present user to take certain actions based on the session type. Due to the way libblockdev interacts with the udisks daemon, an "allow_active" user on a system may be able escalate to full root privileges on the target host. Normally, udisks mounts user-provided filesystem images with security flags like nosuid and nodev to prevent privilege escalation. However, a local attacker can create a specially crafted XFS image containing a SUID-root shell, then trick udisks into resizing it. This mounts their malicious filesystem with root privileges, allowing them to execute their SUID-root shell and gain complete control of the system. |
| 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. |
| When the Strimzi cluster operator is deployed with watchAnyNamespace=true (or a multi-namespace list), any namespace editor can set Kafka.spec.entityOperator.userOperator.watchedNamespace (or topicOperator.watchedNamespace) to an arbitrary namespace. The cluster operator then creates a Role granting full CRUD on Secrets in the target namespace and a RoleBinding pointing to a ServiceAccount in the attacker's namespace — effectively granting cluster-admin-equivalent access via kube-system secret exfiltration. The RBAC objects created cross-namespace have their ownerReferences deliberately stripped, making the privilege grant persistent even after the Kafka CR or attacker namespace is deleted. Fixed in Strimzi 1.0.1 and 1.1.0 by adding a dedicated environment variable to explicitly enable the watched namespace feature (disabled by default). |
