Dolibarr ERP CRM CVE-2026-10215

Exploitation requires a valid authenticated Dolibarr account with at minimum Leave Request module read access - confirmed by CVSS PR:L (low privilege), meaning unauthenticated external attackers cannot exploit this directly. The Dolibarr REST API must be enabled and reachable over the network (AV:N, standard in most deployments). No special non-default configuration is required beyond having a valid user account and API access. The attack is purely read-only: CVSS I:N and A:N confirm no modification or denial-of-service capability. Exploitation is limited to horizontal privilege escalation - accessing peer users' leave records - not vertical escalation to administrative functions or full system compromise. The primary factor limiting real-world risk is the PR:L authentication gate: environments where all Dolibarr users are equally trusted (e.g., a single administrator using the platform alone) face negligible practical exposure, whereas multi-user HR or SMB deployments where employees should not see each other's leave data are meaningfully impacted.

CVSS 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N places this firmly in the limited-impact tier: network-reachable, low complexity, no user interaction required, but gated behind a valid low-privilege account and yielding only confidentiality exposure with no integrity or availability impact. The temporal vector modifiers E:P (proof-of-concept exploit exists), RL:O (official fix released), and RC:C (confirmed report) are all present, indicating elevated confidence in the vulnerability details and reduced urgency once patched. EPSS data was not provided in the input so exploitation probability percentile cannot be quantified. This is not in CISA KEV, meaning no confirmed widespread active exploitation is known at time of analysis. The PR:L authentication requirement is the primary risk limiter - exploitation is trivially easy for any valid Dolibarr user but inaccessible to external unauthenticated attackers. For multi-user deployments (HR teams, SMB employees using self-service leave management), this is a meaningful horizontal privacy violation: any employee could enumerate colleagues' leave records. For single-user or fully trusted internal deployments, practical risk is negligible. The public POC (exploit PDF) lowers the bar for exploitation and warrants treating this as a higher practical priority than the raw CVSS score implies for multi-user environments.

An authenticated Dolibarr employee with a standard user account sends a series of GET requests to the Leave Request API endpoint (/api/index.php/holidays/{id}) incrementing the record ID to enumerate leave records belonging to other employees. Because checkUserAccessToObject receives only the integer ID and the ownership check fails to fire correctly, the API returns the target employee's leave dates, approval status, and associated metadata without raising an authorization error. The publicly available proof-of-concept PDF (https://github.com/user-attachments/files/26487388/2_Dolibarr_Leave_Request_API_Horizontal_Unauthorized_Read_en.pdf) documents this exact technique, making reproduction trivial for any attacker with a valid Dolibarr login.