CVE-2026-100624 in Capgo.app
Summary
by MITRE • 09/26/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Capgo.app versions prior to 12.264.5 represents a critical failure in access control and state management within the build upload infrastructure, specifically affecting the /build/upload/:jobId TUS proxy endpoint. This flaw allows authenticated users with specific permissions to bypass intended temporal and lifecycle constraints on file uploads. The core of the issue lies in the discrepancy between how the system records build request metadata and how the proxy validates incoming requests for persistence operations such as POST, PATCH, and HEAD. When a native build is initiated, the backend correctly generates an upload_expires_at timestamp set to one hour from creation and assigns a pending status within the build_requests database table. These fields are intended to enforce strict boundaries on when uploads can occur and persist, ensuring that resources are not consumed indefinitely or during inappropriate phases of the build pipeline.
However, the TUS proxy endpoint responsible for handling these upload operations fails to utilize this metadata for validation purposes. Instead of checking the current time against the stored expiry timestamp or verifying that the associated build request is still in an active upload state, the proxy only retrieves and validates a limited set of attributes: app_id, owner_org, builder_job_id, and upload_path. The sole authorization check performed by the proxy is whether the authenticated caller holds the app.build_native permission for the specified application. This design oversight means that as long as the user retains this static permission, they can interact with the upload session regardless of temporal expiration or changes in the build lifecycle state. Consequently, an attacker who has obtained valid credentials and possesses the necessary permissions could theoretically continue to write data to a build upload session well after it should have been terminated due to timeout or completion.
The operational impact of this vulnerability is significant from both a resource consumption and potential security perspective. By allowing uploads to persist beyond their intended lifespan, attackers can exhaust server storage resources through denial-of-service attacks using large file writes. More critically, if the internal builder service does not independently validate these constraints before processing uploaded artifacts, malicious actors could potentially inject or modify build inputs after the initial submission phase has logically concluded. This undermines the integrity of the continuous integration and deployment pipeline, as it allows for post-submission tampering with codebases that are being compiled into native binaries. Such manipulation could lead to the creation of compromised applications if the builder service fails to perform its own rigorous checks on input validity relative to time or state.
This vulnerability aligns closely with CWE-284 Improper Access Control, as it involves a failure to enforce proper restrictions on authenticated users regarding resource access duration and context. It also relates to CWE-613 Insufficient Session Expiration because the session associated with the upload job does not terminate correctly based on time-based policies defined by the application logic. From an offensive security perspective, this flaw can be mapped to MITRE ATT&CK techniques involving Resource Hijacking or Supply Chain Compromise, specifically where an adversary manipulates inputs during a build process to introduce malicious code that is subsequently distributed to end users. The lack of state-aware validation in the proxy layer creates a gap that bypasses standard defensive controls designed to limit exposure windows and enforce workflow integrity.
To mitigate this vulnerability, organizations must ensure they are running Capgo.app version 12.264.5 or later, where these checks have been implemented. For environments unable to immediately patch, it is crucial to verify that the internal builder service independently validates upload timestamps and build states before accepting any data for processing. Additionally, implementing strict rate limiting on upload endpoints can help mitigate potential denial-of-service impacts resulting from prolonged write operations. Security teams should also audit other proxy layers within their CI/CD infrastructure to ensure they do not suffer from similar oversights where static permission checks override dynamic state or temporal constraints. Regular penetration testing focused on workflow logic and session management will further help identify such discrepancies before they can be exploited in production environments.