GHSA-r32r-j5jq-3w4m

Summary

A Manager account (access_all=false) was able to escalate privileges by directly invoking the bulk-access API against collections that were not originally assigned to them. The API allowed changing assigned=false to assigned=true, resulting in unauthorized access.

Additionally, prior to the bulk-access call, the regular single-update API correctly returned 401 Unauthorized for the same collection. After executing the bulk-access API, the same update API returned 200 OK, confirming an authorization gap at the HTTP level.

Description

• The endpoint accepts ManagerHeadersLoose and does not validate access rights for the specified collectionIds. src/api/core/organizations.rs:551

  headers: ManagerHeadersLoose,
  

• The received collection_ids are processed directly without per-collection authorization checks. src/api/core/organizations.rs:564

  for col_id in data.collection_ids {
  

• Existing group assignments for the collection are deleted. src/api/core/organizations.rs:583

  CollectionGroup::delete_all_by_collection(&col_id, &conn).await?;
  

• Existing user assignments for the collection are deleted. src/api/core/organizations.rs:590

  CollectionUser::delete_all_by_collection(&col_id, &conn).await?;
  

• By comparison, another bulk-processing endpoint performs per-collection validation using from_loose. src/api/core/organizations.rs:787

  let headers = ManagerHeaders::from_loose(headers, &collections, &conn).await?;
  

• The actual access control logic is implemented in can_access_collection, which is not invoked in the bulk-access endpoint. src/auth.rs:911

  if !Collection::can_access_collection(&h.membership, col_id, conn).await {
  

Preconditions

• The attacker possesses a valid Manager account within the target organization.
• The organization contains collections that are not assigned to the...