CVE-2026-10215 Overview
CVE-2026-10215 is an improper authorization vulnerability in Dolibarr ERP CRM through version 23.0.1. The flaw resides in the checkUserAccessToObject logic invoked from htdocs/holiday/class/api_holidays.class.php, which exposes the Leave Request REST API. An authenticated remote attacker can manipulate the API call to bypass hierarchy-based access checks and read leave request records belonging to other users. The issue is classified under CWE-266: Incorrect Privilege Assignment. A public exploit and proof-of-concept document have been disclosed. The vendor addressed the issue in Dolibarr 23.0.2 via commit ee93b6f2f9dd0f6aeefe9d718ab3ab0a44326b73.
Critical Impact
Authenticated remote attackers can perform horizontal privilege escalation against the Leave Request REST API to read other users' holiday records without authorization.
Affected Products
- Dolibarr ERP CRM versions up to and including 23.0.1
- Component: Leave Request REST API (htdocs/holiday/class/api_holidays.class.php)
- Function: checkUserAccessToObject
Discovery Timeline
- 2026-06-01 - CVE-2026-10215 published to NVD
- 2026-06-03 - Last updated in NVD database
- Patch commit - ee93b6f2f9dd0f6aeefe9d718ab3ab0a44326b73 merged and released in Dolibarr 23.0.2
Technical Details for CVE-2026-10215
Vulnerability Analysis
The vulnerability is an improper authorization flaw in the Leave Request REST API. When a client requests a holiday record, the API resolves the target leave object and then calls DolibarrApi::_checkAccessToResource('holiday', $this->holiday->id). The check receives only the numeric record ID and does not evaluate the hierarchical relationship between the calling user and the record owner. As a result, any authenticated API user with baseline leave permissions can request another user's leave record by ID and receive the response. The flaw is a horizontal privilege escalation against tenant data within the same Dolibarr instance.
Root Cause
The root cause is an incomplete authorization check in the API helper used by api_holidays.class.php. The function _checkAccessToResource was invoked with a resource identifier rather than the full holiday object, which prevented the access layer from re-evaluating hierarchy and ownership. The fix changes the call signature so the complete $this->holiday object is passed, allowing the access control logic to verify the requesting user's position in the user hierarchy before returning data.
Attack Vector
The attack is initiated remotely over the network. The attacker must hold valid API credentials with low privileges. By enumerating numeric id values on the leave request endpoint, the attacker retrieves leave records owned by users outside the attacker's hierarchy. No user interaction is required.
// Patched call site in htdocs/holiday/class/api_holidays.class.php
// Source: https://github.com/Dolibarr/dolibarr/commit/ee93b6f2f9dd0f6aeefe9d718ab3ab0a44326b73
throw new RestException(404, 'Leave not found');
}
- if (!DolibarrApi::_checkAccessToResource('holiday', $this->holiday->id)) {
+ if (!DolibarrApi::_checkAccessToResource('holiday', $this->holiday)) {
throw new RestException(403, 'Access not allowed for login '.DolibarrApiAccess::$user->login);
}
The helper signature was also updated in htdocs/api/class/api.class.php so that $resource_id accepts a full object, an ID, or a list of IDs, enabling hierarchy-aware checks:
// Source: https://github.com/Dolibarr/dolibarr/commit/ee93b6f2f9dd0f6aeefe9d718ab3ab0a44326b73
protected static function _checkAccessToResource(
$resource,
$resource_id = 0, // int|string|Object - full object, id, or list of ids
$dbtablename = '',
$feature2 = '',
$dbt_keyfield = 'fk_soc',
$dbt_select = 'rowid'
) {
// hierarchy-aware authorization logic
}
Detection Methods for CVE-2026-10215
Indicators of Compromise
- HTTP GET requests to /api/index.php/holidays/{id} where {id} is iterated sequentially from a single authenticated session.
- Successful 200 OK responses from the leave API for record IDs owned by users outside the caller's reporting line.
- Spikes in REST API authentication from a single DOLAPIKEY value against the holiday endpoint.
Detection Strategies
- Review Dolibarr web server access logs for repeated calls to /api/index.php/holidays/ with incrementing numeric identifiers from the same API key or IP.
- Correlate dolibarr_api.log entries with the application user table to flag any access where the requesting user is not in the manager hierarchy of the record owner.
- Compare pre-patch and post-patch api_holidays.class.php behavior in staging to baseline expected 403 responses for cross-hierarchy requests.
Monitoring Recommendations
- Enable verbose API request logging in Dolibarr and forward logs to a centralized SIEM for retention and correlation.
- Alert on any single API key issuing more than a defined threshold of holiday endpoint requests per minute.
- Track HTTP 403 to 200 ratio changes on the holiday API to identify enumeration behavior.
How to Mitigate CVE-2026-10215
Immediate Actions Required
- Upgrade Dolibarr ERP CRM to version 23.0.2 or later, which contains commit ee93b6f2f9dd0f6aeefe9d718ab3ab0a44326b73.
- Audit existing API keys and revoke keys that are not actively used by an integration.
- Review recent access logs on the /api/index.php/holidays/ route for evidence of enumeration prior to patching.
Patch Information
The vendor released the fix in Dolibarr 23.0.2. The relevant patch is tracked under GHSA-qjj8-wpvx-p54j and the issue thread at Dolibarr GitHub Issue #37752. Additional context is available in the VulDB entry for CVE-2026-10215.
Workarounds
- Disable the REST API module in Dolibarr until the upgrade to 23.0.2 can be deployed if the API is not required.
- Restrict access to /api/index.php/ at the reverse proxy or WAF to a known allowlist of integration source IPs.
- Remove the Use Dolibarr API permission from low-privileged users who do not need programmatic access to holiday data.
# Example: block external access to the Dolibarr REST API at the nginx layer
location ~ ^/api/index\.php/holidays/ {
allow 10.0.0.0/24; # internal integration subnet
deny all;
include fastcgi_params;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

