| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect Privilege Assignment vulnerability in Dokan, Inc. Dokan dokan-lite allows Privilege Escalation.This issue affects Dokan: from n/a through <= 4.1.2. |
| Incorrect Privilege Assignment vulnerability in bPlugins Advanced scrollbar advanced-scrollbar allows Privilege Escalation.This issue affects Advanced scrollbar: from n/a through <= 1.1.8. |
| Incorrect Privilege Assignment vulnerability in Progress Planner Progress Planner progress-planner allows Privilege Escalation.This issue affects Progress Planner: from n/a through <= 1.8.0. |
| A vulnerability has been identified in Spectrum Power 4 (All versions < V4.70 SP12 Update 2). The affected application is vulnerable to a local privilege escalation due to wrongly set permissions to a binary which allows any local attacker to gain administrative privileges. |
| A vulnerability was discovered in RISC-V Rocket-Chip v1.6 and before implementation where the SRET (Supervisor-mode Exception Return) instruction fails to correctly transition the processor's privilege level. Instead of downgrading from Machine-mode (M-mode) to Supervisor-mode (S-mode) as specified by the sstatus.SPP bit, the processor incorrectly remains in M-mode, leading to a critical privilege retention vulnerability. |
| An issue in Sublime HQ Pty Ltd Sublime Text 4 4200 allows authenticated attackers with low-level privileges to escalate privileges to Administrator via replacing the uninstall file with a crafted binary in the installation folder. |
| A flaw was found in the Observability Operator. The Operator creates a ServiceAccount with *ClusterRole* upon deployment of the *Namespace-Scoped* Custom Resource MonitorStack. This issue allows an adversarial Kubernetes Account with only namespaced-level roles, for example, a tenant controlling a namespace, to create a MonitorStack in the authorized namespace and then elevate permission to the cluster level by impersonating the ServiceAccount created by the Operator, resulting in privilege escalation and other issues. |
| A vulnerability was found in Shenzhen Dashi Tongzhou Information Technology AgileBPM up to 1.0.0. It has been declared as critical. Affected by this vulnerability is the function doFilter of the file \agile-bpm-basic-master\ab-auth\ab-auth-spring-security-oauth2\src\main\java\com\dstz\auth\filter\AuthorizationTokenCheckFilter.java. The manipulation leads to improper access controls. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. |
| A flaw was found in Red Hat Openshift AI Service. The TrustyAI component is granting all service accounts and users on a cluster permissions to get, list, watch any pod in any namespace on the cluster.
TrustyAI is creating a role `trustyai-service-operator-lmeval-user-role` and a CRB `trustyai-service-operator-default-lmeval-user-rolebinding` which is being applied to `system:authenticated` making it so that every single user or service account can get a list of pods running in any namespace on the cluster
Additionally users can access all `persistentvolumeclaims` and `lmevaljobs` |
| JumpServer is an open source bastion host and an operation and maintenance security audit system. Prior to 4.8.0 and 3.10.18, an attacker with a low-privileged account can access the Kubernetes session feature and manipulate the kubeconfig file to redirect API requests to an external server controlled by the attacker. This allows the attacker to intercept and capture the Kubernetes cluster token. This can potentially allow unauthorized access to the cluster and compromise its security. This vulnerability is fixed in 4.8.0 and 3.10.18. |
| A vulnerability has been identified in Mendix OIDC SSO (Mendix 10 compatible) (All versions < V4.1.0), Mendix OIDC SSO (Mendix 10.12 compatible) (All versions < V4.0.1), Mendix OIDC SSO (Mendix 9 compatible) (All versions < V3.3.0). The Mendix OIDC SSO module grants read and write access to all tokens exclusively to the Administrator role and could result in privilege misuse by an adversary modifying the module during Mendix development. |
| A flaw was found in Quay. When an organization acts as a proxy cache, and a user or robot pulls an image that hasn't been mirrored yet, they are granted "Admin" permissions on the newly created repository. |
| A flaw was found in Red Hat Openshift AI Service. A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator. This allows for the complete compromise of the cluster's confidentiality, integrity, and availability. The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it. |
| Nagios Log Server versions prior to 2024R1.0.2 contain a local privilege escalation vulnerability that allows an attacker who could execute commands as the Apache web user (or the backend shell user) to escalate to root on the host. |
| VMware Tools contains an insecure file handling vulnerability. A malicious actor with non-administrative privileges on a guest VM may tamper the local files to trigger insecure file operations within that VM. |
| This issue was addressed by removing the vulnerable code. This issue is fixed in tvOS 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. An app may be able to elevate privileges. |
| The Restaurant Brands International (RBI) assistant platform through 2025-09-06 allows a remote authenticated attacker to obtain a token with administrative privileges for the entire platform via the createToken GraphQL mutation. |
| In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not
set-id:
---------x 1 root root 16048 Aug 7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug 7 13:16 target
it is possible to gain root privileges when execution should have been
disallowed.
While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".
Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal. |
| Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts to current_setting('role') or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected. |
| This issue was addressed with improved data protection. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7. An app may be able to hijack entitlements granted to other privileged apps. |
