Capgo - Cross-App Build Job Access via app_id/job_id Mismatch in /build/status and /build/logs

An attacker who possesses a limited API key restricted to a single app (App A) can access build status and logs for a build job belonging to a different app (App B) by supplying App A's `app_id` while using App B's `job_id`. The authorization check is performed only against the user-supplied `app_id`, and the endpoints do not verify that the `job_id` belongs to that `app_id` [ref_id=1]. This allows cross-app information exposure for native build jobs, including sensitive build metadata, environment info, and potentially credentials [ref_id=1].

The vulnerability resides in `supabase/functions/_backend/public/build/status.ts` and `supabase/functions/_backend/public/build/logs.ts`. Both endpoints perform authorization via `checkPermission(c, 'app.read', { appId: app_id })` using the user-supplied `app_id` but then fetch build data using only the `job_id` without verifying that the `job_id` belongs to that `app_id`. In contrast, `upload.ts` is noted as safer because it queries `build_requests` by `builder_job_id` and checks permission against the database-derived `app_id`.

The advisory recommends that before calling the builder in `/build/status` and `/build/logs`, the application should bind `job_id` to `app_id` by querying `build_requests` by `builder_job_id`, verifying that the database-derived `app_id` matches the request's `app_id` (or ignoring the request's `app_id` entirely), and then running permission checks against the database-derived `app_id` [ref_id=1]. This ensures that even if an attacker supplies a mismatched `app_id`, the authorization check is performed against the actual app that owns the build job.