CVE-2026-71508 in Dolibarr
Summary
by MITRE • 08/24/2026
Dolibarr before 24.0.0 contains an improper authorization vulnerability in the user REST API update endpoint that allows attackers with user-write rights to modify payroll fields by exploiting an incomplete credential denylist that omits payroll columns. Attackers can rewrite salary, bonus, hourly rate, daily rate, and weekly hours for any user without holding payroll rights, with the modified values appearing in payroll export reports.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Dolibarr versions prior to 24.0.0 represents a critical failure in access control mechanisms within its REST API implementation. Specifically, this flaw resides in the endpoint responsible for updating user profiles via HTTP PUT or PATCH requests. The core issue stems from an incomplete denylist used by the application logic to filter out sensitive fields during mass assignment operations. While the developers attempted to restrict write access to certain administrative data points by maintaining a list of prohibited columns, they inadvertently omitted payroll-related attributes from this exclusion list. This oversight creates a significant gap in authorization enforcement, allowing any authenticated user possessing standard write permissions on user profiles to bypass intended security boundaries and manipulate financial compensation data that should be restricted to users with specific payroll management privileges.
From a technical perspective, the vulnerability exploits the principle of mass assignment where input parameters are mapped directly to object properties without sufficient validation against the caller's role or permission set. In this scenario, an attacker can inject values for fields such as salary, bonus amounts, hourly rates, daily rates, and weekly working hours into the user update request. Because these specific field names were not included in the server-side denylist, the application processes them as valid updates to the underlying database records. This behavior violates the principle of least privilege, which dictates that users should only have access to resources necessary for their designated role. The lack of explicit authorization checks for payroll-specific fields means that the system trusts the input data structure more than it verifies the intent and authority of the requesting user.
The operational impact of this vulnerability is severe due to its direct effect on financial records and human resource integrity. An attacker with basic write access can arbitrarily alter compensation details for any other user within the organization. These modifications are not merely cosmetic; they propagate into payroll export reports, potentially leading to incorrect salary disbursements if integrated directly with payment processing systems. Beyond immediate financial loss or fraud risk, this manipulation undermines data integrity and auditability. It allows malicious actors to frame colleagues by inflating their salaries for fraudulent claims or defaming them by altering records in ways that trigger internal audits or compliance violations. The ability to modify these fields without detection highlights a systemic weakness in how sensitive business logic is decoupled from general user management functions.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where an actor obtains privileges they are not entitled to through flawed access control lists or permission checks. Furthermore, it maps to the MITRE ATT&CK technique T1078, Valid Accounts, as exploitation relies on legitimate credentials that have been granted insufficiently scoped permissions. The attack vector is classified under Remote Code Execution via API endpoints, though in this context, it manifests more accurately as Data Manipulation through an unauthenticated or improperly authorized interface action. To mitigate this risk, organizations must upgrade to Dolibarr version 24.0.0 or later where the denylist has been corrected to include all payroll-related columns. Additionally, implementing strict role-based access control (RBAC) that explicitly validates user permissions against every field being updated in API requests is essential. Security teams should also enforce input validation at both the application and database levels to ensure that sensitive financial fields are immutable unless accessed by processes running with elevated privileges specifically designated for payroll administration.