Dolibarr ERP CVE-2026-71507

Exploitation requires an authenticated Dolibarr session with at least 'third-party creation' rights - a non-default permission that must be explicitly granted to user accounts, but one that may be broadly assigned in organizations where multiple users manage supplier or customer records. No read access to the target company object is required, only write API access via the bank account routes. The attack is limited to installations with the REST API enabled and accessible; organizations that have not enabled the API module or have blocked external API access are not directly exposed. The CVSS 4.0 vector (PR:L) confirms authenticated access is required - unauthenticated exploitation is not possible. Limiting factors include: requirement for a valid user account, 'third-party creation' permission grant, and REST API being active and reachable.

The CVSS 4.0 base score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) accurately reflects the core threat model: network-accessible, low complexity, low privilege threshold, no user interaction, and high integrity impact. The absence of a confidentiality or availability component keeps the score from higher tiers, but this understates business risk - the integrity impact here is financial fraud via IBAN substitution, not mere data corruption. No EPSS score was provided in the input data; exploitation probability cannot be independently assessed from available signals. The publicly available POC (distinct from confirmed active exploitation) combined with a low privilege bar and a straightforward attack path warrants treating this as higher operational priority than the raw CVSS alone implies, particularly for organizations using Dolibarr in supplier payment workflows with SEPA transfers. Not currently listed in CISA KEV, so confirmed widespread active exploitation is not established.

An attacker with a low-privilege Dolibarr account - one granted only the generic 'third-party creation' right - authenticates to the REST API and issues write requests to the bank account route for a target company (e.g., a supplier), replacing the legitimate IBAN with an attacker-controlled account number. A publicly available POC details this technique. The next time a finance operator regenerates SEPA credit-transfer files for that supplier, the outgoing payment is silently directed to the attacker's bank account rather than the legitimate creditor.