GHSA-vx2m-jpxr-xv7w: Incorrect Authorization Bypass via Context Hint Cache Replay in Cloudreve

The Cloudreve system incorporates a high-performance database file system (DBFS) layer to manage files, directories, and sharing operations. To optimize user experience and reduce database lookup overhead during sequential file queries, the backend uses an optimization identifier called a "context hint" (represented as a UUID) transmitted via the X-Cr-Context-Hint HTTP header. This hint assists the backend in matching user sessions to cacheable directory states, accelerating file traversal.

A critical broken access control vulnerability exists in this caching flow. When listing a share, Cloudreve generates a context hint and transmits it to the client. If an attacker replays this context hint during requests to retrieve download links (/file/url) or generating thumbnails (/file/thumb), Cloudreve's database file system (DBFS) attempts to restore the cached file navigator state.

This state restoration completely skips subsequent security policy evaluation. The root cause lies in the system trusting the presence of the cached navigator object as proof of continuous, validated authorization. Because the cache retains this authorization state for a default Time-To-Live (TTL) of 300 seconds, an attacker can obtain valid file download URLs and generate file thumbnails even after a share has been manually deleted, expired, or depleted its download quota.

The vulnerability is classified under CWE-863 (Incorrect Authorization). When processing a request for file retrieval, the system relies on shareNavigator to resolve path pointers to database files. Under normal operating conditions (without a cached state), the routing engine invokes the Root() method of the navigator, which validates the share integrity by querying inventory.IsValidShare(share). This process checks if the share is active, validates expiration dates, ensures download limits are not reached, and verifies the share password.

However, when a context hint is supplied in the request headers, the ContextHint middleware extracts the UUID and retrieves the corresponding shareNavigatorState from the key-value store. This state includes a populated shareRoot object. When resolving the target path through To(), the code evaluates whether n.shareRoot is nil. Because the state restoration process populates n.shareRoot, this evaluation returns false, causing the execution flow to bypass the Root() method entirely.

Furthermore, the system fails to handle the post-execution hooks defensively. When a file download is initiated, the system executes the hook fs.HookTypeBeforeDownload to update download counters in the database. If the share has been deleted or is otherwise invalid, this database operation fails. However, instead of halting execution, the file manager merely logs the failure as a warning and proceeds to generate the signed download URL, thereby rendering the security control entirely ineffective.

The vulnerable state-restoration logic in share_navigator.go can be analyzed in the transition method To(). The original codebase implements the path resolution as follows:

// From share_navigator.go
func (n *shareNavigator) To(ctx context.Context, path *fs.URI) (*File, error) {
    // If shareRoot is already restored from cache, the Root() call is bypassed.
    if n.shareRoot == nil {
        root, err := n.Root(ctx, path)
        if err != nil {
            return nil, err
        }
        n.shareRoot = root
    }
    // Execution continues to resolve the child node without re-validating the share.
    return n.resolveChild(ctx, n.shareRoot, path)
}

In this implementation, the cached state maps directly to n.shareRoot during restoration. The check if n.shareRoot == nil acts as an optimization gate. If n.shareRoot is loaded from the cache, the conditional block is skipped, preventing the invocation of n.Root(). The n.Root() method is the only location where inventory.IsValidShare(share) and password validation checks are executed.

// From share_navigator.go (Root validation logic)
func (n *shareNavigator) Root(ctx context.Context, path *fs.URI) (*Folder, error) {
    // Crucial validation routines are situated here
    if err := inventory.IsValidShare(n.share); err != nil {
        return nil, err
    }
    if n.share.Password != "" && !n.isPasswordVerified() {
        return nil, ErrPasswordRequired
    }
    ...
}

Because the execution bypasses the conditional check when n.shareRoot is restored, the safety constraints enforced inside Root() are not evaluated. This design flaw permits unauthorized requests to leverage the stored state to acquire signed URLs via /file/url or request thumbnail resources through /file/thumb.

Exploitation requires that the attacker has previously accessed a valid share or possesses a valid context hint generated during an active sharing session. The attack sequence exploits the 300-second cache TTL window to maintain access after the resource is revoked.

First, the attacker requests the share's file listing, capturing the context hint (UUID) from the response header or body. Second, the attacker triggers a request to /api/v4/file/url, causing the server to register a cache miss, execute the normal authorization checks, and store the authenticated state in the database file system (DBFS) key-value cache under the key navigator_state_<hint>_share.

Once the cache is populated ("warmed"), the owner of the share deletes or revokes the share. This action deletes the corresponding records in the sharing tables. However, the cached navigator_state remains active in memory.

Within the 300-second TTL window, the attacker re-sends the request to /api/v4/file/url using the cached context hint in the X-Cr-Context-Hint header. The server matches the cached state, restores n.shareRoot directly, skips Root(), and issues a signed download URL.

Here is the flow of the exploitation process:

This vulnerability breaks the fundamental access controls governing file-sharing in Cloudreve. Users rely on share revocation, expiration times, and download limits to protect sensitive data from prolonged exposure. Bypassing these mechanisms means that files remain accessible to unauthorized recipients even after explicit deletion.

In enterprise or private cloud environments, this flaw could result in the unauthorized exfiltration of proprietary datasets, credentials, or personal documents. The attack complexity is low, and no specialized privileges or user interactions are required to trigger the exploit.

Because the vulnerability allows the direct generation of signed download URLs, the attacker achieves read access to the underlying storage backend. Although the attacker cannot modify files or upload new contents (preserving integrity and availability), the compromise of confidentiality is complete within the cache lifetime window.

To resolve this logical flaw, developers must ensure that state restoration does not bypass authorization checks. The caching mechanism should serve solely as a performance layer, not an authorization shortcut.

The primary correction requires forcing validation on state restoration. When RestoreState is invoked, the database record for the share must be queried and re-evaluated using inventory.IsValidShare(share). If the database check reveals that the share has been deleted, has expired, or has reached its download limit, the cached state must be discarded, and the request must be denied.

Additionally, modification of download hook behavior is required. In pkg/filemanager/manager/entity.go, the application must treat failures in the execution of navigator hooks as fatal errors. If ExecuteNavigatorHooks fails during the pre-download phase (for example, due to a missing share database entry), the engine must abort the process and return an authorization error to prevent URL generation.

As an immediate, temporary mitigation when patching is not possible, system administrators can deploy a Web Application Firewall (WAF) or modify reverse proxy configurations (such as Nginx) to strip the X-Cr-Context-Hint header from requests sent to /api/v4/file/url and /api/v4/file/thumb. This forces Cloudreve to execute authorization validation on every request, neutralizing the cache bypass.