B1i module of SAP Business One - version 10.0, application allows an authenticated user with deep knowledge to send crafted queries over the network to read or modify the SQL data. On successful exploitation, the attacker can cause high impact on confidentiality, integrity and availability of the application.

SAP Disclosure Management, version 10.1, does not perform necessary authorization checks for an authenticated user, allowing access to administration accounts by a user with no roles, leading to Missing Authorization Check.

SAP GRC Access control Emergency Access Management allows an authenticated attacker to access a Firefighter session even after it is closed in Firefighter Logon Pad. This attack can be launched only within the firewall. On successful exploitation the attacker can gain access to admin session and completely compromise the application.

The ACL (Access Control List) of SAP Message Server - versions KERNEL 7.22, KERNEL 7.53, KERNEL 7.54, KERNEL 7.77, RNL64UC 7.22, RNL64UC 7.22EXT, RNL64UC 7.53, KRNL64NUC 7.22, KRNL64NUC 7.22EXT, can be bypassed in certain conditions, which may enable an authenticated malicious user to enter the network of the SAP systems served by the attacked SAP Message server. This may lead to unauthorized read and write of data as well as rendering the system unavailable.

SAP Landscape Management, version 3.0, and SAP Adaptive Extensions, version 1.0, allows an attacker with admin_group privileges to change ownership and permissions (including S-user ID bit s-bit) of arbitrary files remotely. This results in the possibility to execute these files as root user from a non-root context, leading to Privilege Escalation.

A highly privileged user can exploit SUID-root program to escalate his privileges to root on a local Unix system.

In some SAP standard roles, in SAP_ABA versions, 7.00 to 7.02, 7.10 to 7.11, 7.30, 7.31, 7.40, 7.50, 75C to 75D, a transaction code reserved for customer is used. By implementing such transaction code a malicious user may execute unauthorized transaction functionality.

Due to misconfigured application endpoints, SAP SuccessFactors attachment APIs allow attackers with user privileges to perform activities with admin privileges over the network. These APIs were consumed in the SF Mobile application for Time Off, Time Sheet, EC Workflow, and Benefits. On successful exploitation, the attacker can read/write attachments. Thus, compromising the confidentiality and integrity of the application

SAP startservice - of SAP NetWeaver Application Server ABAP, Application Server Java, ABAP Platform and HANA Database - versions KERNEL 7.22, 7.49, 7.53, 7.77, 7.81, 7.85, 7.86, 7.87, 7.88, KRNL64NUC 7.22, 7.22EXT, 7.49, KRNL64UC 7.22, 7.22EXT, 7.49, 7.53, SAPHOSTAGENT 7.22, - on Unix systems, s-bit helper program sapuxuserchk, can be abused physically resulting in a privilege escalation of an attacker leading to low impact on confidentiality and integrity, but a profound impact on availability.

Under certain conditions, it is possible to request the modification of role or privilege assignments through SAP Identity Management REST Interface Version 2, which would otherwise be restricted only for viewing.

Under certain conditions, SAP BusinessObjects Business Intelligence Platform (SAPUI5), versions - 420, 430, can allow an unauthenticated attacker to redirect users to a malicious site due to Reverse Tabnabbing vulnerabilities.

Active Directory Domain Services Elevation of Privilege Vulnerability

GLPI, which stands for Gestionnaire Libre de Parc Informatique, is a Free Asset and IT Management Software package, that provides ITIL Service Desk features, licenses tracking and software auditing. In versions 10.0.0 to before 10.0.19, a connected user without administration rights can change the rules execution order. This issue has been patched in version 10.0.19.

Active Directory Domain Services Elevation of Privilege Vulnerability

An Improper Privilege Management vulnerability in the gRPC framework, used by the Juniper Extension Toolkit (JET) API on Juniper Networks Junos OS and Junos OS Evolved, allows a network-based, low-privileged authenticated attacker to perform operations as root, leading to complete compromise of the targeted system. The issue is caused by the JET service daemon (jsd) process authenticating the user, then passing configuration operations directly to the management daemon (mgd) process, which runs as root. This issue affects Juniper Networks Junos OS: 18.4 versions prior to 18.4R1-S8, 18.4R2-S8, 18.4R3-S8; 19.1 versions prior to 19.1R2-S3, 19.1R3-S5; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2. This issue does not affect Juniper Networks Junos OS versions prior to 18.4R1. Juniper Networks Junos OS Evolved: All versions prior to 20.4R2-EVO; 21.1-EVO versions prior to 21.1R2-EVO.

An authenticated XCC user can change permissions for any user through a crafted API command.

By leveraging the vulnerability, lower-privileged users of Content Manager can manipulate Content Manager clients to elevate privileges and perform unauthorized operations.

Improper Privilege Management vulnerability in Pandora FMS on all allows Privilege Escalation. This vulnerability allows an unauthorised user to escalate and read sensitive files as if they were root. This issue affects Pandora FMS: from 700 through 773.

SchedMD Slurm before 18.08.9 and 19.x before 19.05.5 executes srun --uid with incorrect privileges.

The samldb_check_user_account_control_acl function in dsdb/samdb/ldb_modules/samldb.c in Samba 4.x before 4.1.22, 4.2.x before 4.2.7, and 4.3.x before 4.3.3 does not properly check for administrative privileges during creation of machine accounts, which allows remote authenticated users to bypass intended access restrictions by leveraging the existence of a domain with both a Samba DC and a Windows DC, a similar issue to CVE-2015-2535.

Dell PowerScale OneFS, versions 8.2.2.x-9.5.0.x, contains an improper privilege management vulnerability. A remote attacker with low privileges could potentially exploit this vulnerability, leading to escalation of privileges.

A privilege escalation vulnerability exists in the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x. The use of the deprecated API `process.binding()` can bypass the policy mechanism by requiring internal modules and eventually take advantage of `process.binding('spawn_sync')` run arbitrary code, outside of the limits defined in a `policy.json` file. Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.

vaultwarden is an unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. In affected versions an attacker is capable of updating or deleting groups from an organization given a few conditions: 1. The attacker has a user account in the server. 2. The attacker's account has admin or owner permissions in an unrelated organization. 3. The attacker knows the target organization's UUID and the target group's UUID. Note that this vulnerability is related to group functionality and as such is only applicable for servers who have enabled the `ORG_GROUPS_ENABLED` setting, which is disabled by default. This attack can lead to different situations: 1. Denial of service, the attacker can limit users from accessing the organization's data by removing their membership from the group. 2. Privilege escalation, if the attacker is part of the victim organization, they can escalate their own privileges by joining a group they wouldn't normally have access to. For attackers that aren't part of the organization, this shouldn't lead to any possible plain-text data exfiltration as all the data is encrypted client side. This vulnerability is patched in Vaultwarden `1.32.7`, and users are recommended to update as soon as possible. If it's not possible to update to `1.32.7`, some possible workarounds are: 1. Disabling `ORG_GROUPS_ENABLED`, which would disable groups functionality on the server. 2. Disabling `SIGNUPS_ALLOWED`, which would not allow an attacker to create new accounts on the server.