Description

Capgo.app before 12.264.5 does not enforce upload expiry or build lifecycle state in the /build/upload/:jobId TUS proxy endpoint. When a native build request is created, an upload_expires_at timestamp (one hour) and a 'pending' status are stored in build_requests, but the upload proxy loads only app_id, owner_org, builder_job_id, and upload_path and checks only the app.build_native permission before forwarding POST, PATCH, and HEAD requests to the internal builder. As a result, an authenticated caller holding app.build_native permission for the app can continue writing to the build upload session after the stored expiry has passed or after the build has moved beyond the upload phase, unless the separate builder service independently rejects the request. The issue is fixed in 12.264.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-26T14:16:43.430Z",
  "pubdate": "2026-09-26T14:16:43.430Z",
  "executiveSummary": "The /build/upload/:jobId TUS proxy endpoint in Capgo.app prior to 12.264.5 suffers from an authorization and state-validation bypass vulnerability.\nThe vulnerability allows an authenticated user with 'app.build_native' permissions to perform unauthorized write operations to build sessions that have exceeded their designated expiration window or have transitioned to a completed build lifecycle state.\nBy neglecting to enforce 'upload_expires_at' timestamps and build status checks, the TUS proxy blindly forwards POST, PATCH, and HEAD requests to the internal builder service.\nThis flaw presents a risk of unauthorized build artifact manipulation and session persistence, potentially leading to build integrity compromise.\nExploitation requires the attacker to possess valid 'app.build_native' credentials for the target application, which serves as a prerequisite for interacting with the proxy endpoint.\nThe impact is limited to the build lifecycle management process, but undermines the expected security boundaries defined in the application's configuration database.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient server-side validation logic within the TUS proxy endpoint (/build/upload/:jobId). While the system correctly stores 'upload_expires_at' (set to a one-hour window) and a 'pending' lifecycle status in the 'build_requests' table during the initial native build request creation, the TUS proxy fails to reference this metadata during subsequent interactions.\nWhen a client initiates a request (POST, PATCH, or HEAD) to the TUS proxy, the proxy performs a limited verification: it extracts the 'app_id', 'owner_org', 'builder_job_id', and 'upload_path' from the request context and validates the user's 'app.build_native' permission against the application. However, it ignores the critical state variables stored in the 'build_requests' database table.\nThis decoupling between the authorization check (which only evaluates role-based access) and the session state validation (which should evaluate expiration and lifecycle stages) permits a race condition or a post-expiry modification attack. An authenticated attacker can maintain a persistent write connection to the build session indefinitely, bypassing the one-hour expiration policy, provided the internal builder does not implement independent, redundant state validation.\nThe attack flow follows these steps: 1. The attacker authenticates as a user with 'app.build_native' permissions. 2. The attacker identifies or initiates a legitimate build request that creates a TUS upload session. 3. The attacker continues to send PATCH requests to the /build/upload/:jobId endpoint to upload or overwrite data after the 'upload_expires_at' threshold has passed. 4. The proxy, failing to query the 'build_requests' table for the current 'pending' status or the expiration timestamp, validates only the user's role and transparently proxies the requests to the internal builder.\nBecause the proxy acts as a pass-through layer for the TUS protocol without validating the build's business logic constraints, the builder service receives potentially malicious or stale data after the build cycle should have terminated. This allows an attacker to inject unauthorized artifacts or manipulate build results in systems where the builder does not perform its own secondary verification of the upload session state.\nThis vulnerability affects Capgo.app versions prior to 12.264.5 and exists primarily within the orchestration logic of the TUS proxy component."
}