Cap-go - Broken Cursor Pagination in /private/devices Endpoint

An authenticated attacker with `app.read_devices` access sends paginated requests to the `/private/devices` endpoint on the Cloudflare/workerd path. The server returns a `nextCursor` value that, when replayed, returns the same row instead of advancing to the next device. This causes duplicate-page loops, makes later rows unreachable via paginated traversal, and can force clients that follow `nextCursor` while `hasMore=true` into infinite iteration [ref_id=1]. The issue is triggered by the mismatch between the cursor filter (based on `timestamp` and `blob1`) and the `ORDER BY` clause (based on `updated_at` and `device_id`) in the Cloudflare implementation [ref_id=1].

The vulnerability resides in the Cloudflare/workerd code path of the `/private/devices` endpoint. The relevant files are `supabase/functions/_backend/utils/stats.ts` (lines 273–286) and `supabase/functions/_backend/utils/cloudflare.ts` (lines 504–574). The `readDevicesCF()` function builds a cursor filter from `timestamp|device_id` but the resulting SQL query uses `ORDER BY updated_at DESC, device_id ASC` while the cursor filter is based on `timestamp` and `blob1`, causing the cursor to never advance past the first row [ref_id=1].

The advisory does not include a published patch diff. The recommended remediation is to align the cursor filter columns with the `ORDER BY` columns in the Cloudflare `readDevicesCF()` function so that the cursor correctly advances past already-seen rows. Until a fix is applied, the advisory notes that the pagination on the Cloudflare/workerd path is broken and can be exploited to cause duplicate-page loops and unreachable rows [ref_id=1].

Create a test app and two devices using the provided curl commands, then request page 1 with `limit=1` and observe that the returned `nextCursor` replays the same device instead of advancing to the second device. Full reproduction steps are documented in the advisory's PoC section [ref_id=1].