| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The issue was resolved by sanitizing logging. This issue is fixed in macOS Sequoia 15.2. An app may be able to access user-sensitive data. |
| This issue was addressed with improved validation of symlinks. This issue is fixed in macOS Sequoia 15.1. An app may be able to access user-sensitive data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. An app may be able to access user-sensitive data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. A non-privileged user may be able to modify restricted network settings. |
| The issue was addressed with additional permissions checks. This issue is fixed in macOS Sequoia 15.3. An app may be able to access protected user data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. An app may be able to access protected user data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. An app may be able to access a user's Photos Library. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. An app may be able to access protected user data. |
| This issue was addressed through improved state management. This issue is fixed in macOS Sequoia 15.1. An attacker with physical access to a Mac may be able to view protected content from the Login Window. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15. A camera extension may be able to access the internet. |
| A logic issue was addressed with improved state management. This issue is fixed in macOS Sequoia 15.2. An app may be able to elevate privileges. |
| A potential security vulnerability has been identified in the HP Support Assistant for versions prior to 9.44.18.0. The vulnerability could potentially allow a local attacker to escalate privileges via an arbitrary file write. |
| In multiple functions of GrantPermissionsActivity.java , there is a possible way to trick the user into granting the incorrect permission due to permission overload. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| A flaw in Node.js’s Permissions model allows attackers to bypass `--allow-fs-read` and `--allow-fs-write` restrictions using crafted relative symlink paths. By chaining directories and symlinks, a script granted access only to the current directory can escape the allowed path and read sensitive files. This breaks the expected isolation guarantees and enables arbitrary file read/write, leading to potential system compromise.
This vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25. |
| <p>A security feature bypass vulnerability exists when Microsoft Windows fails to handle file creation permissions, which could allow an attacker to create files in a protected Unified Extensible Firmware Interface (UEFI) location.</p>
<p>To exploit this vulnerability, an attacker could run a specially crafted application to bypass Unified Extensible Firmware Interface (UEFI) variable security in Windows.</p>
<p>The security update addresses the vulnerability by correcting security feature behavior to enforce permissions.</p> |
| Under rare conditions, the effective permissions of an object might be incorrectly calculated if the object has a specific configuration of metadata-driven permissions in M-Files Server versions 23.9, 23.10, and 23.11 before 23.11.13168.7, potentially enabling unauthorized access to the object. |
| A vulnerability exists in Quick Heal Total Security 23.0.0 in the quarantine management component where insufficient validation of restore paths and improper permission handling allow a low-privileged local user to restore quarantined files into protected system directories. This behavior can be abused by a local attacker to place files in high-privilege locations, potentially leading to privilege escalation. |
| A flaw in Node.js's permission model allows a file's access and modification timestamps to be changed via `futimes()` even when the process has only read permissions. Unlike `utimes()`, `futimes()` does not apply the expected write-permission checks, which means file metadata can be modified in read-only directories. This behavior could be used to alter timestamps in ways that obscure activity, reducing the reliability of logs. This vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25. |
| Grafana is an open-source platform for monitoring and observability. In versions prior to 8.5.13, 9.0.9, and 9.1.6, Grafana is subject to Improper Preservation of Permissions resulting in privilege escalation on some folders where Admin is the only used permission. The vulnerability impacts Grafana instances where RBAC was disabled and enabled afterwards, as the migrations which are translating legacy folder permissions to RBAC permissions do not account for the scenario where the only user permission in the folder is Admin, as a result RBAC adds permissions for Editors and Viewers which allow them to edit and view folders accordingly. This issue has been patched in versions 8.5.13, 9.0.9, and 9.1.6. A workaround when the impacted folder/dashboard is known is to remove the additional permissions manually. |
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. |
