| Название | dolibarr software * Privilege Bypass Allows Any User to Delete Admin Accounts |
|---|
| Описание | Severity
Base Score: 9.0 (Critical)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Discovered by: Abderrahmane Aksoum
Summary
Dolibarr ERP/CRM enforces an admin-status check when a user attempts to disable another user account, correctly blocking the action with the error OnlyAdminUsersCanDisableAdminUsers when the target is an administrator. However, this same check is not applied to the delete action. As a result, any user holding only the standard, non-admin permission "Supprimer ou désactiver les autres utilisateurs" ("Delete or disable other users") can delete the SuperAdmin account by directly manipulating the id parameter of the delete request even though the UI does not expose a delete option for admin accounts to non-admin users, and even though the equivalent disable action is properly blocked.
Steps to Reproduce
Log in as a low-privileged user (test) that has the permission "Supprimer ou désactiver les autres utilisateurs" enabled and no other admin-related rights (confirmed via user/perms.php?id=).
Navigate to a user this account is permitted to manage and click Désactiver (Disable).
Intercept the request in Burp Suite:
GET /dolibarr/htdocs/user/card.php?id=<target_id>&action=confirm_disable&confirm=yes&token=<csrf_token>
Change the id parameter to the ID of the SuperAdmin/admin account and forward the request.
Observed result: The application correctly blocks the action and displays:
The application correctly blocks the action and displays: OnlyAdminUsersCanDisableAdminUsers
.Now we repeat the same process, but this time trigger a Delete action instead Disable with the same low privilege user(test account)
GET /dolibarr/htdocs/user/card.php?id=<own_permitted_id>&action=confirm_delete&confirm=yes&token=<csrf_token>
Intercept the request and change the id parameter to the SuperAdmin account's ID
Observed result: Enregistrement supprimé
The SuperAdmin account is deleted, confirmed by its absence from the user list (user/list.php) and backend response
Root Cause
The delete-confirmation handler for user accounts in user/card.php (triggered by action=confirm_delete) does not perform the same administrator-privilege check that the disable-confirmation handler (action=confirm_disable) performs. The disable path explicitly verifies whether the target user is an admin ($object->admin) and rejects the action if the acting user is not also an admin. The delete path only checks that the acting user holds the generic "delete other users" permission, and proceeds regardless of the target's admin status.
(Exact function/line reference should be confirmed against the Dolibarr source for version 23.0.3 recommend grepping for OnlyAdminUsersCanDisableAdminUsers in user/card.php to locate the check, then inspecting the sibling delete-handling block for the missing equivalent condition.)
Impact
Availability / Integrity — Critical: A non-admin user with a narrow, commonly-granted permission can delete the sole administrator account of a Dolibarr instance, causing loss of administrative access to the application.
Privilege escalation potential: Depending on configuration, removal of the admin account combined with self-registration or account-creation flows could allow an attacker to reintroduce a new account under their control with the freed-up login/id, though this was not tested and would need separate verification.
Severity: Critical — the action requires no special access beyond a permission commonly assigned to junior HR/IT staff, is not blocked or validated against the target's admin status in any way, and results in immediate loss of administrative control over the application.
Suggested Fix
Apply the same admin-status validation used in the disable handler to the delete handler in user/card.php, e.g.:
phpif ($object->admin && !$user->admin) {
setEventMessages($langs->trans("OnlyAdminUsersCanDeleteAdminUsers"), null, 'errors');
// block deletion
}
A video PoC is attached, demonstrating the vulnerability step by step:
https://drive.google.com/file/d/1mgjzyaHPuoxDOrbvNGB4kVriLqFVTKdS/view
Credit
This vulnerability was discovered and reported by: Aksoum Abderrahmane
vulnerability in github issues step by step:
https://github.com/Dolibarr/dolibarr/issues/39053
fix commit with my name credit
https://github.com/Dolibarr/dolibarr/commit/8efa16020fd3d04b633e2224161ad597a41227cb
|
|---|
| Источник | ⚠️ https://github.com/Dolibarr/dolibarr/issues/39053 |
|---|
| Пользователь | Abderrahmane Aksoum (UID 97571) |
|---|
| Представление | 06.07.2026 12:21 (2 месяцы назад) |
|---|
| Модерация | 21.08.2026 07:46 (2 months later) |
|---|
| Статус | принято |
|---|
| Запись VulDB | 394034 [Dolibarr до 23.0.4 Account htdocs/user/card.php ИД эскалация привилегий] |
|---|
| Баллы | 20 |
|---|