CVE-2026-71507 in Dolibarr
Summary
by MITRE • 08/24/2026
Dolibarr before 24.0.0 contains a broken object-level authorization vulnerability in the REST API company bank account write routes that allows authenticated attackers with third-party creation rights to create, replace, or delete bank account details of any company without requiring read access to that company. Attackers can inject attacker-controlled IBANs as creditor accounts, which are then written into regenerated SEPA credit-transfer files, redirecting outgoing payments to attacker-controlled accounts.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Dolibarr versions prior to 24.0.0 represents a critical failure in object-level authorization controls within the application's REST API architecture. Specifically, this flaw affects the endpoints responsible for managing company bank account information through write operations such as creation, replacement, and deletion. The core technical deficiency lies in the insufficient validation of user permissions relative to the specific resource being modified. While the system correctly enforces access control policies that require third-party creation rights for general interactions with business entities, it fails to verify whether the authenticated user possesses read or administrative privileges over the particular company whose bank account details are being altered. This discrepancy allows an attacker who has been granted broad permissions to create new third parties in the system to exploit these elevated write capabilities against existing companies that they do not own and cannot otherwise access.
From a technical perspective, this is a classic example of Insecure Direct Object Reference (IDOR) combined with Broken Access Control at the object level. The application logic assumes that if a user has permission to create entities within a certain domain, they should have unrestricted write access to all related sub-objects across all existing instances in that domain. This assumption ignores the principle of least privilege and fails to implement proper ownership checks or role-based access control (RBAC) validations for individual resource modifications. Consequently, an authenticated attacker can manipulate the internal identifiers associated with third-party companies to target bank account records belonging to unrelated organizations within the same Dolibarr instance.
The operational impact of this vulnerability is severe due to its direct implication on financial integrity and data confidentiality. By exploiting this flaw, attackers can inject malicious International Bank Account Numbers (IBANs) into the system as creditor accounts for any company in the database. These injected details are not merely cosmetic; they are actively utilized by Dolibarr when generating SEPA credit-transfer files, which are standard electronic payment formats used extensively across Europe and beyond. When these regenerated files are processed by banking institutions or internal accounting systems, outgoing payments intended for legitimate vendors or partners are redirected to bank accounts controlled by the attacker. This constitutes a direct financial theft vector that can result in significant monetary loss for organizations relying on automated payment processing workflows.
This vulnerability aligns with several recognized industry standards and threat models. It is categorized under CWE-284, which covers Improper Access Control, specifically highlighting failures where access control decisions do not properly enforce the intended security policy regarding specific objects. Furthermore, in the context of the MITRE ATT&CK framework, this behavior maps to T1530 Data from Information Repositories and potentially T1567 Exfiltration Over Web Service if the attacker retrieves sensitive data before or after modifying it. The attack path also reflects aspects of CWE-862 Missing Authorization, as the application does not enforce proper authorization for a specific action on a specific resource.
Mitigation strategies must focus on immediate patching and architectural review. Organizations running Dolibarr versions earlier than 24.0.0 should upgrade to version 24.0.0 or later immediately, where this access control logic has been corrected to enforce strict ownership verification for bank account modifications. In the interim, if upgrading is not feasible, administrators should restrict REST API access to only those users who absolutely require it and ensure that third-party creation rights are granted with extreme caution. Implementing additional monitoring on SEPA file generation processes can help detect anomalous changes in creditor accounts. Long-term remediation involves conducting a comprehensive audit of all REST API endpoints to ensure consistent enforcement of object-level permissions, ensuring that write operations always validate the user's relationship to the specific target resource rather than relying solely on broad role-based privileges.