Dolibarr Authorization Bypass Enables Unauthenticated Arbitrary File Reads

Dolibarr 23.0.4 before 24.0.1 contains an authorization bypass vulnerability that allows unauthenticated attackers to read arbitrary files through the document storage endpoints by supplying a crafted hashp parameter value. Attackers can send a request with hashp=shared to skip token validation while satisfying the authorization condition in htdocs/document.php and htdocs/viewimage.php, gaining access to application logs, uploaded business documents, database backups containing password hashes, and files belonging to other multicompany entities.

• Dolibarr: Versions from 23.0.4 through versions less than 24.0.1 are identified as affected.
• Dolibarr 24.0.1: This is the exact release associated with the fix for the listed branch. It should not be treated as proof that every parallel or later release branch has been independently verified.
• 22.0 branch: A Dolibarr pull request states that the 24.0.1 fix covered document.php and viewimage.php but missed website/wrapper.php; a follow-up fix was later merged into the 22.0 branch. The returned material does not identify a released 22.x version containing that fix or establish the full affected boundary for that branch.

The root cause is CWE-863: Incorrect Authorization in Dolibarr document storage handling. When hashp is set to shared, the request can skip token validation while the non-empty parameter still satisfies the authorization condition, so the normal secure-document access check is not enforced as intended. The advisory identifies htdocs/document.php and htdocs/viewimage.php; exposed content can include application logs, uploaded business documents, database backups containing password hashes, and files belonging to other multicompany entities. The attacker only needs network reachability to Dolibarr and does not need authentication or user interaction. The fix associated with Dolibarr 24.0.1 adds handling that rejects hashp=shared; later Dolibarr follow-up material states that the initial fix missed website/wrapper.php and that a backport was merged into the 22.0 branch. The complete behavior and release coverage of other branches remain unconfirmed.

The vulnerability is remotely reachable over the network, requires no authentication, requires no user interaction, and is described as low complexity. The request flow uses hashp=shared to bypass token validation and read data through the document endpoints. The VulnCheck advisory states that the issue is included in the VulnCheck KEV database. However, the supplied normalized record leaves known_exploited unset and marks public_exploit as false; a separate GCVE-hosted catalog contains a Previdian assertion of successful exploitation, but that is external intelligence rather than confirmation from the CNA advisory. No specific campaign, victim, or IOC is identified in the reviewed material.

The vulnerability provides remote, unauthenticated file-read access through the affected document endpoints. The primary technical outcome is loss of confidentiality for logs, business documents, database backups, and files belonging to other entities; the record does not establish write access or service disruption. Password hashes in exposed backups could enable offline password guessing when passwords are weak or reused, but that outcome depends on the backup contents and authentication practices. In multicompany deployments, access to another entity's files can expand the incident beyond one business unit. Organizations may need to investigate data disclosure, change credentials, and assess compliance obligations if personal data or confidential business information was accessed.

• Data disclosure: An attacker may read application logs, uploaded business documents, database backups containing password hashes, and files belonging to other multicompany entities.
• Business information exposure: Retrieved documents may contain customer information, contracts, transaction records, or internal data, depending on the deployment and document contents.
• Authentication risk: If password hashes are exposed in a database backup, the organization may need to assess credential changes and password reuse across other systems.
• Incident response cost: Determining which files were accessible, preserving evidence, and assessing notification obligations may be required as part of a data-disclosure investigation.

The record describes read access only. The reviewed material does not establish that this issue directly permits data modification or service disruption.

1. Upgrade deployments in the range from 23.0.4 through versions less than 24.0.1 to 24.0.1, the release associated with the fix in the advisory and source repository.
2. For deployments on the 22.0 branch, verify that the backport covering website/wrapper.php is present in the released code or source currently deployed. Because no exact 22.x release is identified in the reviewed material, do not mark the branch safe based only on its version number.
3. Review local changes, distribution packages, and deployment wrappers to confirm that document.php, viewimage.php, and website/wrapper.php all reject hashp=shared and do not grant access merely because hashp is non-empty.
4. If the system may have been accessed before patching, preserve logs, determine which sensitive files could have been read, and assess whether credentials present in exposed backups should be changed.
5. No vendor-specific temporary mitigation was confirmed in the reviewed material. Network access restrictions may be used as a compensating control while patching, but they should not replace the vendor fix.

1. Inventory deployed Dolibarr versions, including the application branch, maintenance branch, and website module where enabled.
2. Identify systems with network-reachable document.php, viewimage.php, or website/wrapper.php, especially systems that store logs, business documents, database backups, or multicompany data.
3. Review access logs and reverse-proxy logs for requests containing hashp=shared together with the affected endpoints. This is a precautionary detection pattern derived from the documented mechanism, not a confirmed IOC.
4. Check successful responses and download history for documents, logs, or backups during the period when an affected version was deployed.
5. If backups or sensitive files may have been readable, identify the exposed data and assess whether credentials represented in those files should be changed. The absence of matching log entries does not prove that the system was not accessed.