CVE-2026-71505: Dolibarr REST API Auth Bypass Vulnerability

CVE-2026-71505 Overview

CVE-2026-71505 is a broken object-level authorization (BOLA) vulnerability in Dolibarr ERP/CRM versions before 24.0.0. The flaw resides in the REST API third-party site account write routes, where per-object access checks are enforced only on read routes. Authenticated attackers holding third-party creation rights can overwrite the WebPortal password of any company by targeting the write endpoint. After replacing the credentials, the attacker authenticates as the victim company to access invoice data and retrieves the previous password verifier returned in the API response. The issue is tracked under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Authenticated attackers with third-party creation rights can take over any company's WebPortal account and access confidential invoice data.

Affected Products

Dolibarr ERP/CRM versions prior to 24.0.0
REST API endpoint api_thirdparties.class.php third-party site account write routes
Deployments exposing the Dolibarr REST API to authenticated users with third-party creation rights

Discovery Timeline

Vulnerability reported by VulnCheck to the Dolibarr project
2026-08-24 - CVE-2026-71505 published to NVD
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-71505

Vulnerability Analysis

Dolibarr exposes REST API routes for managing third-party WebPortal site accounts. Read routes correctly invoke DolibarrApi::_checkAccessToResource('societe', $id) to enforce per-object authorization. The equivalent write routes omit this check. As a result, an authenticated user with generic third-party creation rights can modify site account records belonging to companies they do not own.

The write route accepts a target $id and $site value, then executes a SQL update against societe_account without validating whether the caller is authorized for that specific fk_soc. Attackers can overwrite the WebPortal password field, effectively hijacking the portal login for the targeted company.

Compounding the impact, the API response returns the previous password verifier stored on the record. This exposure enables offline cracking of the original credential in addition to the immediate account takeover.

Root Cause

The root cause is inconsistent enforcement of object-level authorization across the REST controller. Access checks are gated on read paths but absent on write paths handling the same resource identifier. This is a classic instance of CWE-639 where authorization decisions rely on a user-supplied key without validating ownership.

Attack Vector

Exploitation requires an authenticated Dolibarr API user holding third-party creation rights. The attacker issues a write request against the third-party site account endpoint with a victim company's $id and a new password. The server persists the change without verifying resource ownership. The attacker then authenticates against the WebPortal as the victim company and pivots to invoice data.

php

// Security patch: adds per-object authorization check on the write route
// File: htdocs/societe/class/api_thirdparties.class.php
            throw new RestException(403);
        }

+       if (!DolibarrApi::_checkAccessToResource('societe', $id)) {
+           throw new RestException(403, 'Access not allowed for login '.DolibarrApiAccess::$user->login);
+       }
+
        $sql = "SELECT rowid, fk_user_creat, date_creation FROM ".MAIN_DB_PREFIX."societe_account WHERE fk_soc = ".((int) $id)." AND site = '".$this->db->escape($site)."'";
        $result = $this->db->query($sql);

Source: Dolibarr commit 4cf305e

Detection Methods for CVE-2026-71505

Indicators of Compromise

REST API PUT/POST requests to third-party site account routes referencing fk_soc values not owned by the calling API user
Unexpected updates to rows in the societe_account table where pass_crypted changes without a corresponding portal-side password reset
WebPortal authentication events for a company immediately following an API write from a low-privileged user account
API responses containing prior password verifier values returned to non-owner callers

Detection Strategies

Compare the API caller identity against the fk_user_creat and fk_soc owner of each modified societe_account record
Alert on any REST API write to /thirdparties/{id}/accounts where the acting user lacks direct ownership of the target company
Correlate API-driven password changes with subsequent portal login attempts from new IP addresses or user agents

Monitoring Recommendations

Enable Dolibarr API access logging and forward logs to a central SIEM for review
Baseline normal API usage per user and flag deviations in third-party write volume
Monitor database audit logs for direct changes to societe_account.pass_crypted

How to Mitigate CVE-2026-71505

Immediate Actions Required

Upgrade Dolibarr to version 24.0.0 or later, which introduces the _checkAccessToResource call on the write route
Rotate all WebPortal passwords for companies that may have been targeted while the vulnerable version was reachable
Review REST API user roles and revoke third-party creation rights from accounts that do not require them
Audit societe_account records for unauthorized modifications since the API was exposed

Patch Information

The fix is delivered in Dolibarr 24.0.0 via commit 4cf305e. The patch adds an explicit DolibarrApi::_checkAccessToResource('societe', $id) check to the third-party site account write route in htdocs/societe/class/api_thirdparties.class.php, throwing a RestException(403) when the caller lacks access. Additional analysis is available in the VulnCheck advisory and the CodeAnt research writeup.

Workarounds

Restrict access to the Dolibarr REST API using network controls until the upgrade is applied
Remove third-party creation rights from any API user that does not strictly need them
Place the REST API behind an authenticating reverse proxy that filters write requests to /thirdparties/*/accounts

bash

# Example: block third-party site account write routes at an nginx reverse proxy
location ~ ^/api/index\.php/thirdparties/[0-9]+/accounts {
    limit_except GET { deny all; }
}