Description

Capgo (capgo.app) exposes a native build TUS upload proxy (supabase/functions/_backend/public/build/upload.ts) that authorizes a caller against a single build job identified by the supplied builder_job_id and validates only that job's stored upload_path, but then forwards the user-controlled TUS resource suffix taken from /build/upload/:jobId/* to the builder service while injecting Capgo's privileged builder API key. Because the forwarded suffix is never bound to the authorized job's upload_path or upload_session_key, a caller holding a valid 'all' or 'write' Capgo API key with app.build_native permission for one application can use its authorized proxy path for job A to write to the TUS upload resource of another job B, provided that resource suffix is known or exposed, corrupting that build's artifacts. All versions are affected; no patch was available at the time of advisory publication.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-26T14:16:43.567Z",
  "pubdate": "2026-09-26T14:16:43.567Z",
  "executiveSummary": "The Capgo build service contains an authorization bypass vulnerability within its native build TUS upload proxy, located in supabase/functions/_backend/public/build/upload.ts. The vulnerability exists because the proxy validates authorization for a specific 'builder_job_id' but fails to enforce a cryptographically bound relationship between the authorized job context and the user-supplied TUS resource suffix. Consequently, an authenticated attacker with 'app.build_native' permissions can manipulate the upload path to target arbitrary build jobs.\nThe impact is significant, allowing an attacker to perform unauthorized writes to the TUS upload resources of other applications or build jobs. By overwriting artifacts associated with a different job, an attacker can corrupt build outputs or potentially perform supply chain compromise within the Capgo infrastructure. Exploitation requires the attacker to possess a valid API key with appropriate build permissions and knowledge of the target's TUS resource suffix. This flaw represents a failure in path validation and session binding, exposing the system to cross-job data corruption and unauthorized artifact modification across all current versions of the affected product.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper decoupling of authorization and request routing within the TUS upload proxy. When a request is made to the endpoint /build/upload/:jobId/*, the proxy correctly validates that the authenticated user possesses the 'app.build_native' permission for the specified :jobId. It checks the job's stored upload_path to ensure the user is permitted to interact with the specific job context. However, the proxy logic fails to bind the subsequently forwarded TUS resource suffix to the authorized 'upload_path' or the 'upload_session_key' assigned to that job.\nThe architectural flaw is located within supabase/functions/_backend/public/build/upload.ts. After validating the request against the initial :jobId, the proxy extracts the wildcard portion of the request URL (the TUS resource suffix) and appends it to the forwarding request destined for the internal builder service. Critically, the proxy injects a privileged Capgo builder API key into the forwarded request. Because the builder service trusts the proxy's injected credentials, it processes the request under the assumption that the proxy has already verified authorization for the entire target path.\nAn attacker can exploit this by initiating a legitimate upload request for a job they control (Job A). By intercepting the request or crafting a direct call, they can manipulate the TUS resource suffix to reference the resource path of a target Job B. Since the proxy only verifies permissions for Job A, but forwards the full request (including the manipulated suffix) to the builder service with elevated privileges, the request is executed against Job B's resource namespace. If the attacker can predict or identify the TUS resource suffix for Job B, the proxy facilitates an unauthorized write to that target.\nThe attack flow proceeds as follows: 1) The attacker authenticates with a valid API key possessing 'app.build_native' scope. 2) The attacker identifies a target Job B and its corresponding TUS resource suffix. 3) The attacker submits an upload request to the proxy using their authorized Job A identifier but supplies the TUS resource suffix belonging to Job B. 4) The proxy validates the request against Job A and authorizes it. 5) The proxy forwards the request with the Job B suffix and the privileged builder API key to the builder service. 6) The builder service processes the write operation, resulting in the corruption or replacement of artifacts for Job B."
}