Description

Dolibarr versions 10.0.0 before 24.0.0 fail to perform per-object authorization checks in the Users::getGroups REST API endpoint, allowing authenticated users to retrieve group memberships of other users. Attackers can call GET /users/{id}/groups with arbitrary user identifiers to access group names, entity associations, and private notes across tenant boundaries.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-30T13:16:56.613Z",
  "pubdate": "2026-08-30T13:16:56.613Z",
  "executiveSummary": "Dolibarr versions 10.0.0 through 23.x are susceptible to a Broken Object Level Authorization (BOLA) vulnerability within the REST API. The flaw resides in the Users::getGroups endpoint, which fails to enforce strict access control checks on user-supplied identifiers. By manipulating the user ID parameter, an authenticated attacker can perform unauthorized queries to retrieve sensitive metadata, including group memberships, multi-tenant entity associations, and private notes pertaining to other users. This vulnerability circumvents tenant isolation boundaries, potentially exposing organizational structure and proprietary user data. The exploit is accessible to any authenticated user within the Dolibarr environment, requiring no specific administrative privileges. Given that the API exposes internal data across the application's user base, this vulnerability represents a significant risk to data confidentiality and integrity, particularly in multi-tenant SaaS deployments where strict segmentation is required to prevent cross-tenant information leakage.",
  "technicalDetails": "The vulnerability originates from a deficiency in the authorization logic within the REST API component, specifically involving the Users::getGroups method. While the endpoint correctly validates that a request is authenticated, it fails to perform a secondary, granular check to ensure that the requester has sufficient authorization to access the data associated with the specific {id} parameter provided in the URL path. In a secure implementation, the application should verify the relationship between the authenticated session token and the requested user resource before executing the data retrieval logic.\nThe attack flow follows a predictable pattern of insecure direct object referencing. An attacker initiates an authenticated session and identifies the REST API endpoint at /users/{id}/groups. By iteratively modifying the {id} field—which acts as the primary key for user records—the attacker can bypass the intended access limitations. The backend application, failing to validate whether the authenticated user has legitimate access to the resource associated with the arbitrary ID, queries the database and returns the result set for that specific user. This results in the unauthorized disclosure of internal system metadata.\nData exposed through this exploitation vector includes the target's group memberships, organizational entity affiliations, and private administrative or user-defined notes. Because these fields are returned as part of the JSON response, the impact extends beyond mere identity enumeration to the exposure of sensitive internal configurations. In environments hosting multiple entities, this represents a cross-tenant data breach, as a user in one entity could potentially access records belonging to users in an entirely separate entity. The absence of object-level authorization within the API routing layer effectively allows for mass data scraping of the user directory and associated metadata. The vulnerability is present across all Dolibarr versions from 10.0.0 to 24.0.0 (non-inclusive), necessitating a rigorous review of the API controller layer where object-level access control is missing. The attack requires no special interaction or elevated privileges, as the API inherently trusts the request as long as the session is active, making this a high-impact, low-complexity vulnerability."
}