CVE-2026-71507: Dolibarr REST API Authorization Bypass

CVE-2026-71507 Overview

CVE-2026-71507 is a broken object-level authorization (BOLA) vulnerability in Dolibarr ERP/CRM versions before 24.0.0. The flaw exists in the REST API company bank account write routes. Authenticated attackers holding third-party creation rights can create, replace, or delete bank account details for any company in the system. The attacker does not need read access to the target company record. Exploitation lets adversaries inject attacker-controlled International Bank Account Numbers (IBANs) as creditor accounts. Dolibarr subsequently writes these IBANs into regenerated Single Euro Payments Area (SEPA) credit-transfer files, redirecting outgoing supplier payments to attacker-controlled accounts. The vulnerability is tracked under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Authenticated attackers with minimal third-party creation privileges can redirect outgoing SEPA supplier payments to bank accounts they control, causing direct financial loss.

Affected Products

Dolibarr ERP/CRM versions before 24.0.0
Dolibarr REST API endpoint POST /thirdparties/{id}/bankaccounts
Dolibarr SEPA credit-transfer file generation module

Discovery Timeline

2026-08-24 - CVE-2026-71507 published to the National Vulnerability Database (NVD)
2026-08-24 - Last updated in NVD database
Reporting credit: VulnCheck (per commit c100564d059e19c711317c734d302a90b11e2e8b)

Technical Details for CVE-2026-71507

Vulnerability Analysis

The vulnerability resides in the Dolibarr REST API, specifically in htdocs/societe/class/api_thirdparties.class.php. The company bank account write routes verify that the target third-party company exists but never validate whether the authenticated caller is authorized to access that specific company. This is a classic broken object-level authorization defect. Any authenticated user granted the general permission to create third parties can supply an arbitrary socid in the request path and modify banking details attached to any company object, including suppliers used for real payment runs. Because the bank account details feed directly into regenerated SEPA XML payment files, the impact extends beyond data tampering into financial fraud through payment redirection.

Root Cause

The root cause is a missing call to DolibarrApi::_checkAccessToResource('societe', $id) before the bank account object is instantiated and persisted. The existing $this->company->fetch($id) call only confirms that the record exists. It performs no per-object authorization. A secondary contributing factor was missing external-user protection in htdocs/api/class/api_access.class.php, where the role cache identifier was not consistently set before authorization checks executed.

Attack Vector

An attacker authenticates to the Dolibarr REST API using any account with the third-party creation right, which is a low-privilege role in most deployments. The attacker then issues a write request against the bank account route for a target socid corresponding to a legitimate supplier. The request payload contains an attacker-controlled IBAN and BIC. On the next SEPA credit-transfer generation, Dolibarr writes the malicious creditor account into the outgoing XML file. The bank processes the transfer against the substituted IBAN, sending funds to the attacker.

php

// Security patch in htdocs/societe/class/api_thirdparties.class.php
// Adds per-object authorization before writing bank account data
if ($this->company->fetch($id) <= 0) {
    throw new RestException(404, 'Error creating Company Bank account, Company doesn\'t exists');
}

if (!DolibarrApi::_checkAccessToResource('societe', $id)) {
    throw new RestException(403, 'Access not allowed for login '.DolibarrApiAccess::$user->login);
}

$account = new CompanyBankAccount($this->db);
$account->socid = $id;

Source: Dolibarr commit c100564

Detection Methods for CVE-2026-71507

Indicators of Compromise

REST API POST, PUT, or DELETE requests to /thirdparties/{id}/bankaccounts originating from user accounts that do not otherwise interact with the referenced socid.
Unexpected creation or modification of CompanyBankAccount records for supplier third parties, especially near scheduled SEPA run times.
SEPA credit-transfer XML files containing creditor IBANs that do not match the historical supplier IBAN for the same socid.
Dolibarr audit log entries showing bank account writes by users holding only the third-party creation right.

Detection Strategies

Diff generated SEPA credit-transfer files against the previous run and alert on any creditor IBAN change per supplier.
Correlate Dolibarr application logs with web server access logs to identify low-privilege API tokens writing to bank account routes across multiple socid values.
Baseline which user accounts legitimately manage supplier banking data and alert when other accounts issue writes to the same endpoint.

Monitoring Recommendations

Forward Dolibarr application, database, and reverse-proxy logs to a centralized SIEM for correlation of API activity with payment file generation events.
Monitor for HTTP 200 responses on POST /thirdparties/{id}/bankaccounts from accounts flagged as low-privilege third-party creators.
Track file integrity for the SEPA output directory and alert on IBAN field changes between generations.

How to Mitigate CVE-2026-71507

Immediate Actions Required

Upgrade Dolibarr to version 24.0.0 or later, which includes commit c100564d059e19c711317c734d302a90b11e2e8b enforcing per-object authorization on bank account routes.
Review all Dolibarr user accounts and API tokens holding the third-party creation right and revoke privileges that are not operationally required.
Audit CompanyBankAccount records and pending SEPA credit-transfer files for unauthorized IBAN changes since the last known-good state.

Patch Information

The fix is included in Dolibarr Release 24.0.0. The relevant code change is documented in the upstream commit and reproduced in the technical analysis above. Additional context is available in the VulnCheck advisory and the Codeant AI security research writeup.

Workarounds

Restrict access to the Dolibarr REST API using a reverse proxy allowlist while the upgrade is scheduled.
Disable the third-party creation permission for API-only service accounts and delegate supplier onboarding to interactive users with additional oversight.
Implement an out-of-band verification step comparing generated SEPA creditor IBANs against a signed supplier reference list before file submission to the bank.

bash

# Verify Dolibarr version and confirm patched build
php -r "require('/var/www/dolibarr/htdocs/filefunc.inc.php'); echo DOL_VERSION;"

# Quick check: list bank account modifications in the last 7 days
mysql -u dolibarr -p dolibarr -e \
  "SELECT rowid, fk_soc, iban_prefix, tms FROM llx_societe_rib \
   WHERE tms > (NOW() - INTERVAL 7 DAY) ORDER BY tms DESC;"