Summary
Cloudreve's admin OAuth sign-in endpoint for OneDrive policies accepts only read-level admin permission while persisting caller-supplied secrets and application IDs.
Under these conditions, an attacker with Admin.Read access can alter stored OneDrive credentials and thereby influence storage policy behavior without needing full write privileges.
Affected context
This vulnerability appears in Cloudreve deployments where:
- Admin users or API clients are granted Admin.Read but not Admin.Write
- The
/api/v4/admin/policy/oauth/signinroute is accessible as part of the admin interface - OneDrive-based storage policies rely on secrets and app IDs configured via this OAuth flow
In such environments, the endpoint can be abused to persist new OAuth credentials under the guise of a read-only operation.
Exploit preconditions
- Attack surface: Authenticated Cloudreve admin API, specifically
/api/v4/admin/policy/oauth/signin - Required access: An account with Admin.Read-level permissions capable of calling admin routes
- Trigger point: Invoking the OAuth sign-in endpoint while supplying attacker-controlled OneDrive
secretandapp_idvalues - Why exploitation is possible: The handler is grouped under an Admin.Read-only route and does not enforce the additional Admin.Write guard that other policy mutation handlers use, yet it still persists configuration changes
Why this happens
The root cause is an authorization design flaw where a state-changing operation is exposed under a permission level intended for read-only actions.
The /api/v4/admin/policy/oauth/signin handler is placed within an admin route group that enforces only Admin.Read, but it performs a write operation by persisting the supplied OneDrive secret and app_id into a storage policy.
This aligns with CWE-863: Incorrect Authorization, in which the system fails to apply appropriate authorization checks for sensitive functions and allows users with insufficient privileges to modify security-relevant configuration.
Potential impact
- An Admin.Read user could configure or replace OneDrive OAuth credentials used by a storage policy
- Attackers may redirect file storage to accounts they control, impacting data confidentiality and integrity
- Misconfigured credentials could cause service disruption or denial of access to legitimate storage
- Audit trails and ownership of stored content may be obscured or misattributed
General mitigation guidance
Effective mitigation focuses on ensuring that every state-changing or configuration-modifying route is protected by the appropriate authorization guard.
Common hardening patterns include:
- Classifying endpoints explicitly as read-only or mutating, and enforcing stricter permissions for the latter
- Centralizing authorization logic so that all admin routes consistently apply role and scope checks
- Treating changes to OAuth credentials, secrets, and storage policies as high-sensitivity operations requiring elevated privileges
- Applying least-privilege principles to admin roles, ensuring that read-only roles cannot indirectly trigger writes
How teams detect issues like this
Detection typically involves:
- Reviewing route definitions to identify handlers under read-only groups that perform writes or persist configuration changes
- Using static analysis or linters to enforce that functions touching secrets or policy objects require high-privilege guards
- Implementing authorization tests in CI that exercise admin APIs with downgraded roles to confirm access is correctly denied
- Monitoring logs for unexpected policy updates initiated by accounts with nominally read-only roles
