| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Starting in versions 11.3.7, 11.0.3, and 12.0RC1, it is possible to exploit a bug in XWikiRights resolution of groups to obtain privilege escalation. More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right. Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights. The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights. It's possible to work around the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it. |
| This issue was addressed by removing the vulnerable code. This issue is fixed in iOS 15.7 and iPadOS 15.7, macOS Ventura 13. An app may be able to gain elevated privileges. |
| In onCreate of NotificationAccessConfirmationActivity.java , there is a possible way to hide an app with notification access in Settings due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| In some SAP standard roles in SAP Business Planning and Consolidation - versions - SAP_BW 750, 751, 752, 753, 754, 755, 756, 757, DWCORE 200, 300, CPMBPC 810, a transaction code reserved for the customer is used. By implementing such transaction code, a malicious user may execute unauthorized transaction functionality. Under specific circumstances, a successful attack could enable an adversary to escalate their privileges to be able to read, change or delete system data. |
| A logic issue was addressed with improved state management. This issue is fixed in tvOS 16.2, macOS Monterey 12.6.2, macOS Ventura 13.1, iOS 15.7.2 and iPadOS 15.7.2, iOS 16.2 and iPadOS 16.2. An app may be able to use arbitrary entitlements. |
| An access issue existed with privileged API calls. This issue was addressed with additional restrictions. This issue is fixed in iOS 16.2 and iPadOS 16.2, tvOS 16.2, watchOS 9.2. A user may be able to elevate privileges. |
| A vulnerability has been identified in SINEC NMS (All versions >= V1.0.3 < V2.0), SINEC NMS (All versions < V1.0.3), SINEMA Server V14 (All versions). The affected software do not properly check privileges between users during the same web browser session, creating an unintended sphere of control. This could allow an authenticated low privileged user to achieve privilege escalation. |
| An attacker can pre-create the `/Applications/Google\ Drive.app/Contents/MacOS` directory which is expected to be owned by root to be owned by a non-root user. When the Drive for Desktop installer is run for the first time, it will place a binary in that directory with execute permissions and set its setuid bit. Since the attacker owns the directory, the attacker can replace the binary with a symlink, causing the installer to set the setuid bit on the symlink. When the symlink is executed, it will run with root permissions. We recommend upgrading past version 64.0 |
| Inappropriate implementation in image-burner in Google Chrome OS prior to 59.0.3071.92 allowed a local attacker to read local files via dbus-send commands to a BurnImage D-Bus endpoint. |
| An Improper Privilege Management issue was discovered in Fuji Electric Monitouch V-SFT versions prior to Version 5.4.43.0. Monitouch V-SFT is installed in a directory with weak access controls by default, which could allow an authenticated attacker with local access to escalate privileges. |
| ATutor versions 2.2.1 and earlier are vulnerable to an incorrect access control check vulnerability in the Social Application component resulting in privilege escalation. ATutor versions 2.2.1 and earlier are vulnerable to an incorrect access control check vulnerability in the Module component resulting in privilege escalation. ATutor versions 2.2.1 and earlier are vulnerable to a incorrect access control check vulnerability in the Alternative Content component resulting in privilege escalation. |
| An issue was discovered in Honeywell XL Web II controller XL1000C500 XLWebExe-2-01-00 and prior, and XLWeb 500 XLWebExe-1-02-08 and prior. A user with low privileges is able to open and change the parameters by accessing a specific URL because of Improper Privilege Management. |
| Foreman since version 1.5 is vulnerable to an incorrect authorization check due to which users with user management permission who are assigned to some organization(s) can do all operations granted by these permissions on all administrator user object outside of their scope, such as editing global admin accounts including changing their passwords. |
| systemd v233 and earlier fails to safely parse usernames starting with a numeric digit (e.g. "0day"), running the service in question with root privileges rather than the user intended. |
| An issue was discovered in Cloud Foundry Foundation cf-release versions prior to 250 and CAPI-release versions prior to 1.12.0. A user with the SpaceAuditor role is over-privileged with the ability to restage applications. This could cause application downtime if the restage fails. |
| An issue was discovered in AppArmor before 2.12. Incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to the common logic to handle 'restart' operations removing AppArmor profiles that aren't found in the typical filesystem locations, such as /etc/apparmor.d/. Userspace projects that manage their own AppArmor profiles in atypical directories, such as what's done by LXD and Docker, are affected by this flaw in the AppArmor init script logic. |
| An Improper Access Control issue was discovered in Trihedral VTScada 11.3.03 and prior. A local, non-administrator user has privileges to read and write to the file system of the target machine. |
| TeamPass before 2.1.27.9 does not properly enforce manager access control when requesting roles.queries.php. It is then possible for a manager user to modify any arbitrary roles within the application, or delete any arbitrary role. To exploit the vulnerability, an authenticated attacker must have the manager rights on the application, then tamper with the requests sent directly, for example by changing the "id" parameter when invoking "delete_role" on roles.queries.php. |
| TeamPass before 2.1.27.9 does not properly enforce item access control when requesting items.queries.php. It is then possible to copy any arbitrary item into a directory controlled by the attacker, edit any item within a read-only directory, delete an arbitrary item, delete the file attachments of an arbitrary item, copy the password of an arbitrary item to the copy/paste buffer, access the history of an arbitrary item, and edit attributes of an arbitrary directory. To exploit the vulnerability, an authenticated attacker must tamper with the requests sent directly, for example by changing the "item_id" parameter when invoking "copy_item" on items.queries.php. |
| Nagios Core through 4.3.4 initially executes /usr/sbin/nagios as root but supports configuration options in which this file is owned by a non-root account (and similarly can have nagios.cfg owned by a non-root account), which allows local users to gain privileges by leveraging access to this non-root account. |
