# Shared collection scope confusion

Search or fetch helpers that apply the requester's scope or config to another owner's files.

_Area: Web access control and IDOR. Seen in 2 disclosed reports; one confirmed bounty: $14,500; latest 2026-09-17. Updated 2026-10-31._

## How it works
A shared or album feature searches files that belong to an owner, but the scope (path filters, config, or a fallback identity) is taken from the requester instead of the owner. The assumption that breaks: that the code path serving a shared view uses the owner's boundaries. When the requester's filters, config, or a privileged fallback account are substituted, the search reaches files the owner never shared.

## Where it shows up
- A query helper that takes a target `userId` but reads config from the ambient session user (e.g. `getUserConfig`/`getAppValue` with no user argument) [E3](https://bugbountylibrary.com/r/h1%3A3506873.md).
- Path `LIKE` filters built from the viewer's source folders but applied to the owner's folder [E3](https://bugbountylibrary.com/r/h1%3A3506873.md).
- Alternate code paths selected by request headers (mobile user-agent) that fall back to a superuser or service account [E1](https://bugbountylibrary.com/r/blog%3A003random-com-posts-meta-bountycon-instagram-writeup.md).
- Content-addressed storage where authorization is per-tenant but the object key is global; dedupe/short-circuit branches that skip integrity checks before creating the tenant binding [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-6p9m-q3jp-47h4.md).

## How to review
For every shared/album/search endpoint, confirm the scope is derived from the resource owner, not the caller. The invariant: any filter, config, or identity used to select files must belong to the owner of the collection being searched. Check that helper functions operating on another user's data never call ambient-session config getters. For header-dependent branches, verify each branch enforces the same authorization. For content-addressed stores, verify every path that creates a per-tenant binding validates the object against the claimed key before binding.

## Variants seen
- Viewer's source-folder config applied to owner's files in smart albums [E3](https://bugbountylibrary.com/r/h1%3A3506873.md).
- Mobile-UA branch falling back to a superuser account, bypassing blocks [E1](https://bugbountylibrary.com/r/blog%3A003random-com-posts-meta-bountycon-instagram-writeup.md).
- LFS dedupe branch skipping hash verification, binding a foreign object to a repo [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-6p9m-q3jp-47h4.md).

## Impact and severity
Private posts and media readable despite blocks [E1](https://bugbountylibrary.com/r/blog%3A003random-com-posts-meta-bountycon-instagram-writeup.md); cross-tenant private repo content leaked [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-6p9m-q3jp-47h4.md); files outside the album owner's configured folders exposed to sharees [E3](https://bugbountylibrary.com/r/h1%3A3506873.md). Severity is high because the boundary crossed is the tenant/owner line. Worse when the fallback identity is privileged [E1](https://bugbountylibrary.com/r/blog%3A003random-com-posts-meta-bountycon-instagram-writeup.md) or the leak is silent and needs no victim action [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-6p9m-q3jp-47h4.md).

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3A003random-com-posts-meta-bountycon-instagram-writeup.md
- E2: https://bugbountylibrary.com/r/ghsa%3AGHSA-6p9m-q3jp-47h4.md
- E3: https://bugbountylibrary.com/r/h1%3A3506873.md