In GLPI from version 9.1 and before version 9.4.6, any API user with READ right on User itemtype will have access to full list of users when querying apirest.php/User. The response contains: - All api_tokens which can be used to do privileges escalations or read/update/delete data normally non accessible to the current user. - All personal_tokens can display another users planning. Exploiting this vulnerability requires the api to be enabled, a technician account. It can be mitigated by adding an application token. This is fixed in version 9.4.6.

GLPI through 9.4.3 is prone to account takeover by abusing the ajax/autocompletion.php autocompletion feature. The lack of correct validation leads to recovery of the token generated via the password reset functionality, and thus an authenticated attacker can set an arbitrary password for any user. This vulnerability can be exploited to take control of admin account. This vulnerability could be also abused to obtain other sensitive fields like API keys or password hashes.

An issue was discovered in GLPI before 9.4.1. After a successful password reset by a user, it is possible to change that user's password again during the next 24 hours without any information except the associated email address.

inc/user.class.php in GLPI before 9.4.3 allows XSS via a user picture.

Teclib GLPI before 9.4.1.1 is affected by a timing attack associated with a cookie.

An issue was discovered in GLPI through 9.2.1. The application is affected by XSS in the query string to front/preference.php. An attacker is able to create a malicious URL that, if opened by an authenticated user with debug privilege, will execute JavaScript code supplied by the attacker. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

A remote code execution issue was discovered in GLPI through 9.2.1. There is a race condition that allows temporary access to an uploaded executable file that will be disallowed. The application allows an authenticated user to upload a file when he/she creates a new ticket via front/fileupload.php. This feature is protected using different types of security features like the check on the file's extension. However, the application uploads and creates a file, though this file is not allowed, and then deletes the file in the uploadFiles method in inc/glpiuploaderhandler.class.php.

SQL injection exists in front/devicesoundcard.php in GLPI before 9.1.5 via the start parameter.

front/backup.php in GLPI before 9.1.5 allows remote authenticated administrators to delete arbitrary files via a crafted file parameter.

GLPI before 9.1.5.1 has SQL Injection in the condition rule field, exploitable via front/rulesengine.test.php.

GLPI before 9.1.5.1 has SQL Injection in the $crit variable in inc/computer_softwareversion.class.php, exploitable via ajax/common.tabs.php.

GLPI before 9.1.5 allows SQL injection via an ajax/getDropdownValue.php request with an entity_restrict parameter that is not a list of integers.