Summary

Testing confirmed that even when a Manager has manage=false for a given collection, they can still perform the following management operations as long as they have access to the collection:

• PUT /api/organizations/<org_id>/collections/<col_id> succeeds (HTTP 200)
• PUT /api/organizations/<org_id>/collections/<col_id>/users succeeds (HTTP 200)
• DELETE /api/organizations/<org_id>/collections/<col_id> succeeds (HTTP 200)

Description

• The Manager guard checks only whether the user can access the collection, not whether they have manage privileges. This check is directly applied to management endpoints.
  src/auth.rs:816

  if !Collection::can_access_collection(&headers.membership, &col_id, &conn).await {
      err_handler!("The current user isn't a manager for this collection")
  }

• The can_access_collection function does not evaluate the manage flag.
  src/db/models/collection.rs:140

  pub async fn can_access_collection(member: &Membership, col_id: &CollectionId, conn: &DbConn) -> bool {
      member.has_status(MembershipStatus::Confirmed)
          && (member.has_full_access()
              || CollectionUser::has_access_to_collection_by_user(col_id, &member.user_uuid, conn).await
              || ...

• A separate management-permission check exists and includes manage validation, but it is not used during authorization for the affected endpoints.
  src/db/models/collection.rs:516

  pub async fn is_manageable_by_user(&self, user_uuid: &UserId, conn: &DbConn) -> bool {
      let Some(member) = Membership::find_confirmed_by_user_and_org(user_uuid, &self.org_uuid, conn).await else {
          return false;
      };
      if member.has_full_access() {
          return true;
      }
      ...

• The actual update and deletion endpoints only accept ManagerHeaders and do not perform additional manage checks.
  src/api/core/organizations.rs:608

  async fn put_organization_collection_update(..., headers: ManagerHeaders, ...)

src/api/core/organizations.rs:890

  async fn put_collection_users(..., headers: ManagerHeaders, ...)

src/api/core/organizations.rs:747

  async fn delete_organization_collection(..., headers: ManagerHeaders, ...)

Preconditions

• The attacker is a Manager within the target organization.
• The attacker has access to the target collection (assigned=true).
• The attacker’s permission for that collection is manage=false.
• A valid API access token has been obtained.

Steps to Reproduce

1. Confirm that the attacker’s current permissions for the target collection include manage=false.

2. As a control test, verify that update operations fail for collections the attacker cannot access.

3. Confirm that update operations succeed for the target collection where manage=false.

4. Use PUT /collections/{col_id}/users to set manage=true, confirming that the attacker can escalate their own privileges.

5. Verify that deletion of the collection succeeds despite the Manager lacking management rights.

Required Minimum Privileges

• Organization Manager role (Owner/Admin privileges are not required)
• Works even with access_all=false
• Only access rights to the target collection are required (manage privilege is not required)

Attack Scenario

A restricted Manager (intended for read/use-only access) directly invokes the API to update collection settings, elevate their own privileges to manage=true, and even delete the collection.

This allows the user to bypass operational access restrictions and effectively gain administrator-equivalent control over the collection.

Potential Impact

• Confidentiality: Expansion of access scope through unauthorized privilege escalation and configuration changes.
• Integrity: Unauthorized modification of collection settings and assignments; potential disabling of access controls.
• Availability: Deletion of collections may disrupt business operations.

References

• GHSA-h4hq-rgvh-wh27