CVE-2026-76032 in Cells
Summary
by MITRE • 08/18/2026
Pydio Cells 5.0.0 through 5.0.2 returns share-link details to any authenticated user. The REST handler for GET /a/share/link/{Uuid} in idm/share/rest/handler.go reads the workspace UUID from the path, calls LinkById, and writes the result with no authorization step, whereas the sibling handler for GET /a/share/cell/{Uuid} loads the workspace and requires MatchPolicies with ResourcePolicyAction_READ, returning a not-found error so that existence is not disclosed. Nothing compensates further down: GetLinkWorkspace reaches GetOrCreateWorkspace, which issues SearchWorkspace with a query carrying no ResourcePolicyQuery, and PrepareResourcePolicyQuery returns the query unmodified when that field is nil, so the workspace service applies no policy filter. The workspace UUID is not secret, because the unauthenticated public page served for a share link embeds it as START_REPOSITORY. Any account holding a standard user role can therefore submit the UUID and receive the link hash and URL, the owner's user identifier, the hidden share user login, the permission set, the download limit and count, the target users, the expiry, and the password-required flag, while a direct read of the shared node from the same account is refused.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability in Pydio Cells versions 5.0.0 through 5.0.2 represents a critical authorization bypass within the application's share management subsystem, specifically affecting the REST API endpoint responsible for retrieving detailed information about public sharing links. The core technical flaw resides in the GET /a/share/link/{Uuid} handler located in idm/share/rest/handler.go. When this endpoint is invoked with a valid workspace UUID extracted from the request path, it immediately calls the LinkById function and serializes the resulting data structure to the HTTP response without performing any intermediate authorization checks. This stands in stark contrast to the sibling endpoint GET /a/share/cell/{Uuid}, which correctly implements security controls by loading the associated workspace and enforcing a MatchPolicies check that requires ResourcePolicyAction_READ, thereby returning a not-found error if access is denied and preventing information disclosure regarding existence or details.
The root cause of this authorization failure lies in how the backend services handle policy enforcement for shared resources. The LinkById function eventually triggers GetLinkWorkspace, which subsequently calls GetOrCreateWorkspace to retrieve workspace metadata. This call issues a SearchWorkspace operation with a query object that lacks any ResourcePolicyQuery component. Because the PrepareResourcePolicyQuery utility returns the query unmodified when its input is nil or empty, the underlying workspace service applies no policy-based filtering during this specific retrieval process. Consequently, the system fails to verify whether the requesting user has permission to view the metadata of the share link associated with that UUID. This architectural oversight allows any authenticated user who possesses a standard user role to bypass intended access controls and retrieve sensitive configuration details about shares they do not own or have no business accessing.
The operational impact of this vulnerability is significant due to the nature of data exposed through the unauthenticated public page mechanism. The workspace UUID required to exploit this flaw is not considered secret information, as it is embedded in the HTML source code under the variable START_REPOSITORY when an administrator generates a share link for external access. This design choice inadvertently provides attackers with the necessary identifier to target specific shares. An authenticated attacker can submit any known or guessed workspace UUID to the vulnerable endpoint and receive a comprehensive JSON response containing sensitive metadata. The exposed data includes the internal hash of the share, the full URL, the user identifier of the link owner, the hidden login credentials for shared users, the complete permission set assigned to the share, download limits along with current usage counts, target user lists, expiration dates, and flags indicating whether password protection is enabled. This level of detail allows an attacker to map out sharing structures within an organization, identify high-value targets based on permissions or expiry settings, and potentially facilitate further attacks such as credential stuffing if passwords are weak or reused.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure in enforcing authorization policies for specific API endpoints despite their existence elsewhere in the application logic. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as exploitation requires valid authentication but leverages insufficient access control mechanisms rather than credential theft. The discrepancy between the secure implementation of GET /a/share/cell/{Uuid} and the insecure GET /a/share/link/{Uuid} highlights a common pattern in web application development where security controls are applied inconsistently across similar functionalities. To mitigate this issue, developers must ensure that all API endpoints handling sensitive resource metadata implement consistent authorization checks prior to data retrieval. This involves integrating policy evaluation logic into the LinkById flow or ensuring that GetOrCreateWorkspace respects ResourcePolicyQuery parameters even when derived from share link contexts. Until a patch is applied, administrators should restrict network access to these internal REST APIs where possible and monitor for unusual patterns of requests targeting share endpoints with varying UUIDs.